システムテストにおけるテスト実行の順番をどう決めるか

システムテストではテストケース数が数万件に達することが珍しくありません。テストの実行においては、膨大なテストケースをどのような順番で実行するのかが極めて重要な意味を持っています。理想を言えば、数万件のテストケースのすべてについて、３回程度繰り返しテストを実行し、検出可能な欠陥をすべて検出するということになるでしょう。しかし、現実においてはそれだけの工数を用意することが不可能である場合がほとんどだと思われます。それでは限られた工数の枠内でどのような順番でテストを実行すればよいでしょうか。

一人のテスト担当者が1日で実行できるテストケース数が20件、テスト担当者が10名、一か月でのテスト実施日数が20日、システムテストの期間が6カ月とした場合、実行できるテストケースの最大件数は以下のように24000件となります。

　20件×10人×20日×6カ月＝24000件

工数に余裕がある場合は、24000件のテストケースを何度か繰り返しテストを行なうことができますが、工数に余裕がなく、各テストケースを1回と＋αしか実行できないものとして説明します。以降の説明では、機能テスを対象としています。

方法Aでは、次の順番でテストを実行します。

テスト担当者ごとにテストを実施する機能を割り当て、一人当たり2400件のテストケースを6ヶ月かけて実行します。この方法では、最初にテストされる機能と最後にテストされる機能との間には6ヶ月近い隔たりが生まれることになります。

方法Bでは、次の順番でテストを実行します。

システムテストの期間をいくつかのサイクルに分け、各サイクルごとに実行するテストケースを割り当てます。ここではテストサイクルを4として説明します。4つのテストサイクルを実行し終えたときにすべてのテストケースの実行が完了することになります。各テストサイクルごとに、どの機能のテストを誰が実行するかを割り当てます。ここで重要なことは、各テストサイクルにおいて、すべての機能についてテストを実行するということです。つまりテストケースを「間引いて」テスト実行するということです。テストサイクルが４つであれば、ごく簡単にいえばある機能のテストケースのうち、4分の1を1つのテストサイクルで実行するということです。

方法Aでは、6ヶ月というシステムテストの期間を通して、テストを実行する機能が順番に変わることになります。この場合、システムテストの終了間近になってテストを実行した機能に多くの欠陥が見つかるということがあり得ます。もしもこうしたことが起きれば、プロジェクトリスクとプロダクトリスクの両方が急上昇してしまいます。

これに対して、方法Bでは、最初のテストサイクルの段階で、他よりも多くの欠陥のある機能を特定可能なことが期待できます。システムテストの早期にそうしたリスクを把握することができれば、余裕をもって対策を検討することが可能となります。方法Bの利点はこれだけではありません。方法Bの利点を箇条書きで次に示します。

①.最初のテストサイクルの段階で、他よりも多くの欠陥のある機能を特定できる。

②.システムテストの全期間に渡ってすべての機能を対象とした様々なメトリクスを、各テストサイクルごとに収集することが可能となり、テストプロセスをコントロールすることが方法Aより容易になる。

③.テストサイクルごとに各人が担当する機能を入れ替えることにより、システムテスト終了の時点でテスト担当者が、システムの機能全体に対する理解を深めることができる。

④.システムテスト開始時点より終了時点でのテスト対象の品質が高くなることに対応して各テストサイクルの期間を決めることができ、テストサイクルに応じてテストの網羅度を変えることができる。

⑤.方法Aでは、最初にテストされる機能と最後にテストされる機能との間に長いブランクがあり、その間に欠陥の修正が行なわれるうちに、最初にテストした機能でデグレードする可能性があり、そのまま見逃される危険があるが、方法Bではそうした危険は少ない。

以上の利点のうち、③はテストサイクルごとに担当する機能が入れ替わるので、最初から担当する機能を固定する方法に比べて、慣れの問題があり、テスト効率の点で不利ですが、テストは一回きりではなく、何度もあるため、長期的にみれば特定の機能のテストが特定のテスト担当者に依存するという問題を回避することができ、機能全体を理解することができる方法Bが有利となります。

上にあげた方法Bの利点で④はこういう意味です。システムテスト開始時点では、ソフトウェアの品質はそれほど高くありません。したがって、この段階でのテストでは、テストを実行するテストケース数をある程度抑え、少なめに設定します。システムテストの中盤では、ある程度の品質が確保されるため、実行するテストケース数は広く深く、多めに設定します。システムテストの最終段階では、徹底したテストは不要ですから、広く浅く、実行するテストケース数は少なめに設定します。

したがってシステムテストの期間が6ヶ月で、テストサイクルが4サイクルであれば、各テストサイクルのテスト期間は例えば次のようになります。

　第1サイクル　1ヶ月
　第2サイクル　2ヶ月
　第3サイクル　2ヶ月
　第4サイクル　1ヶ月

4つのテストサイクルとした場合、どのテストケースをどのテストサイクルで実行するかをテストケース仕様書に明記します。次のテストケース仕様書の例で、左端の「実施TS」の列にある数字が、そのテストケースを実行するテストサイクルを表しています。例えば第2テストサイクルで使用するテストケース仕様書では、実行するテストケースが一目見てわかるように薄い水色などで塗りつぶしておきます。

この例では、各テストサイクルでの実行テストケースの件数には違いはありませんが、実際にはテストサイクルに応じてテスト網羅度を変えることになります。例えば第1と第4のテストサイクルでは実行するテストケース数が少なく、第2と第3のテストサイクルでは多くなります。

膨大なテストケースをどのような順番でテスト実行するかという問題は、テストプロセスにおけるかなり重要な事柄だと思いますが、このことについて説明したものはほとんど存在しないようです。テストプロセスを解説した書籍を何冊か持っていますが、どれにも説明がありません。Web上で検索してみましたが、ここで説明した事柄に近いことが書かれている記事が一つだけ見つかりました。日経BP社のITProというサイトの2006年6月28日の以下の記事です。

　基礎から学ぶソフトウエア・テスト（5）　テストのマネージメントとレポート

ちなみにISTQB テスト技術者資格制度の「ソフトウェアテスト標準用語集」の（日本語版）では、「テストサイクル」の説明として、「特定可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること」とあります。この用語集で扱われている「テストサイクル」は、ここで説明したテストサイクルとは少なくとも同じものではないようです。「ソフトウェア品質知識体系ガイド」でも取り上げられていないようです（見逃しているかもしれませんが）。