テスト失敗率の追跡
モバイルアプリのテストが継続的インテグレーション(CI)環境で失敗する場合、通常はビルドも失敗していることを示しています。つまり、誰かがコードの変更や修正を行い、ビルドを再実行してテストをやり直す必要があり、これが繰り返されるサイクルにつながります。テストとビルドの実行中に他のタスクに切り替えたとしても、テストとビルドが完了して元のタスクに戻る際にはコンテキストスイッチが発生します。
テスト失敗率の重要性Click to copy link
モバイルアプリのテスト失敗率が高いということは、デバッグや修正、そしてテストとビルドの再実行と、その結果待ちに頻繁に時間を費やしていることを示しています。失敗率は、長時間かかるテストやビルドでは特に重要です。修正を行って新しいビルドとテストを実行する際に、エンジニアはさらに長く待たされることになるためです。
モバイルアプリのテストがどこで、なぜ最も多く失敗しているかを追跡・分析することで、チームはテストプロセスを改善し、時間の経過とともにより堅牢にすることができます。つまり、テストの失敗解決に費やす時間と労力が最小限に抑えられ、チーム全体の効率と生産性が向上します。
モバイルアプリの失敗したテストを追跡する主な目的は、開発プロセス全体における待ち時間を削減することです。頻繁に失敗するテストがある場合、遅かれ早かれそのテストと関連するビルドを待ち、問題を修正して、もう一度試す必要が出てきます。この繰り返しのプロセスの中で、1) コンテキストスイッチによって、または 2) そのテストとビルドの結果を待っている間は何も有益なことができないために、時間を失うことになります。
頻繁に失敗するテストを見つけるClick to copy link
Bitrise Insightsを開いたら、まずOverviewページのビルド失敗率チャートから、最も頻繁に失敗しているアプリとビルドを確認できます。テストのみに関心がある場合は、左側のサイドバーのEXPLOREセクションにあるTestsページに切り替えられます。
Testsページを開いたら、Failure rateタブに切り替えます。
すべてのTestsメトリクスページには、2つのチャートが表示されます。上のチャートには、設定したフィルターに対応するデータが常に表示されます。下のチャートは内訳チャートと呼ばれ、フィルターで絞り込んだ内容の1段階深いデータを表示します。
Workspaceにアプリが1つしかない場合、Insightsはいずれかの Explore ページを開いた際に自動的にそのアプリを選択します。ただし、Workspaceに複数のアプリがある場合、Testsページを開くと、上のチャートにはWorkspace全体のテスト失敗率が表示されます。これはworkspace内のすべてのアプリのテストスイート失敗率に基づいています。この例では、下のチャートに同じデータがアプリ単位で表示されます。これにより、どのアプリのテストスイートが最も多く失敗しているかが分かります。
実際の例を見てみましょう。内訳チャートでは、Workspace内で最も頻繁にテストスイートが失敗しているアプリケーションを確認できます。そのアプリに絞り込む と、テストスイートごとの内訳が表示されます。
上のチャートには、絞り込んだ内容が表示されるようになります。つまり、この場合は選択したアプリのテストスイート失敗率が表示されます。下の内訳チャートでは、どのテストスイートが最も頻繁に失敗しているかを確認できます。
そのテストスイートに絞り込んでみましょう。
上のチャートにはこの絞り込みが反映され、内訳チャートはブランチ単位の失敗率に切り替わります。グラフの下には、上部で設定したフィルターと、右上隅で設定したtime rangeの両方に基づいて絞り込まれたTest casesリストが表示されます。
このTest casesテーブルを使用すると、選択した期間、アプリ、テストスイートの中で、どのテストケースが最も頻繁に失敗しているか(Failure rate)、またはどのtest caseが最も多くの回数失敗したか(Failure count)を確認できます。
調査を続けるため、最も頻繁に失敗しているテストケースを選択します。
これにより、この特定のテストケースのみに焦点を当てるための関連フィルターが設定されます。その結果、上部のチャートにはこの特定のテストケースの失敗率の推移のみが表示されるようになります。
チャートの下では、Insightsのフィルターが自動的にRelated test case runsタブに切り替わります。
Related test case runsテーブルを使用すると、この特定のテストケースの過去の実行結果をすべて確認でき、各実行にかかった時間や成功したかどうかが分かります。右側のボタンを使用すると、該当するビルドのページや該当するテストレポートのページにすぐに移動でき、そこで調査を続けられます。
テスト失敗率を注視して改善することは、アプリ開発プロセス全体における待ち時間を削減し、チームの効率と生産性を向上させるのに役立ちます。