Kontur Mobile Test Session:5時間で446個のバグ

12月、Konturはエカテリンブルクで年次の都市テストセッションを開催しました。 今回は、5時間の38人のテスターが新しいモバイルアプリケーションのバグを検索しました。 テストのスペシャリストでありイベントのオーガナイザーであるイゴール・ボリシキンは、彼の経験を共有し、Contourは新しいテストセッションと今年のイベントへの行き方を思いついたと語った。











テストセッションとは



テストセッションは、初心者や上級テスター、テストに無関心でない人、マスタークラスの類似物、または開発者向けのワークショップを対象とした競争です。 テストセッションでは、他社の同僚に会い、新製品の「強さ」を自分で確認し、バグの発見に優れている人を見つけることができます。 テストセッションは、エカテリンブルクの伝統的なイベントです。 エカテリンブルク-UTCのテスターコミュニティで見つけることができる最後の4回目の市全体のテストセッションは何でしたか。







フォーマットについて



従来のテストセッション形式には、Webサービスのテストが含まれます。 メンバーには製品分析があります。 バグを見つけるのにN時間かかります。 最後に、審査員は誰がどのくらいのバグを見つけたかを考慮します。 最高のものは賞品です。 従来のテストセッション形式に追加された輪郭:







モバイルアプリケーション。

テスト用の製品は、Konturモバイルアプリケーションでした。外部および内部会議用の会議。 Contourアプリの詳細については、 Google PlayApp Storeなどの市場でのカンファレンスをご覧ください。 仕組みは次のとおりです。









分析の代わりにマインドマップ。

参加者にアプリケーションの大量の退屈な分析をロードしませんでしたが、代わりに、各チームには、その仕事の特徴と研究のための自由な分野の上限がありました。 マッピングには、プログラムXMindを使用しました。







トレーニング。

テストセッションの形式に従って、バグを検索するプロセスで、参加者はモバイルアプリケーションをテストするための新しい方法とテクニックを学びました。 ポイント2と3についてはもう少し詳しく説明します。







参加者について



エカテリンブルクのさまざまな企業から38人のテスターがテストセッションに集まりました:iRidium mobile、Ridero、Motorsport.com、Ural Airlines、Point、Advanta、Mercata、Extreme Pro、Flag Studio、BD Cube、ITM Holding、Digital Spectr、SkyDNS、Naumen、Contour 。











経験ベースのテスト



テスターに​​分析をロードする代わりに、アプリケーションを知る別の方法、つまり経験に基づいたテストを提案しました。







経験に基づくテスト-オープンな多次元空間でのヒューリスティック探索。 簡単な場合は、アプリケーションを調べて、機能するかどうかを判断します。 テストセッションの各参加者はすでに会議に参加しているため、アプリケーションのサブジェクトエリアを知っています。







経験ベースのテストは、3つの方法に基づいています。







  1. 間違いを推測する-エラーを想定し、それがアプリケーションにないことを確認します。
  2. チェックリストに基づいたテスト-アプリケーションのトップレベルのチェックを考え出し、テスト中に特定のテストケースを生成および検証します。
  3. 研究テスト-自身の経験に基づいて、アプリケーションの動作の予想される結果と取得された結果の比較。


ただし、テストセッションのすべての参加者がモバイルアプリケーションのテストの経験があるわけではありません。

研究の新しい方向性を提案し、経験と特定のケースを経験豊富なテスターと共有するために、テストセッション中にモバイルテストのヒューリスティックについて参加者に話しました。







モバイルテストヒューリスティックは、これまで知られていなかったものの発見に貢献する研究方法の集まりです。











ペアテストについて



セッションでは、参加者はペアでテストしました。 19チームが構成されました。 チームを結合し、次の基準に従ってバランスを取りました。







テストの経験。

初心者は初心者に慣れています。 経験豊富な経験者。 初心者が非常に経験豊富なテスターと協力して作業する場合、ほとんどの場合、経験豊富なテスターが優勢であり、初心者の同僚のアイデアを明らかにすることはできません。 参加者の経験が4年を超える場合(5年や10年など)、それらを1つのチームに安全に結合できます。







モバイルアプリケーションのテストの経験。

テストセッションは、あらゆる専門分野のテスターに​​とって開かれたイベントです。したがって、モバイルテスト以外のテスターが同じチームに参加するのは良いことです。







デバイス。

人々はガジェットを使用してテストセッションに参加しました。 チーム内のデバイスがiOSとAndroidの両方であることを確認しようとしました。







さまざまなコミュニケーション。

私たちはコミュニケーションのためです! 同じ会社の同僚が同じチームに所属することはできません。







ペアテストはタスクに集中するのに役立ち、テスターが他の人が休憩を取りながら動き続けるのに役立ちます。 カップルは、各テスターがアイデアを説明し、実装することを奨励します。 テスターが自分の考えを他の人に説明すると、それ自体を定式化するプロセスが新しいアイデアや事例を生み出します。 ペアテストは、コミュニケーションスキルを向上させ、同僚と効果的に対話する方法を学ぶための優れた方法です。 一部の人にとって、これはペアでの最初のテストでしたが、一部の人にとってはそうではありませんでした。 参加者がこの方法を自分の仕事に適用したいと願っています。







バグトラッカーについて



バグ追跡のシステムは、Youtrack Contourでは従来のものでした。 多くのテスターが最初にYoutrackを使用したため、システムの操作方法とバグの取得方法に関する短いビデオチュートリアルを用意しました。











バグ評価システムについて



計画によると、5つのチームが最も多くのポイントを獲得しました。 評価システムの例を示します。







バグトラッカーで2つのエンティティを作成できます。

タスク-システムを改善するための提案。 Tuskyは1点と評価されました。

バグ-製品の欠陥。 バグには、クラッシュ、メジャー、マイナーの別の優先度がありました。







クラッシュ優先のバグには、無限のロード、フリーズ、データ損失(入力または編集されたデータは保存されません)、デバイスの主な機能のブロックが含まれます。 このようなバグは20ポイントと評価されました。







主要なものには、非アクティブなボタンまたはリンク、編集不可のフィールド、予期しない実行結果、課されたレイアウト(作業の妨害)、データセキュリティ違反が含まれます。 このようなバグは10ポイントで評価されました。







マイナーなものには、タイプミス、課せられたレイアウト(作業に干渉しなかった)、誤ったアニメーション、有益なヒントは含まれておらず、問題は不安定でした。 このようなバグは5点で評価されました。











スラングについて



参加者は、モバイルアプリケーションの読み書き可能なバグレポートのスラング機能を受け取りました。 小さな例:







タップ -タッチスクリーンを短くタッチしてから削除します。

ダブルタップ -ダブルクリックに似た、指での短い2回のタッチ。

タッチは、タップよりも長いタッチです。

長押し -長押しします。 タッチはタッチよりも長いです。

Svayp(スライド) -画面上で指を連続的にスライドさせます。

トースト -アプリケーションウィンドウの表面に表示されるポップアップメッセージ。

Togleはステータススイッチです。

タイトル-タイトル画面のタイトル。

状態 -デバイスの状態、向き(縦または横)。







また、タップとスワイプの違い、トーストの切り替えと状態のタイトルの違いを思い出しました。







賞品について



テストセッションの結果に基づいて、最も多くのポイントを獲得した5つの勝利チームを選択しました。 サーキットはスポーツプログラミングの競技会を頻繁に開催するため、実績のあるスキームを選択し、ACM ICPCのような賞品を手渡しました。 賞品のある共通テーブルで、最もポイントの多いチーム、最初のチームが賞品を選択し、2番目のチームがポイントを獲得します-2番目など。











テストするのに最適なのは誰ですか



審査員が結果を要約している間、参加者は同僚とチャットしたり、ピザのおやつを食べたり、オフィスを見学したり、ゲームゾーンで時間を過ごしたりできます。











合計で、参加者は446件の報告を行い、そのうち349件はバグ、97件はタスクでした。











ry審は278件の報告を受け入れ、140件の報告を拒否しました。 説明できない、再現不可能な、または同じチームバグ内で繰り返される拒否。











受け入れられた報告のうち、215はバグでした。 これらのうち、118個のバグの優先度はマイナー、80-メジャー、17-クラッシュです。











これらはすべてのチームの統計であることを強調します。 215のレポートには、チーム間またはデバイスに依存するバグの繰り返しが多数あります。 したがって、アプリケーションを開発しているチームのバグトラッカーに移行した固有のタスクの数は23でした。







テストセッションの写真はすべてこちらにあります







TestHackathonChallenge



私たちは自分自身のために新しいトピックを試しました。 そして、彼らはモバイルアプリケーションでテストセッションを行いました。 みんなが気に入ったので、2018年も続けますが、目新しさを追加します。 次のテストセッションは年末に開催され、発表はブログに掲載されます。お見逃しなく!








All Articles