PR

 年に数回システム改修を実施しており、そのたびにリグレッションテスト(変更により、ソフトウエアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するテスト)を実施している。毎回同じようなテストを実施するので、過去のテストケースを使い回して効率化したいと考えている。しかし、思うように再利用できず、毎回のように同じような内容のテストケースを作成している―――。開発現場でよくある光景だろう。

 新規開発したときのテストケースや直近の改修で作成したテストケースなど、過去の案件のテストケースに多少手を加えるだけで再利用したいと考える現場は多い。しかし、成功している現場はあまり多くない。テストケースの再利用に苦労する現場で、よく耳にする理由が、既存のテストケースの理解に時間がかかるという理由だ。

 過去案件のテストケースの再利用では、過去のテストケースの作成に関わらなかったエンジニアが担当することが多い。そうした場合、まずは過去のテストケースの内容を理解して、それから今回の案件に合わせて修正するという形で再利用する。だが、テストケースの多くは、その作成手順や意図が作成者以外に分かるような形で管理されていない。

 具体的には「どのテストケースに実施したいテストの対象があるのか分からない」「テストケースの目的や意図、インプット資料が分からない」「テストケースが最新のシステム仕様と合っているのか分からない」といった問題がある。

テストケースの再利用につまづく3つの「分からない」
テストケースの再利用につまづく3つの「分からない」
[画像のクリックで拡大表示]

どのテストケースに実施したいテストの対象があるのか分からない

 今回の改修でテストしたい機能のテストケースが、既存のテストケースのうちどこにあるのか分からない。

 例えば今回の改修では、A機能とB機能をテストしたいとしよう。新規開発時に作成したテストケースのうち、A機能とB機能のテストで再利用できそうなテストケースがどれなのかを特定する必要がある。このとき問題となるのが、テストケースがどのテストケースファイル(テストケースを書いたファイル)にあるのか分からない、ということだ。

 特に問題となりやすいのは1つのテストケースファイルの中で複数の機能を確認している場合だ。例えば、業務のシナリオをテストするシナリオテストである。そうした場合、テスト対象の機能のテストケースがあるかどうか、テストケースのファイルを1つひとつ開いて確認しないといけなくなる。なお、機能単位で実施する機能テストはそこまで難しくならない。機能ごとにテストケースファイルを作ることが多いため、どの機能のテストケースがどのファイルにあるかをファイル名で推測できる。

テストケースの目的や意図、インプット資料が分からない

 テストケースだけを見て、テストのケースの目的や意図、どんなインプット資料を基に作成されたのかを読み取るのは困難だ。そのテストケースが何を確認することを目的としたテストケースなのか、どのドキュメントの情報を基にテスト条件や期待値を導き出しているのか。テストケースの再利用を考えるときには、こうした情報が必要になる。これらの情報が分からないと、テストケースがどの程度再利用できるのか、判断ができない。

テストケースが最新のシステム仕様と合っているのか分からない

 テスト対象のシステム仕様が過去の改修で以前と変わっている場合がある。古いシステム仕様のテストケースを使ってしまうと、不具合の検出漏れや検出誤りを起こす原因となる。再利用するにしても、テストケースが最新のシステム仕様とどれくらい乖離しているのかを確認する必要がある。ただ、インプット資料がいつの時点のものか分からない場合、最新のシステム仕様との乖離を確認するためには全てのテストケースを確認しなくてはならず、確認作業に時間がかかってしまう。

 こうした「分からない」という問題があるため、テストケースを再利用するための調査作業に時間がかかってしまう。それなら新規で作成し直したほうが早いと判断し、再利用をあきらめる原因になってしまったりする。