この記事はPeter G Walenによるゲスト投稿です。
回帰テストはときに苦痛です。遅くて実行しづらいこともあります。問題のもとにもなります。問題を把握して修正するのも困難な場合があります。しかも、これはまだ回帰テストを自動ツールで実行する方法や、反復的環境で実行する方法などに言及する以前の話です。
私は30年以上にわたってソフトウェア業界で働くうちに、「回帰テスト」とは何かという定義を何度も聞いてきました。念のためはっきりさせておくと、私の実用的な回帰テストの定義は次のとおりです。
回帰テストとは、顧客がソフトウェアを利用するにあたって中心的な機能で、過去3回のビルド/リリース/イテレーションで動作していたものが引き続き問題なく動作することを確認するためのテスト作業である。
以上です。回帰テストという概念を私はこのように捉えています。しっかりした学術的な定義もありますが、1990年代以降、私は大学では働いていないので、そういった定義は敬遠する傾向にあります。私の定義は長年にわたって実用に耐えています。
私は回帰テストまたは回帰テストスイートに何を含めるべきかをどのように判断しているでしょうか？簡潔な答えは、「何もかも入れようとしない」です。
私の記憶にあるかぎり、すべてのリリースのすべての側面を回帰テストスイートに含めるのが妥当であるようなケースはごく少数です。私は回帰テストについても、テスト自動化と同様の観点で見る傾向にあります―つまり、意味があることをします。
特定のビルドまたはリリースで使用された機能テストが製品全体の重要な成功要因となる領域を検証するものであるなら、たしかに回帰テストに含める候補になるでしょう。それ自体はさほど重要ではないが、製品内の他の重要なコンポーネントから使用されるコンポーネントを検証するものであれば、それも候補になるでしょう。
必ず回帰テストに含められるとは限りませんが、一部のマイナーな変更よりは、じっくり検討されるでしょう。
何もかもは含めない
回帰テストスイートに何を含めるかについて、大まかな基準をいくつか挙げました。ここで、私が「何もかもは含めない」と言うときの意味について説明しましょう。
私は、機能テストをそのまま回帰テストスイートに流用しようとする組織を見てきました。これが意味をなすのは、一握りの限られた状況だけです。ソフトウェアの同じ部分にちょっとした機能変更が入り、元のテストに加えて新しい機能テストが回帰テストスイートに入れられたとき、この戦略は崩れ去ります。
同じ機能に毎回変更が入るケースもあります。イテレーションごとに変わるものを回帰テストスイートに入れることに意味があるでしょうか？特定の状況では、あるかもしれません。実際にそんな状況を見たことがあるかどうかはあやしいです。
私が見てきて、そしてやってきたのは、作業する中で、重要で脆弱な領域を書き留めておくことです。「完了」時期が近づき、変更が少なくなってきたら、基本的なチェックのセットを構築し始めます。可能なすべての組み合わせを検証する必要はありません。それは機能テストですでにカバーされています。
機能の主要な点に焦点を当てます。変更やフローの詳細は、見かけほど重要ではありません。
これは安全なアプローチでしょうか？あまり安全には聞こえませんよね。
次のように考えてみてください。機能がイテレーションごとに変更されるなら、そのようなマイナーな変更に合わせて回帰テストを変更することに意味はあるでしょうか？次のイテレーションのテストで機能テスターによって検証される可能性が高い場合、回帰テストの変更はその時間と労力に見合うでしょうか？
さらに「何もかもは含めない」
詳細な機能テストでは、ドロップダウンリストの内容を検証する必要があるかもしれません。実際、多くの場合、リストを検証する必要があります。これは、たとえば要素が数個だけなら、完全に意味があるでしょう。要素数が15や20を超えると、たいていの人は、実際のリストの内容をそれほど注意して見ないのではないでしょうか。
ドロップダウンリストの要素数が100を超えたら？どうでしょうか？内容を1行1行調べていく人もいるかもしれません。たいていの人は、おそらく公式のソースとドロップダウンリストの内容を見比べるでしょう。項目の数が同じであれば、「問題なし」と宣言するでしょう。
1100以上の項目があるドロップダウンについては言わずもがなです（そういうものを私は実際に見たことがあります）。
回帰テストを実施するとき、そういったテストは回帰テストに含められる「資格がある」でしょうか？おそらくないでしょう。値を選択するドロップダウンがあるなら、選択して先に進みます。通常、そうしたドロップダウンはDBのテーブルから値を持ってきています。私の経験では、内容が変化した場合は、環境の問題のせいであるか、ときには誰かが「ただのテスト環境だから」というのでデータをめちゃくちゃにした結果でした。
ソフトウェアの機能にとって重要なものに集中しましょう。細かな技術的詳細は、機能テストで検証するべきです。ソフトウェアの基本的な有用性を見るべきときに、こういった詳細を検証するテストの設計に時間を取られてはいけません。
以前は150個の要素があったドロップダウンに3つの値しかなかったら、尋ねてみるのがよいでしょう。すべてのドロップダウンを検証するのに時間と労力を費やすのは？おそらくそれほどの価値はないでしょう。
でも、これはどうなのですか……
そうですね。プロダクトオーナーやプロダクトマネージャー、あるいはビジネスから見た製品の機能を管理する立場の誰かにとって本当に重要なものもあるかもしれません。そういったものについては、議論と評価が必要です。毎回手動で行う必要がある作業の量を説明しましょう。テストを自動化するスクリプトを作成し、実行するのに必要な労力を説明しましょう。
なにより、機能テストで新機能をテストするために、どのみち行う必要があることを説明しましょう。これらは考慮に入れられているでしょうか？必ず議論に含めましょう。
回帰テストで検証するためのコストが、ビジネス面で得られるテスト対象機能への信頼に見合うなら、回帰テストに含める意味があるかもしれません。ここで重要なのは、回帰テストの実施にかかる労力とコストについて議論することです。変更がない機能を繰り返し繰り返しテストする労力、時間、コストは、他の機能を回帰テスト作業に追加することの価値よりも大きいでしょうか？
それなら、これはどうなのですか……
顧客、すなわちソフトウェアを実際に利用する人たちのニーズにとって重要な機能もあるでしょう。これも議論と評価が必要です。そうすることで、「回帰テスト」の一番の目的に近づくことができます。
以前のビルドから引き継いだ機能をテストすることは重要で、大きな意味があります。多くの組織が見落としているのは、「このソフトウェアは依然としてビジネスニーズを満たしているか？」という点です。
私たちはニーズを満たしていると信じたいのです。いくらかでも確かにするには、作業対象のソフトウェアの背後にある動機から焦点を逸らさないようにする必要があります。機能の断片をすべて組み合わせた全体としては、何を行っているのでしょうか？
私が正式な「回帰」テストを構築するときはいつも、さまざまな状況を勘案して上記のような疑問に対処します。私はソフトウェアを使用して作業する人たちが期待する論理的フローに着目します。そうすると、そのようなフローを中心としてスクリプトを構築し、ユーザーが頻繁に遭遇するバリエーションを含めることができます。
そうしたスクリプトは、フローを通して作業するメンバーによって検証可能です。フローをスクリプト化し、テスト自動化プラットフォームに合わせて調整できます。各フローを評価し、ソフトウェアを使う人たちのニーズやソフトウェアの変更が対処するビジネス上の問題に対応するようにフローを構築します。
こうすることで、ソフトウェアの変化に合わせて適応し、変化できる、意味のある回帰テストスイートを構築できます。変更はどれも同じではありません。顧客にとって最も重要なビジネスフローの回帰テストに焦点を当てましょう。
Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。
（この記事は、開発元Gurock社の Blog 「Building Meaningful Regression Test Collections」2020年9月30日の翻訳記事です。）