最近、当社はウェビナー「テスト メンテナンス: 機能テストの最も難しい部分へのプロのような取り組み」と題して、テスト ケースとテスト ステップのチェックリスト、テスト ケースのクリーン アップ、およびテスト レビューについて解説しました。
ここでは、あなたのチームとテスト スイートに利益をもたらす、効果的なテスト メンテナンス戦略を構築するための最重要ポイントをご紹介します。
創造から始まるメンテナンスの容易化
優れたメンテナンスは常に優れたテスト プランから始まり、より簡単なメンテナンスは作成から始まります。テスト プランをファイリング システムのように捉え、命名規則に基づいて検索することができます。
テスト プランには、テスト ケースとテスト サイクルが含まれるのが理想的です。テストサイクルには、ビルド情報、環境情報、および開始日と終了日を含める必要があります。
一方、テスト ケースには、以下のような項目のチェックリストが必要です。
- テストの命名規則の定義 – テストの命名規則に関しては、テスト ケース番号を含めることが必須です。さらに、コンポーネント、テスト対象のアプリやウェブサイトの領域も含める必要があります。
- テスト属性 – これらは、テスト ケースの目的や目標を説明する側面です。基本的には、テストで達成したいことを表現する形容詞であり、後に効率的なテスト スイートを作成するのに役立ちます。
- 優先度 – 優先度は、ビジネス上の重要性として捉えるべきです。つまり、アプリケーションの重要なワークフローへの依存性に対して、そのテストがどれだけ重要かということです。テストケースを「低」、「中」、「高」に分類すると言うのは簡単ですが、影響を与えるユーザーの数によって正当化することで、本当に優先度が高いものを理解するのに役立ちます。
- 説明文 – 最後に追加する説明文は、テストの機能性と目的を確認する必要があります。
- テスト データ – テスト データの再利用が可能な場合は、テスト ケースで使用されているテスト データを記載することで、将来的にモジュール式のテストを作成できるようになります。また、テストを実行するために必要なテスト データの種類も記載します。
- 前提条件 – 前提条件、つまりアプリケーションの前提条件は、チーム内では必ずしも理解されていませんが、バックエンドのデバッグ プロセスでは重要な意味を持ちます。
テスト ケースをさらに深く掘り下げていくと、テスト ステップのチェックリストが、従うべきいくつかのガイドラインの概要を示すのに役立ちます。テスト ケースに番号を付けるだけでなく、テスト ステップにも説明、期待される結果、実際の結果を記載する必要があります。
テスト メンテナンスに必要な No.1 のルール
テスト メンテナンスは一見簡単そうに見えるかもしれませんが、時間、労力、チーム ワークが必要なため、実施するのは非常に困難です。
そのため、テストを粒状にして独立させておくことが重要であり、それによってテストの実行頻度を高めることができます。テスト メンテナンスで問題になるのは、元々のテスト ワークフローにテストを追加しようとして、複雑になってしまう場合が多いです。
機能を追加しながらこのパターンを続けていくと、すぐに壊れやすくなり、メンテナンスが難しくなります。これは、あるテストの出発点を理解する唯一の方法がその前に実行されたテスト ステップを理解するからです。失敗した場合、その後に実行されるすべてのテストも失敗する可能性があります。
テストを結合して複雑なシナリオを作成すると、脆弱なテストが作成されるだけでなく、テストを個別に実行することができなくなります。言うまでもなく、自動化された UI テストは時間がかかることが多く、フィードバック サイクルを短縮するために小さなサブセットのテストを実行したい場合には、特に困難な障害となります。
さらに、以下のような技術がテスト メンテナンスに有効であることがわかっています。
- テスト ケースを作成する前に、エンド ユーザーの視点で設計し、それを考慮に入れる。アプリが誰によって使用されているか、機能が対応すべき要件は何かを考える。
- 命名規則など、効果的なテスト作成のためのベスト プラクティスに従う。全員が異なるプロセスを従っていては意味がないので、関係者の賛同を得られるようにする。
- テスト ケースだけではなく、ステップや必要なテスト データの詳細を説明する。テストに関連性を持たせるために、テストに含めるべきデータを指定する。
- 特に自動化では、新しいテストで同じ手順を再現する必要がないように、粒度の細かいテストに注力したいと考えていますが、再利用可能なテストを作成することが重要です。
テスト ケースのクリーン アップ
削除すべきテストは何かを考えれば、作成すべきテストも見えてきます。
以下のテストは削除候補とします。
- 重複したテスト – 念のため、コピー＆ペーストや同じものをテストすることがありますが、重複したテストはテスト スイートに必要なものではありません。
- 情報量の少ないテスト – テストが失敗し、十分な情報を提供していない場合や、あまりにも多くの操作をチェックしている場合は、テスト スイートにとって価値のあるものではありません。
- 信頼性の低いテスト – 欠陥のあるテスト、不安定なプラットフォーム、またはいつでもどこでも実行できないテストは、スイートに入れるべきではありません。
- 誤解を招くテスト – 常に合格するテスト、データ セットが変化するテスト、誤ったチェック、または不明確な命名規則などは、正確な情報を提供しません。
- 保守が難しいテスト – セットアップに時間がかかり、学習が困難で、実行時間が長く冗長なテストは、モジュール化して再作成する必要があります。
テスト レビューへの取り組み
コード レビューの利点はよく語られますが、テスト レビューもまた、テスト ケースが正確であること、理解しやすく実行しやすいこと、再現性があり再利用可能であることを確認するのに有益であり、同時にチームの時間とコストの節約にも役立っています。
テスト レビューを行うことで、チームは問題を早期に発見することができ、要件に対応しているかどうか、エンド ユーザーの視点からアプリケーションを見ているかどうかを理解することができます。
また、モジュール化やベスト プラクティスを適用するとともに、さまざまなアプローチに触れることで、チーム内での知識の共有を促します。
コード レビューと同様に、テスト レビューもアーキテクト、開発者、同僚など、さまざまな役割の人が参加でき、コミット前でもマージ後でも、いつでも実行することができます。
レビュー対象を決定する際には、可読性、パフォーマンス、他のシステムへの依存性、他のシステムへの影響、およびコンプライアンスなどを考慮する必要があります。チェックリストを用意しておくと、何をレビューすべきかの指針となり、非常に有益です。
さらなる学習
テスト メンテナンスについてもっと深く知りたいですか? オンデマンドでウェビナーの全容をご覧ください。
GUI テスト自動化製品 TestComplete の詳細は、こちら。
この資料は、SmartBear の Blog で公開されている「Tackling the Hardest Part of Functional Testing: Test Maintenance」の日本語参考訳です。
