リグレッションテストの観点となる最有力候補とは？

ここ数年、品質に対する意識が高まっており、リグレッションテスト（または回帰テスト）の需要が増え続けています。しかしながら、何をテストすべきか想像できない方が多いようにも感じます。そこで本記事ではテストをすべき観点の洗い出し方法について解説いたします。

リグレッションテストって、何すればいいの？

リグレッションテストは、機能追加や不具合改修した範囲を逸脱して、本来影響しないであろう範囲も含めテストすることが求められます。そのため、範囲が膨大になりがちと言えます。しかしながら、コストの観点から言えば、すべての項目を実施することは現実的に難しいです。では、より費用対効果が高いリグレッションテスト範囲を選択し、より多くの不具合を発見することができるであろう範囲をどうやって絞りこんでいけばよいかを紐解いていきましょう。

皆さんに、リグレッションテストの観点を洗い出す３つのポイントをご紹介します。

【リグレッションテスト観点を洗い出す３つのポイント】

１．システムの要となるメイン機能は必ず含めましょう。

２．プロダクトリスクを洗い出してみましょう。

３．最低限の項目を洗い出すために、優先順位をつけましょう。

ポイント1・2で機能の洗い出しを行い、ポイント３で観点の絞り込みを行います。簡単そうに思えますよね。まずは何をテストしたらよいのか、書き出してみてください。そして、そこから篩(ふるい)にかけるわけです。膨大になりすぎたら、関係者で議論してみてください。そして、より良いものを選抜しましょう。

リグレッションテストを実施する理由

観点をあれもこれもと洗い出し、ケース数が膨大になりすぎると実施が負担になり、コストもかかりすぎてしまい、継続困難になってしまうはずです。まずは、前述した「観点を洗い出す３つのポイント」を念頭に、数日で終えられる現実的な分量まで絞り込んでください。その理由をご説明します。

1機能のパターンが増えすぎないように、まずは1機能1パターンがおすすめです。広範囲を網羅するためにはテストパターンの縮小が不可欠です。しかしながら、絶対ではありません。その機能の重要度やバグ発生率などを指標に理由付けができるものは増やしましょう。

指標や理由もなく増やすのは、’テスト数膨大路線へまっしぐら’ですので、まずは最低限から始めましょう。そして徐々にテストケースを更新していくことをお勧めいたします。

リグレッションテストの実施回数が増えると、バグ発見率が減る

リグレッションテストのテストケースは適切に更新していくことがとても重要です。リグレッションテスト開始早々はバグ発見率も高く、実施効果がみられることが多いのですが・・。実施回数が増えるにつれ、バグの発見率は低迷していくはずです。同じテストケースでは、バグを発見できなくなってしまうからです。

時がたつと、開発関係者内の意識が向上し、バグ発見率が低くなる傾向があります。それは、リグレッションテストの観点の代替わりを意味します。安定してきた機能からはバグが発見されにくくなるため、リグレッションテスト内の優先度は下がります。ですから、品質が向上した機能のテストパターンは縮小を検討しましょう。

その時々のメイン機能を十分に含めつつ、プロダクトリスクやバグの発見率を参照し、テスト実施が本当に必要な観点のみになるように更新してください。主要機能や不具合発生率の高い機能の最有力候補のテストケースは残しつつ、最近不具合が起きていないケースは縮小し、新たなケースに差し替えていくことをお勧めします。

新たなケースとしては、新規機能や不具合発生率が高いがまだ追加していないケースから選択し追加してください。システムも常に進化しているわけですから、当然といえば当然ですよね。リグレッションテストのテストケースも時折、追加・更新・削除を行い、適切にリフレッシュしていくように心がけましょう。

まとめ

まずは、最有力候補となる必要最低限のテスト観点を絞り、リグレッションテストのケースを設計しましょう。リグレッションテストは追加しすぎて膨大になりがちです。同じ期待結果が重複しないように可能な限り削減するように心がけましょう。そこから、徐々にケースを更新していくことをおすすめします。

もうこれ以上ケース削減できない場合、ケース１つ１つに優先度をつけ、「高」は必ず実施、「中」はできれば実施、「低」は実施しなくても良いという位置づけにしてみましょう。「中・低」のケースは余裕があるときの実施範囲拡大枠として残し、活用することもおすすめいたします。

時がたち、実施回数が増えてきたら、既存のケースからはバグが発見できなくなるでしょう。最有力候補のケースも最有力ではなくなり、世代交代が起こります。時とともに最有力候補が変わっていくことを念頭において、テスト計画をしてください。

これまで膨大になりがちな観点について絞りこみのポイントをお伝えしてきましたが、最後にお伝えしたいことがあります。バグ発生率が低減しない場合にはケースの削減ができません。しかしながら、ケースを削減できないと、機能拡張などでケースパターンが増える一方となり、実施負担が増大していきます。ケース削減ができず、絶対に実施したいケース膨大になってしまった場合にはテスト自動化をご検討ください。

テスト自動化は同じケースを何度も実行することでよい高い費用対効果を得られます。テスト自動化は新規機能に適用するよりも、バグを回避するためのリグレッションテストに適用すべきです。リグレッションテストのテスト自動化は本当にお勧めです。

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