リグレッションテストのテストケースを書く際の注意点

はじめに

新機能開発とは別に、サービス全体をカバーするリグレッションテストを定期的に行う必要があると考えています。なぜなら、以前QAとサードパーティツールとリグレッションテストで書いたように、内部で開発している機能に変更が無くても欠陥が発生する可能性もありますし、新機能開発の検証で見逃してしまった欠陥を定期的にテストを実行することで見つかる可能性があるからです。そしてそのなかでクリティカルな事象の発生を未然に防ぐことを目的としてリスクの高いものは一通り確認ができる必要があります。

以前書いたアジャイル開発におけるテストケースの書き方は、主に新機能開発のテストケースという観点で書いてみましたが、サービス全体のリグレッションテストのケースを書く際にはまた別の観点から考慮が必要だと思い、このnoteを書いてみました。割と細かいTipsのような内容になっていると思います。

どれくらいの頻度でテスト実行すべきか。

基本的にはリリースの頻度によります。リリースが2週間に1回であれば、2週間に1回やれば良いのではないかと思います。そしてできればコードフリーズしてからリリースの前の期間に行うことが望ましいと思います。

どれくらいの工数を使うべきか

2週間に1回の実行であればコードフリーズしてからリリースの直前に終わるように0.5〜1日（4〜8時間以内）で終わる量のテストケースを用意したら良いのではないかと思います。可能なら半分くらいを自動テストでカバーできれば良いと思います。

どういう内容であるべきか

サービス全体を大雑把にでも一巡するようなテストケースであるべきです。カスタマージャーニーマップのようなものがあればそれを参考にしてもよいかもしれません。ただ、プロダクトリスクの観点から検証項目を洗い出すべきだと思います。具体的にはお金の管理に関わるものは必ず検証して、そうではないもの（プロフィールの設定等）は検証対象から外しても良いかもしれません。

具体的テストケースか抽象的テストケースか

リグレッションテストについてはある程度要件も固まっていることが前提ですし、外部に委託する可能性もあるので具体的テストケースのほうが望ましいと思います。

テストケースの粒度

また、テストケースの粒度もある程度揃えておいたほうが良いとは思います。あるテストケースでは「Emailで会員登録できること」と1つのテストケースになっていて、別のケースでは「Emailを入力できること」「パスワードを入力できること」「ユーザー名を入力できること」と3つのテストケースに分かれていると管理しにくいです（進捗もわかりにくくなります）。私見では1アクション1ケース、すなわち上の例で言えば「Emailで会員登録できること」くらいの粒度がリグレッションテストには望ましいのではないかと思います。

おそらく新規開発であればEmailとかパスワードのValidationを細かくチェックするでしょうから後者のように1インプットごとに1ケースにすることが多いのではないでしょうか？そういう部分でもリグレッションテストと新機能開発のケースの作り方は違うと思います。安易な流用は効果的ではないと思います。

テストケースの独立性

テストケースを複数人分担することが考えられるので、どこから手を付けてもテストを実行できることが望ましいのではないかと思います。例えばテストケースが100件あったとして24番目のケースから実行することも51番目のケースから実行することもできる様になっていることが望ましいと思います。

もちろん、あるテストケースが一つ前のテストケースで完了したことが前提になっている場合もあるので、そういう場合は前提条件として記載したら良いと思います。例えばプロフィールを編集するという機能を検証するのであれば会員登録されていることが前提になっているかもしれないのですが、その前提条件は前提条件としてテストケースに記載しておいたほうが良いということです。そうしないといきなり会員登録してない状態でテストを開始して編集ボタンにたどり着かないということになります。