2018年8月24日 / 最終更新日時 : 2020年9月3日 user 事例・ソリューション

テスト自動化における 10 のベストプラクティス #2: 回帰テストを始めよう

ソフトウェアのリリースサイクルの中で、一般的にQA（品質保証）担当者は、以下の項目において、テストを実施します。

リリース固有のテスト: テスト対象アプリケーション (AUT) の新機能を検証します。
欠陥修正の検証テスト: レポートされた欠陥が修正されたことを検証します。
回帰テスト: 回帰テストは「新しい欠陥が入り込んでいないか」および「古い欠陥が再発していないか」を検証します。そのため、検証には、以前のリリースサイクルでテスト対象アプリケーションが合格したテストケースを使用します。

前回の「#1: 何を自動化するか」では、テスト自動化に適したテストケースについて紹介しました。これに該当するのは、「安定した機能テスト」と「データ駆動型テスト」です。回帰テストはこれらの条件と合致するため、はじめに自動化することをお勧めします。以下のセクションでは、回帰テストを自動化するためのベストプラクティスについて説明します。

重要度の高い回帰テストケースからテストを自動化する

すべての回帰テストケースが同じ重要性を持つわけではありません。自動化の対象として、以下の回帰テストを中心的に取り組みましょう。

スモークテスト

スモークテストでは、テスト対象アプリケーションの新しいビルドに対して、基本的な機能が動作していることを検証します。このテストは、アプリケーションの起動、ログイン、ウェルカム画面の表示、新規データの取得といった操作をアプリケーションが実行できることを確認します。スモークテストを自動化することで、常に、新しいビルドに対して、テストが実行できるようにしましょう。これにより、テストにさらにリソースを投入する前に、ビルドが「良い状態」であることを確認できます。

サニティテスト

サニティテストでは、アプリケーションで最も重要な機能を徹底的にテストします。たとえば、ECサイトをテストする場合、ユーザーがログオン、アイテム検索、買い物かごへの追加、チェックアウトができることを検証します。このテストに、優先度が高いすべての機能、変更された機能/モジュールが含まれることを確認してください。

価値の高いテストケース

価値の高いテストケースとは、過去のリリースサイクルにおいて、欠陥が発見されたテストケースです。価値の高いテストケースを回帰テストに追加することで、「新しい欠陥」や「過去に見つかった欠陥」が検出される確率が上がります。

保守できる回帰テストにする

ある種のプラクティスは、自動化テストの保守性を高めます。これは、回帰テストだけでなく、その他すべての自動化テストに適用されます。重要なことは、可能な限り自動化テストをモジュールにし、互いに独立させることです。保守性が下がるため、テストケース間でコードをコピー&ペーストしてはいけません。たとえばログイン処理などのモジュールを再利用するには、独立したモジュールとして作成します。これにより、ログイン処理が変わっても、更新するモジュールは 1 つで済みます。もうひとつのベストプラクティスは、各テストケースにおいて、UI要素（テスト対象アプリケーションのオブジェクト情報（XPathなど）の定義を、アクションステップ（アプリケーションの各操作（ボタンクリック、データ入力など））から切り離すことです。また、テストデータをハードコーディングしてはいけません。テストデータはスプレッドシートやデータベースで管理すべきです。（保守性については、本シリーズの今後の記事でさらに詳しく紹介します。）

すべての回帰スイートの実行は、必要な場合のみにする

新規ビルドのたびに、すべての回帰スイートを必ずしも実行する必要はありません。マイナーリリースであれば、「スモークテスト」と「変更されたモジュールの回帰テスト」を実行した方が合理的でしょう。これを実現するには、各テストがカバーするテスト対象アプリケーションのモジュールに従って、回帰テストケースをまとめることです。

たとえば、あるリリースでオンラインストアが受け付ける支払いの種類だけを変更した場合、回帰テストが必要なのは支払い処理だけかもしれません。(アイテム検索や買い物カゴへの追加といった他の機能は回帰テストから除外します。)また、新しい言語のローカライズなど、アプリケーションに大幅な変更があった場合は、完全な回帰スイートを実行するのが合理的でしょう。特定のリリースサイクルに合わせて回帰テストケースを優先度付けする方法については、「Regression Testing Guide (英語)」を参照してください。

開発ツールチェインを活用する

自動化された回帰テストは、開発コードと同様に扱うことができます。そのため、自動化された回帰テストを開発コードのように扱うとともに、既存の開発環境を活用しましょう。

ソース管理を使用する

GitやSubversionといったソース管理システムの目的は、複数の開発者が、お互いの変更を上書きすることなく、同時に同じアプリケーションに対して作業できるようにすることです。また、ソース管理システムを使用することで「正しいバージョンの回帰テスト」を「対応するアプリケーションのバージョン」と合わせて管理できます。

CIプロセスと統合する

開発チームが継続的インテグレーションプロセスに従っている場合、CI環境に回帰テストを統合することにより、回帰テストを自動化することができます。

バグトラッキングシステムと統合する

JIRAやBugzillaといったバグトラッキングに用いられるツールは、欠陥をレポートする上で、そして解決に至るまで欠陥を追跡する上で重要です。欠陥を自動的にレポートするように回帰テストを構成しましょう。また、バグトラッキングプロセスを利用して、手動テストで発見された欠陥とその再現方法を文書化しましょう。次の開発サイクルでは、この文書が新しい回帰テストケースの候補を提供するでしょう。

回帰スイートの数を管理する

通常、リリースサイクルごとに新しい回帰テストケースが追加されます。回帰スイートの増加にともない、テストの実行に大量のリソースが必要となります。エンハンスされるアプリケーションに合わせて増加する回帰テストを最新の状態に保つのは、多くの負担を抱えることになります。これを防止するためには、管理できる範囲内に回帰スイートの数を抑えることです。そのためには、リリースサイクルごとに、テストプロセスに貢献しないテストケースを削除しましょう。たとえば、「古い機能のテスト」や、「テスト対象アプリケーションで省略し続けている、優先度の低いテスト」などは削除しましょう。また、新しいテストケースについては、テストプロセスの価値を高めるかどうかを慎重にレビューしましょう。価値を高めるテストケースとは、たとえば、前回のリリースサイクルで欠陥の発見に成功したテストや、重要な新機能を試験するテストです。

回帰テストの限界を意識する

回帰テストが問題なく完了している場合でも、そのテストが、新しい欠陥を発見できていない可能性はあります。

回帰テストの目的を思い出してください。回帰テストの目的は、「コードの変更によって、古い欠陥を再び挿入していないこと」や、「過去に問題のなかったコードに新しい欠陥を挿入していないこと」を保証することです。すべての回帰テストが成功しているという事実は、必ずしも、新しい機能にも問題がないということを示しているわけではありません。回帰テストを自動化する大きなメリットのひとつは、手動テストの担当者が、新機能の探索的テストとユーザーエクスペリエンスの向上に集中できることです。

（この記事は、開発元 Ranorex 社 Blog 「10 Best Practices in Test Automation #2: Start With Regression Tests」2018年4月24日の記事を元にしています。）