リグレッションテストの適切な範囲の見極め方！必要最小限で最大の効果を出す方法

近年、開発手法はウォーターフォールモデル開発からアジャイル開発が主流になってきました。小単位で開発を繰り返す手法であるアジャイル開発では、リリースするたびにリグレッションテストを実施していくことはとても大切です（詳しいアジャイル開発手法は本記事では割愛いたします）。もちろんウォーターフォールモデルにおいても、テスト実施による不具合改修が行われた際に実施するリグレッションテストも必要です。

本記事では、第三者検証企業の受け入れテストフェーズにおけるリグレッションテストの適切な範囲について解説していきます。

リグレッションテストはどこまでやるの？

リグレッションテストとは、「プログラムの変更に伴い、システムに予想外の影響が現れていないかどうかを確認するテスト」のことです。予想外の影響がないことを確認するためには、搭載されているさまざまな機能について確認する必要があります。

すこし話が横にずれますが、ソフトウェアテストの7原則※の一つに「全数テストは不可能」というものがあります。「全数テスト」とは、ソフトウェアに入力する可能性のある、すべてのパターンをテストすることです。テストエンジニアなら、これを聞いただけでも、「そりゃ、数多すぎ。全部テストケースを作成するのも実施するのも、無理だわ」と直感でわかると思います。

※ISTQBテスト技術者資格制度 Foundation Level シラバスに記載されている、ソフトウェアテストを行う上で共通して理解しておく必要がある一般的なガイドラインのこと

全数テストは無理だとしても、可能な範囲でより多くの不具合を検出できるよう最大限効率よくテスト設計されるべきです。そして、作成されたものがテストケースとなります。

リグレッションテストでは、このように様々な状況を考慮して作成したテストケースの中から、さらに絞りこんでテストを実施します。時間も、お金も、人手もあるのであれば、変更のたびに作成したすべてのテストケースを再実施するフルリグレッションテストを実施してみましょう。しかし、そのような恵まれたプロジェクトは稀で、現実にはほぼ存在しないでしょう。(少なくとも私はお目にかかったことがありません)

たいていは、「そんなかかるの？」、「もう少し短期間で完了できない？」、「リグレッションテストに割ける日数は●日しかないから」 などといったことを言われるのではないでしょうか。

そんな日数ではできない！と、交渉しようにも、「リグレッションテストの重要性はわかっている、だけど、リリース日は決まっている。開発チームも一生懸命修正してくれているけれども、それでも修正数が多い、思ったより複雑、修正範囲が広い・・」などの、さまざまな事情で結局想定以上に少ない工数しかもらえないケースがあると思います。

このように、工数に制限がある状況下で実施するリグレッションテストにおいて、どこまでやるの？と聞かれた場合何と答えればいいのでしょう。「与えられた工数内で、実施可能な範囲をテストする」という身も蓋もない結論が着地点となります。

では、工数がなかったらリグレッションテストはやらなくてもいいのか？と聞かれれば、そんなことはありません。与えられた条件の中で、リスクを考慮しながらどこまで範囲を絞るのか、を考えていく必要があります。

テスト範囲が漏れていた場合のリスク

「プログラムの変更に伴い、システムに予想外の影響が現れていないかどうかを確認するテスト」がリグレッションテストです。しかし元々テスト実施で確認OKとなっていた機能で不具合が作りこまれ、結果市場へ不具合が流出することがリスクとして挙げられます。

「元々テスト実施で確認OKとなっていた機能で不具合が作りこまれ」、この部分にリグレッションテストの怖さがあります。不具合流出という点においては、通常のテストでも挙げられるリスクですが、1度は正常に稼働すると確認できた機能から不具合が出た場合、通常の検出時のフローよりも時間がかかります。いつのタイミングで作りこまれた不具合なのか？そもそも最初のテスト結果は正しかったのか？など、ただ検出したときよりも確認作業にも時間がかかるのです。

そして、リグレッションテストの範囲から漏れていた状況により、当該リグレッションテストの実施時点では検出できなかったことが分かったとしましょう。設定したテスト範囲としてそもそも正しかったのか、他にも足りていないテストはないか、という疑問も出てきます。こういった心理的な負担もリグレッションテストの範囲が漏れていた場合におけるリスクと言えます。

必要範囲を適切に抽出する方法

リグレッションテストでは、様々な要因で想定していた工数よりも少ない工数でテストを実施することが多々発生します。なぜなら、繰り返しになりますが、お金も人も余裕がないケースが多いからです。

そのため、リグレッションテストでは必要な範囲を適切に抽出することがとても大切です。

では、必要な範囲とはどのように選択すればよいでしょうか。

【実施必須】

「プログラムの変更に伴い、システムに予想外の影響が現れていないかどうかを確認するテスト」がリグレッションテストであるため、プログラムの変更が入った機能に関しては、そもそも仕様通りに動くのか？というテストは必須です。これは、どんなに工数がないから！と言われても削ることはできません。

【実施推奨】

実施推奨としては、変更機能そのものではなく、関連がありそうな機能をリストアップします。例えば、変更した機能のデータを利用するような機能が挙げられます。変更した機能のデータとうまく連携ができているか？データの持ち方、利用先に考慮漏れがないか？など、ミスが発生しやすいであろう機能を推測して対象とします。

推測と書くと、属人化してしまいそうではあります。しかし開発担当より提供された基本設計書、詳細設計書、そのほかの開発資料、またテスト設計段階で作成した画面遷移などを活用して、それぞれのつながりを把握しましょう。そうすることで担当者によって大きな差異がでることなくリストアップできるはずです。

余談ですが、私はリグレッションテストの範囲を選定する際に、「実施必須のテスト」「実施推奨のテスト」以外に、さらに２段階の優先度「あわよくば実施に含めたいテスト」「とっても余裕があればやるテスト」を設定、分類します。

必要範囲を洗いだす作業はとても大事ですが、希望した通りに実施できることはとても少ないため、範囲の洗い出しと同時に優先度もつけておきます。

そのうえで、お客様とリグレッションテストをどこまで実施するか？を相談させていただき、実施しない場合のリスクと実施した場合の工数と天秤にかけて調整していきます。

リグレッションテストにおいては、この実施範囲の調整がとても大事です。万が一テスト範囲から漏れていた場合に、リスクと工数を天秤にかけて調整したことが分かっていれば慌てずにすみます。また、振り返り時にも自分が設定した優先度が適切であったのか、確認することができ、その後のプロジェクトに活かせますよ。

まとめ

「リグレッションテストの適切な範囲の見極め方！必要最小限で最大の効果を出す方法」と題しまして、ご紹介してまいりました。リグレッションテストは、フルリグレッションテストを実施する機会はまず発生しないということを頭に入れて置く必要があります。

そのうえで、人が足りない、リグレッションテストを実施できる期間が短い、テスト対象機器が不足している、そもそも工数が足りないなど、様々な制約がある中で、効果的なリグレッションテストを実施しましょう。そして「範囲を抽出する」「優先度を設定し、リスクを考慮しながら実施する範囲を決定する」というテスト戦略が必要です。

開発資料、テスト設計で作成した資料などをフル活用し、「どの機能に変更が入ったか？」「関連する機能はどの機能か？」を細かく確認しながら、リグレッションテストの範囲設定にチャレンジしてみてください。

誰でもカンタンにテスト自動化ができる時代は、すぐそこまできています。当サイトでは、テスト自動化ツールに興味のある方へ、「テスト自動化　推進ガイドブック」と「テスト自動化ツールT-DASH 基本ガイドブック」のダウンロード資料をご用意しております。ぜひダウンロードいただき、資料をご覧ください。

---