多くのプロジェクト計画書では、ソフトウェアテストの各段階ごとに完了基準を数値的に設定しておくことがほとんどだと思います。テスト項目数とバグ数について、その数値的基準を、ステップ数あたり何件とか、仕様書のページ数あたり何件とか。これらは、過去の経験値から設定されたり、会社の指針から設定されている場合が多いと思います。しかし、これらはあくまでも目安で、テスト仕様書が完成するまでは、実際の数字が確定しないこととなります。

 

テスト工程をはじめるにあたって、テスト推進チームが発足するなどして、テスト作業の体制やルールなどの標準化などをすすめていくわけですが、このテスト推進チームにおいてもテスト項目数や目標検出バグ数の見積り、その妥当性の判断の指針の決定は重要な作業で、詳細スケジュールの決定にも関係してきます。

 

ソフトウェアテストの最初の段階となる単体テストでは、ロジック網羅、条件分岐、限界値・代表値などのテスト内容を実施して、そのすべての消化が単体テストの完了基準となることが多いと思います。

その次の段階の結合テストで、最初から動かなくてテスト項目が消化できない、そして結合テストのスケジュール遅延ということがよくあったりします。

このような結合テスト初期段階のつまづきを予防するために、単体テストの後半に、結合テスト的な項目を２０％から３０％含ませるなどして、あるいはプレ結合テストというような形で実施して、次工程となる結合テストの実施可能性を判断して、単体テストの完了とするというようなことを行うこともあると思います。

そして、この実施方法をもとにすると、結合テストにおいてもシステムテスト的な項目の一部を実施し、そして、システムテストにおいても受入れ・運用テスト的な項目の一部を実施するということになります。

 

現実的な完了の判断は、このような現テスト工程の状況についてアセスメントを実施して、次のテスト工程へ進むかの判定会議によることになるかと思います。

このアセスメントや判定会議では、テスト項目の内容分類と消化数、バグ発生原因分類や発生状況の推移、バグ対応状況の推移などの統計もカギとなります。

テスト項目数は、有用な統計にするための根本的な数字ですから、それなりに相当な数が必要だと思います。ただ、テスト項目数は、スケジュールや要員にも直接関連しますので、妥当数を判断することが重要となります。

 

なお、テスト項目は、全テスト工程を通して全網羅を目指さなければならないと考えます。トップダウン的にみれば、各テスト工程は、この全網羅を段階的に配分しているわけで、その配分に見合っている必要があると思います。

 

さて、結局のところ、実際のテスト項目数は、テスト直前にならないと明確にならないようです。

ただ、ウォータフォール型の開発によれば、要件定義が終われば、その人員は運用テストの準備に、また、システム設計が終われば、その人員はシステムテスト、結合テストの準備に取り掛かることに理論上なっていますので、必ずしもテスト直前にならないと明確にならないわけでもなさそうです。

さらには、設計書にシナリオを作成することもよくあります。このシナリオが後のテストケースとして利用されることを考えれば、シナリオからテスト項目数を見積もることもできるそうです。