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