ここから先は、前説で述べたテスト・シナリオ進捗管理で用いられる、3つの管理指標の詳細を具体的に見ていくことにしましょう。
テスト・シナリオ
テスト・シナリオ進捗管理の基礎データになるのが表の右端の欄に実績を記入したテスト・シナリオ一覧表になります。
この表を見ると、多くは予定通りの進捗でありますが、テスト・シナリオ04で取引9に障害が発生していることが分かります。
進捗を時系列でイメージ化すると、図のようになります。
4月1日からテスト基準日「7月1日」のテストが開発され、現時点は4月10日です。
グレーの網掛けがしてある取引や帳票のテストが終了しています。
表の「検証結果」の列のテスト・シナリオ04の取引9で障害が発生し、いまだにその原因が判明していない状態です。
その影響で、テスト・シナリオ04の最後のテストである、帳票3のテストができません。
さらに、テスト・シナリオ05と06に取引6が含まれているので、そのテストも開始できないのです。
テスト・シナリオ04の障害の原因が、取引6にある可能性を否定できないからです。
この場合、図の下部の付表のようになります。
4月10日(現時点)では、テスト・シナリオ達成率は3/6件に過ぎません。
最低1回はテストされた取引テストは、8/9件まで達成できています。
画面も同じく8/9件である。帳票については2/6件に留まっています。
ここで注意してもらいたいのだが、テスト・シナリオの達成率だけをシステム・テストの進捗管理に使用してはいけません。
テスト・シナリオは複数のテスト基準日にまたがっており、テストの開始から終了までの期間が長いのです。
このため、テスト・シナリオが着実に前に進んでいても、終了するまでは進捗としてカウントされていません。
テスト・シナリオの達成率の数字ばかりを見てしまうと、実際はそうでないのに、進捗が遅れているかのような印象を与えます。
そして、システム・テストの終盤になって数値が急激に立ち上がるのが一般的です。
これでは、報告を受けた側は心配になってしまいます。
これを防ぐため、テスト・シナリオの進捗率に加え、取引、画面、帳票のテストの進捗をデータとして把握しておくのです。
そうすれば、「テキスト・シナリオはこの数値ですが、取引、画面、帳票の検証はここまで進んでいます」と説明ができます。
システム・テストの進捗の実態を報告するときには、進捗イメージが、相手に伝わるように心がけてほしいものです。