2019年4月1日 / 最終更新日時 : 2021年6月29日 user 事例・ソリューション

テスト自動化における 10 のベストプラクティス #6: 失敗するテストケースの解決

はじめに

安全で保守が可能になるように入念に設計されたテストケースであっても、「テストの失敗」は起こりえます。「テストの失敗」には複数の解釈があるので、まずその違いを見てみましょう。

失敗を期待するテストケース

不正なパスワードなど、テスト対象アプリケーション (AUT) からエラーを返すことを期待するテストケースです。このタイプのテストケースは、期待されるエラーメッセージを返す場合に「成功」となります。

アプリケーションの欠陥を発見するテストケース

これは成功するテストケースです。なぜなら、欠陥を発見することはソフトウェアテストの主な目的の1つだからです。このタイプのテストケースは回帰テストに含めることを検討しましょう。

アプリケーションの機能に無関係な理由で失敗するテストケース

この記事で使用する「失敗したテストケース」とは、これを意味します。テストケースが失敗する場合に最初にすべきことは、以下について確認することです。

テスト対象アプリケーションの欠陥によってテストケースが失敗したのか？
不正または無効なテストデータなど、テストケース自体に問題があるのか？
テスト環境に問題があるのか、それとも欠陥ではないテスト対象アプリケーションでの変更に問題があるのか？

テストケースが失敗した原因がすぐに分からない場合、アプリケーションの欠陥を報告する前に、テストケース自体のトラブルシューティングが必要かもしれません。「失敗したテストケースを再実行して、成功するかどうか確認すれば良い」と思う人もいるでしょう。しかし、ある時には成功し、ある時にはこれといった理由なく失敗するテストケースは「フレーキー (Flaky：不安定)」で信頼できないテストケースであり、失敗の原因である問題を解決して、テストの結果を信頼できるようにすることが重要です。

デバッグを補助するようにテスト実行を構成する

本シリーズの「第3回メンテナンス可能なテストを作成する」では、以下にあるような、より安定した失敗しにくいテストケースを設計するためのベストプラクティスをご紹介しました。

できる限りテストケース間の依存関係を排除すること
安定したテスト環境を用意すること
失敗が期待されるテスト (未解決の欠陥のテストなど) をテスト実行から除外すること

上記以外にも、失敗が起こったときにスクリーンショットを取るようにテストケースを設計するのも有用です。これらの推奨事項に加えて、必ず失敗を適切に処理するようにテスト実行を構成しましょう。失敗によってテスト全体を停止するのは、本当にそれが正しい状況である場合だけにしましょう (たとえば、アプリケーションが起動に失敗したりスモークテストが失敗したりする状況です)。また、本当のエラーと失敗だけに的を絞って、テスト実行レポートのサイズを管理することも重要です。

※Ranorex には「デバッグ」「情報」「警告」「成功」といった定義済みのレポートレベルがあります。大規模なテスト実行では、このレベルのレポート情報が大量に作成されることがあります。レポート結果を「エラー」および「失敗」レベルだけにすることを検討してください。そうすることで、本当に解決が必要な問題を特定しやすくなります。

問題を切り分ける

失敗するテストケースの数が多い場合、環境、テストフレームワーク、テスト対象アプリケーションの問題を探しましょう。

環境

環境に関する問題として、以下の問題について確認しましょう。

必要なサービスが実行されていないこと
必要な場合に管理者モードで実行されていないこと

テストフレームワーク

テストフレームワークに関する問題を探しましょう。
たとえば、ライセンスエラーや適切に構成されていないリモートエージェントなどです。

テスト対象アプリケーション

テスト対象アプリケーションが正しく準備されているかを確認しましょう。
ロケーション固有のシステム設定や誤ったブラウザーバージョンの問題のほか、異なるシステム言語といった問題すらありえます。あるいは、ユーザーインターフェイスをブロックする保留中のOSアップデートがあるかもしれません。

テストの実行において、ほとんどのテストケースが成功した場合、失敗した個々のテストケースに問題がないかを疑いましょう。問題の原因を示すエラーメッセージがあるかもしれません。また、エラーメッセージがない場合に、テストケースがたまたま失敗したと考えて、テストケースを再実行してはいけません。

テストの失敗はすべて理由があって発生します。成功したように見えるテストケース、または理由もなく失敗するテストケースは「フレーキー (Flaky：不安定)」なテストです。
問題の原因を探るために、以下のチェックリストにて考えられる原因を確認してください。

失敗したテストケースをトラブルシューティングする

以下のチェックリストを確認して、失敗したテストケースを 1つずつトラブルシューティングしましょう。

テスト対象アプリケーションに対してテストケースが最新になっているか？（たとえば、UI 要素の変更に対してテストケースが更新されているなど）
入力データは正しいか、テストで利用できるか？
すべてのパラメーターを正しく設定しているか？
期待される結果は有効か？（たとえば、テストケースが 1 つの有効な結果を期待しているが、複数の有効な結果を返すことがあるなど）
問題を引き起こしたかもしれない以前のテストケースとの間に依存関係が存在しないか?（※1）
最新のテスト実行のティアダウンは正しく動作したか？
テスト対象アプリケーションは正しい状態にあるか？（たとえば、すべてのブラウザーウィンドウが閉じている、または最後のテスト実行で入力されたデータは、すべて削除またはリセット済みであるかなど）
タイミングの問題はないか?

※1. この状況を避けるには、本シリーズの「第3回メンテナンス可能なテストを作成する」で説明するように、テストケースを互いにモジュラーで独立したものにすることです。

※2. イリノイ大学アーバナ・シャンペーン校によるフレーキーテストの調査によると、多くの場合、フレーキーテストの原因は非同期の待機です。期待される結果をテスト対象アプリケーションが十分に早く返さないために、テストが失敗します。この場合、テストケースが不必要に失敗しないように、テストケースのステップに待機時間を追加する必要があるかもしれません。Ranorex での待機時間の動作については、「Ranorex ユーザーズガイド（UI 要素の待機）」の章を参照してください。

デバッグツールを使用する

失敗するテストケースの解決に役立ちそうなツールがあるなら、それを活用しましょう。

※Ranorex（Ranorex Studio）には失敗したテストケースのトラブルシューティングを補助するツールが用意されています。

デバッガー

デバッガーを使用すると、ブレークポイントを設定して、失敗したテストケースをステップ実行し、変数の値と各ステートメントの式を検証できます。

メンテナンスモード

メンテナンスモードを使用すると、テストを実行しながら、失敗したテストケースを修正できます。詳細については本Blogの記事（Debug Tests Quickly with Maintenance Mode）を参照してください

リモートテスト

これは、仮想マシンなどのテスト環境で発生したテストケースの失敗をトラブルシューティングする上で非常に有用なツールです。

テスト対象アプリケーションを正しい状態にするため、リモートテスト機能である「Ranorex Agent」を使用し、失敗が発生した直前までを実行するようにします。そして、本Blogの記事（How to Reconstruct Failed Test Cases in CI Systems）にあるように、テスト環境にて、失敗したテストケースをトラブルシューティングします。

失敗したテストケースを解決する時間を取り、失敗から学ぶことは、テストスイート全体の信頼性を向上する上で役立ちます。

（この記事は、開発元 Ranorex 社 Blog 「10 Best Practices in Test Automation #6: Resolve Failing Test Cases」2018年5月25日の記事を元にしています。）