よいリグレッションテストとは何なのか

リグレッションテストとは

ソフトウェアに対して変更を加えたとき、変更を加えていない箇所で期待通りのふるまいとならない事象をリグレッションと呼びます。 リグレッションテストは、このリグレッションを検知し、リスクレベルを低減するためのアプローチの一つです。

なお、リグレッションに対するリスクへの対処方法は、リグレッションテストだけではありません。 より実践的なアプローチは、goyokiさんのブログ「リグレッションテストの方針立て」の記事をご覧ください。

リグレッションテストの価値

リグレッションテストは、リグレッションが発生した場合のリスクを低減することを目的としたテストであるため、リグレッションを適切なタイミングで検知することができることが価値であると考えます。

リグレッションテストにまつわる課題

リグレッションテストを実施するためのリソースや時間が不足する

リグレッションテストは、一般的にリリース前の限られた期間で実施されることが多く、リソースや期間が不足しがちです。特に、組み込みソフトウェアのように、使用できるハードウェアの制約がある場合、このような問題が顕著になります。

言わずもがな、人手によるテストだけでなく、テスト自動化を活用することも重要ですが、テスト自動化によるスケールにも限界があります。*1

新しい機能を実装したときや、機能に変更を加えた場合の、リグレッションテストの追加基準が不明瞭

リグレッションテストは、一度作って終わりではなく、プロダクトのライフサイクルに合わせて、継続的に保守していく必要があります。 しかしながら、長い期間にわたって運用され続けているリグレッションテストでは、担当者の交代などによって、過去どのような経緯でそのテストケースを追加したのかがわからないという状況がしばしば発生します。

リグレッションテストが増え続ける

プロダクトライフサイクルの一部のフェーズ(衰退期)を除いては、新しい機能の開発や、既存機能の変更が続くため、リグレッションテストは増える傾向にあります。 また、リリース後に故障や障害が発覚し、ステークホルダからの要望により、リグレッションテストを追加するという状況も、残念ながらよく発生します。

よいリグレッションテストを実現するためのポイント

リグレッションのリスクを適切に評価し、ステークホルダと共有できている

リグレッションテストは、リスクベースドテストであり、リスクを適切に評価できていなければなりません。

一方で、リスクの評価手法には注意が必要です。 プロダクトや会社の信頼を大きく損なうリスク(例えば、利用者の生死に関わるリスクや、個人情報漏洩のリスクなど)は、発生頻度は低いものの、発生した場合の影響が甚大なものになります。 例えば、リスクの定量評価の手法の一つであるリスクの発生頻度と影響度を掛け合わせたリスクレベルの算定をした場合、判断基準によっては、リスクレベルが過小評価される懸念があります。

そして、事前に評価したリスクとリグレッションテストのスコープをステークホルダと共有することで、リグレッションテストへの理解を深めてもらう活動が重要だと考えています。

評価したリスクに対するリグレッションテストの追加基準が明確になっている

リグレッションテストは長きにわたって運用されるテストです。 そのため、担当者が交代した場合においても、前述のリスクの評価と、リグレッションテストの追加基準が伝わることが重要です。

テストの目的をトレースすることができる

テスト実行の効率化のために、一連のテストシナリオの中に複数のテスト目的が含まれている状況があります。 ただし、一つのテストシナリオに複数のテスト目的を含めてしまうと、作成者とは異なる担当者から見たときに、どのような目的でそのテストをしているのかがわからないという状況が起こります。

一つのテストシナリオに複数の目的を含めないというアプローチが理想ではありますが、実際のプロダクト開発の現場ではテストデータの準備に時間がかかるなどの理由で、テストシナリオを分割できないこともあります。

そのようなやむを得ないケースでは、テストケースの目的を明確にするために記述を追加し、その記述を継続的に保守していくことが重要です。

選択容易なテストになっている

毎回実装した全てのリグレッションテストが実行できればよいですが、先にも述べた通り、リソースや期間の制約で、全てのリグレッションテストが実行できない可能性があります。 このとき、テストの実施スコープを狭めて、リソースや期間に収まるように調整する必要が出てきます。 「想定していないリグレッションを検知するのがリグレッションテストなのだから、影響範囲を特定するのは難しいのでは？」と言われればその通りではありますが、システムが採用しているアーキテクチャや変更箇所、事前に洗い出したリスクなどの情報から、よりリスクの高い箇所に関連するテストをスコープに含めます。 このときに重要になるのが、テストの選択容易性です。

おわりに

AI Writingみたいな記事ですが、全部自分で書いたよ！（うそー！

で、アシカさんはもちろん完璧にできているんですよね？

アシカ「・・・・・」