リグレッションテストの書き方のコツ

サービスを提供し続けることが一般的になってきた中、新機能の追加や不具合の修正などプロジェクトではスピードを求められる現場が多いのではないでしょうか。そして、スピードを上げつつ品質も維持していくのは難しく感じているのではないでしょうか。

新機能を出したら出したで、既存の機能が動作しなくなった、不具合修正したら他の機能で不具合がでたなど、様々なケースがあります。

そこでリグレッションテストをこれから始めよう、または既にやっているけど毎回納期が遅延してしまうといった方に向けて「リグレッションテストの書き方のコツ」を解説していきたいと思います。

リグレッションテストの目的とは？

アプリケーションやサービスを提供していると、新しい機能を追加したり、不具合を修正したり、プログラムの修正が入ります。プログラムを修正することで、変更された箇所以外に意図していない影響（デグレード）がでて、今まで正常に動作していた箇所が動作しなくなるケースがあります。リグレッションテストはこのような意図していない影響がでていないことの確認を目的としています。

リグレッションテストの書き方ってコツはあるの？

理想はすべてテストをすることができればいいのですが、開発現場では短納期での開発や緊急対応が必要な改修が発生します。このような時は、テストの期間を多く割くことができない場合がよくあります。ただ、テストの期間はとれませんが、品質の低下は防がなければなりません。そのため、短納期でも実施できるリグレッションテストの書き方のコツを3点ほど紹介します。

【リグレッションテストの書き方　３つのコツ】

１．実施範囲を決める

1点目は「実施範囲を決める」ことで短納期の場合で最低クリアするべきテストを検討します。前述したように、テストの期間を割くことができない場合、常にすべての機能のリグレッションテストの実施は困難です。そのため、以下のように重要度を考慮して実施範囲を絞り込んでいきます。

• 人命やお金にかかわる機能などリスクの高い機能
• 利用者がよく使用する機能
• 修正箇所の影響範囲から関係のある機能
• 過去に何度も修正されている機能

２．簡単でいいので1回は各機能を通す

2点目は「簡単でいいので1回は各機能を通す」ことです。

実施範囲を絞り込んでも、できれば各機能を1回は通すようなテストの構成にしていたほうがいいでしょう。例えば、新しく画面を追加し、新しい画面は問題ないことが確認できたが、既存の画面を開くことすらできなかった・・、というような状態がありえるためです。

３．テストケースの粒度を合わせる

3点目は「テストケースの粒度を合わせる」ことです。

納期が短いとリグレッションテストは1人ですべてのテストを実施することは困難です。そのため、複数人で並列的にテストを実施できるようにしておく必要があります。粒度を合わせておけば、どのテストケースから始めてもテストできますし、計画段階で期間内に収まらなくても、途中から何人人員を増加させればいいのか、などの判断ができるようになります。また、自動化する際には、粒度を合わせていると、どこからでも自動化に着手できます。

リグレッションテストの書き方のコツとして伝えたいポイントは、リグレッションテストはだれが見て、どこから着手しても同じようなテストができるように作成することです。テストの人数を増やすことや、自動化ができる内容になるため、テストの短納期に対応できる仕組みを入れやすくなります。

リグレッションテストを自動化する

企業や開発チームによって、リグレッションテストにかかる工数は変わりますが、大事なポイントをお話します。リグレッションテストを実施するタイミングは、できれば単体テスト、結合テスト、システムテストなど各工程で実施できれば、開発行程の中で解決できます。そうすることで、ある程度品質が担保された状態でテストを実施できます。

また、不具合は上流工程で減らすことができれば、プロジェクト全体のコストを下げられます。開発時には何度もリグレッションテストを実施すれば、自動化によるテスト工数が削減できます。そして手動で絞り込んで実施していたテストを毎回すべて実施できるため、品質の担保を行えるメリットもあります。

そのため、まずは一つでもいいので自動化して、徐々に拡充していくことをお勧めします。

ただし、リグレッションテストを自動化する対象範囲は、一気にすべてをやる必要はありません。テストケースを書いている最中にも開発コードは日々変化しています。一気に自動化するコードを書いている間に、動かないテストケースがでてきてしまうことがあるので対象範囲には注意しましょう。

一気に自動化してしまうと、そこで燃え尽きてメンテナンスするチームの仕組みが出来上がりません。メンテナンス不能なテストコードになってしまうかもしれません。自身のチームに沿ったやり方を見つけながら、チームで自動化し、テストコードを書く文化がチーム内に浸透していくように進めていきましょう。

自動化に向いているのは単体テストや、手順が多くミスが発生しやすいテストです。まずは小さな単位で導入に失敗しないよう進めないと、メンテナンス不能なコードは自動化されていても、コストが膨らんでしまいますので注意してください。

まとめ

「リグレッションテストの書き方のコツ」と題しまして、ご説明してまいりました。ソフトウェアの品質はリリースしたら終わりではなく、維持してしくみ作りにしてさらに良くしていく必要があります。

リグレッションテストは今後の開発現場においては必須だと考えられます。今回の内容はリグレッションテストを書く際の考え方として、まずリグレッションテストとはなにか、リグレッションテストのテストケースの実施範囲の決め方、どこまでテストする必要があるのかをご理解いただけたと思います。そして、自動化に向けたテストケースの書き方について解説をしてきました。

本記事ではリグレッションテストの書き方のコツとして筆者の経験を元に書いているため、足りないところもあると思います。ここまで読んでいただいた方はぜひこの機会にリグレッションテストを始めてみてください！

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