テスト計画・テスト目標（その１）納期とコストとプロダクト品質
ソフトのテスト計画にはテストの目標を具体的・定量的に書く
ソフトのテストの目標で最初に決めておく項目は、納期とコストとプロダクト品質で、これらを出来るだけ具体的・定量的に決めておきます。テストに使える期間と投入できる人員や機材と最終的に求められる品質は相互に絡み合っいます。ですので、まず品質目標を決め、その品質を達成するのに必要な人員と機材をきめ、その人員と機材で作業に必要になる期間を決めていくのが良いでしょう。
ソフトのテストはソフトの開発と同じく進捗や結果が目に見えにくいので、うまく管理をしないと計画どおりの成果が得られません。管理をするには、ゴールとなる目標が具体的で定量的なほうがやり易いので、テストの目標もできるだけ具体的で定量的な物にするのが良いです。
テストの目標の立て方にも色々とあってこれが正解というのはなく、それぞれのソフト開発プロジェクトに適した目標をその都度考える必要があります。とはいえ、テストの目標を立てるのは慣れていないとなかなか難しい面もあるので、グータラ親父がこれまで見てきたテストの目標の例をいくつかの種類に分類して紹介してみます。皆さんが目標を立てる時の参考にご覧ください。
テストの納期目標は細分化してマイルストーンに使う
テストの納期とコストはテストを計画する時の必須項目なのでテスト計画の最初に目標を決めます。まずはテストの納期を決めるのですが、ソフトの開発と同じようにテストも何種類かのテストに細分化してそれぞれの納期目標を決め、その後で全体の納期億票を決めるのが良いです。
テストチームが実施するテストにも、機能・性能の確認や安定性の確認、セキュリティの確認、妥当性確認などいろいろな種類のテストがあり、それぞれのテストは順番に実施される事もあれば、同時並行して実施される場合もあります。計画している複数のテストのそれぞれの納期目標を決め、それらのテスト結果が全て揃った時点でテスト終了の可否を判断するテスト全体としての納期目標を決める事になります。
全体としての納期目標以外に複数のテストの納期目標を決めて、それらをテスト作業のマイルストーンとする事で、テスト進捗の日程管理に使う事ができます。マイルストーンが計画どおりに達成できていれば進捗は問題無し、マイルストーンの達成に遅れが出ていれば、何か日程上の問題が発生している、という管理の仕方ですね。
テストのコスト目標には稼働率を使うと管理し易い
各々のテストの納期が決まれば、そのテストに必要な機材・環境・人員を洗い出して機材・環境・人員の割り振りの計画が立てられるようになります。使える機材・環境・人員には限りがあるので、できるだけ上手に使用日程を調整して、高額な機材や設備の空き時間が少なくなるように、または機材や環境待ちでテスト人員の待ち時間が発生しないように工夫して計画を作る事になります。
必要な機材・環境・人員必要な期間確保するのに必要になるコストがテストコストなのですが、コストは計画時点でコスト見積もりをして予算の手当てをした後は、目標として管理する事場面は少ないです。必要な機材・環境・人員は揃えないとテストが進まないので、コストそのものを管理に使うのは、少しやり難いですね。
でも、コストの見積もりに合わせて機材・環境・人員の稼働率を見積もっておき、これをコスト管理のための目標に使うと、テストの途中でもテストコストの管理が比較的やり易くなります。例えば、ある機材を１０月１１日から３０日まで２０日間準備するとして、その内で３日間は環境や人員の都合でテストに使わない日が４日ある計画だとすると、この機材の稼働率の目標は16日/20日 なので８０％です。
実際にテストを進めていくうちに何か問題が起きて、テストに使わない日数が最初の計画よりも１日増えると、稼働率は７５％と目標よりも低くなります。その状態のままでテストを続けて計画していたテストが完了できれば良いのですが、日程やテスト内容に問題が生じるなら何か対策を打たないといけません。計画からのズレに対して対策を行う事は管理なので、稼働率をコストの目標とするとテスト管理をやり易くなります。
テスト対象のプロダクト品質についても目標を立てる
テストの目標として納期とコストの次ぎに必要なのは、テスト対象のソフトのプロダクト品質についての目標です。プロダクト品質の目標は、ソフトの出来具合に大きく影響されるので、テストそものもの目標というよりは、テストを続けるか中断するかを判断するための目標と考えるのが良いです。テストで良く使うプロダクト品質の目標について、何件か例を挙げてみましょう。
（１）バグの検出率
バグ検出率としてよく使うのは、テスト項目あたのバグ検出率 （Ｘバグ/テスト） や、ソースコード 1KLOC あたりのバグ検出率 （Ｙバグ/KLOC）です。前者のテスト項目あたりのバグ検出率は、ソフトの出来具合がある程度安定しているという前提の元で、テスト設計の品質の良し悪しを見る時に使います。目標の値に比べて実績値が小さすぎる時は、十分バグを検出できていないかも知れないので、テスト設計に何か問題がないか確認してみるのが良さそうです。
後者のソースコード 1KLOCあたりのバグの検出率は、テスト設計の品質がある程度安定しているという前提の元で、テスト対象のソフトの品質の良し悪しを見る時に使います。目標の値に比べて実績値が大きすぎる時には、テスト対象のソフトの品質がかなり悪いかも知れないので、このままテストを続けてよいかどうか一度立ち止まって検討したほうが良いかも知れません。
（２）バグの修正率
テストでバグが見つかれば、それを修正するデバッグ作業が始まります。見つかったバグがその日の内に全て修正されるようならば良いのですが、多くの場合は修正に日数が掛かるので、修正されたバグの累積数は見つかったバグの累積数よりも小さくなります。
修正されたバグの累積数/見つかったバグの累積数で計算されるバグの修正率は、 100% になっているのが理想ですが、現実にはなかなかそうもいきません。バグが大量に検出されてデバッグが追い付かなく、未修正のバグが溜まっていくとバグの修正率の値は 70%とか 60% とかに低下していきます。
ですので、テスト期間を通してバグの修正率を何％程度に維持するか、とかテスト終了の時点でバグの修正率を何％に持って行くのか、というバグ修正率の目標値を決めておき、これを使ってテストの管理をする事でテスト対象ソフトのプロダクト品質を管理する事ができます。
テストの目標にはプロセス品質と作業品質と管理も使います
ここまで紹介してきた 納期とコストとプロダクト品質 以外にも、テストの目標としてはプロセス品質と作業品質と管理 を使う事もあります、これらについての次ぎの記事で紹介します。