テスト報告書・テスト計画の評価にはテスト日程についての評価も書く
テスト評価にはテスト内容に続いてテスト日程についての評価も書く
ソフトのテスト報告書に書くテスト評価ではテストの日程についての評価も書きます。日程の評価はテストの終了日程を守れたかという最終的な結果と、テスト作業中の日程が計画から大きくズレなかったかとう途中の日程管理に分けて書くと判り易くなります。
テスト評価の１つ目のテスト内容の評価については前の記事で紹介したので、この記事ではテスト評価の２つ目のテスト日程の評価についてもう具体的に紹介していきましょう。
日程の評価はテストの終了日程を守れたかという最終結果と途中の日程管理に分けて書く
テストの成果として一番大なのはバグの検出状況ですが、その次に大切なのは日程を守れたかどうかです。テスト報告書での日程についての評価は、最終的なテスト終了日程を守れたかという日程管理の最終結果に焦点をあてた評価と、テスト作業の途中での日程管理の状態に焦点を当てた評価の２つの面から評価をします。
テストはソフト開発の最終段階での作業のために、設計や実装などの前工程での工程遅れが持ち越されているのにリリース時期は変わらないとう状況で、デスマーチが始まっているプロジェクトに巻き込まれる事も良くあります。色々と難しい状況の中でテストを行う事になるので、最初に計画していたテストの終了日程を守ってテストを終わる事ができたかどうか、とうい最終結果についての評価と、終了日程を守るためのテストの途中で日程管理がうまくできていたか、とう観点から評価していきます。
終了日程を守れたかは開始日と終了日の両方について計画と実績を見比べる
テスト終了日を守れたかどうかを評価する時には、テスト終了日だけではなく、以下の３つの観点で計画と実績とを比べて評価します。
- テスト終了日の評価：実際のテスト終了日は計画書からズレていないか
- テスト開始日の評価：実際のテスト開始日は計画書からズレていないか
- 日程見なおしの状況：テストの開始日・終了日を変更するテスト計画の修正はあったか
（１）テスト終了日の評価
テスト終了日の評価では、最新のテスト計画書に書いてあるテスト終了日までに実際のテストが終了できたかについて、評価します。計画した日程を守ってテストが終了できていれば評価は良ですが、日程に遅れがあった時にはテスト開始日の実績も考慮します。テストの開始が計画書のとおりの日程で始まっていて、テスト終了日が遅れていたのなら、テスト終了日についての評価は不可です。しかし、テスト開始が計画よりも遅れていてその分だけテスト終了日が遅れたのであれば、テスト終了日についての評価は不可ではなく可ですね。（評価は、良＞可＞不可 の３段階で評価していると想定しています）
（２）テスト開始日の評価
テスト開始日の評価では、単純に計画日からの遅れの大小で評価するので良いでしょう。テストの開始が計画よりも遅れていなければ開始日の評価は良で、遅れが出ていた場合には遅れた日数が計画書に書いてある全体日程の１０％以内なら評価は可とし、１０％を超える開始日の遅れがあれば評価は不可で良いと思います。なお、終了日の評価も開始日の評価も、最新の計画書の日程と実際の日程との対比で評価するのが判り易くて良いです。初版の計画書の日程からの計画変更については、次の日見なおしの状況で評価します。
（３）日程見なおしの状況
テスト計画書は初版のまま最後まで使えるのが理想ですが、実際には色々な要因から計画の見直しをする場合もあります。テスト開始日やテスト終了日についても変更があった時には日程計画を適切に見直して計画書を改定しておく事が、テストの管理を成功させるためにとても大切です。テストを終わった後で、テストの開始日や終了日についても、計画日程と実績の日程に全体工程の１０％以上の差が出ていた場合には、日程計画の適切な見直しができていたかどうか、一度振り返って考えてみるのが良いです。
テスト日程の管理は監視サイクルと修正アクションとリスク日程を評価する
テストの終了日程を守れたかどうかという最終結果の評価とは別に、テスト作業途中での日程管理の状況についても評価が必要です。テスト日程が計画どおりに進んでいるのかを監視して、計画からのズレが出てきた場合にはズレを解消するための対策を行う、それでもズレが大きくなるようなら計画の見直しをする、というよう日程管理が正しく機能していたかどうかの評価です。日程管理の状況については、以下の３つに分けて評価を書くと、テスト報告書が書きやすくなります。
- 管理サイクルの維持：日程のズレの有無を監視してズレを改修する対策を行う管理サイクルは機能していたか
- 回復対策の効果 ：日程のズレが起きた時にズレを回復するための対策を行い効果が出せていたか
- リスク日程の効果 ：日程計画のズレが起きた時の対策の１つとして織り込んであった余裕日程は適切だったか
（１）管理サイクルの維持
テスト日程の管理のサイクルは短い場合で１日長い場合で１週間程度が多いと思います。テスト計画書で決めた管理サイクルの期間に従って、日程計画に対する実際の日程の進捗状況を監視し必要なら対策を行う、という管理サイクルが正しく機能していたかどうかを、日程管理の記録を元に評価します。
まずは、決められた管理サイクルが抜けなく実施されていたのかの管理の実施状況ですが、これは計画された日程管理の回数と日程管理の記録から数えられる実施された日程管理の回数から、管理サイクルの実施率を計算します。例えば管理サイクルが1週間に1回で、テスト期間が24週間だとすると合計23回の日程管理が行われるのが計画です。それに対して、実際の日程管理の記録が残っているのが20回だと、実施率は 23% (=20*100/24) となります。
次に、日程管理の記録から日程に問題がある事を指摘した指摘件数を拾い出します。指摘件数の拾い出しと同時に、問題点に対する対策の実施の有無についても件数を確認します。指摘件数累計/管理実施回数 で、１回の日程管理あたり何件の問題を見付けたのかという指摘密度が判り、対策実施件数累計/指摘件数累計 で見つけた問題の何割に対策を実施したのかという対策密度が判ります。
指摘密度も対策密度もどの値が正しというのは無いのですが、過去の類似のテストと比較して今回のテスト管理サイクルの実施状況が妥当だったのかという視点で、管理サイクルの維持状況の良し悪しを評価します。
（２）回復対策の効果
管理サイクルの実施状況の評価の次ぎは、実際の日程管理の効果が出ていたかどうかの評価です。日程管理の効果の測り方には、これが良いという方法は無いのですが、日程計画のブレの延べ日数で測るというのも一つの手です。一番簡単な日程管理はマイルストーン管理です、テストの設計や実行の作業を細分化して各々の作業の終了日をマイルストーンにして、計画日に対する実績日のズレで日程計画からのズレを数値化して管理する方法ですね。日程管理をマイルストーンベースで行う場合には下記のサンプルのように、マイルストーンの計画と実績の表を作ります。
このサンプルでは現在5月８日で、5月７日までに計画されていたマイルストーンの実際の完了日が実績日の欄に記入してあり、計画日からのズレが（遅れたか早まったかに関わらず）ズレ日数欄に記入してあります。 この管理表を元に、毎週１回の日程管理の時に、その日までに完了する予定だったマイルストーンのズレ日数を累計して、マイルストーンの延べのズレ日数を表にすると、以下のようになります。
この延べのブレ日数が小さいほうが計画日程通りに日程が進んでいる事を示します。日展進捗の管理がうまく動作して効果が出ていればズレは少ないはずですので、日程管理の効果の良し悪しを評価する指標にはなります。もちろん、何日以下なら良いというような絶対的な基準は無いので、良し悪しの判断のためには過去のテストとの比較が必要になりますが、ある程度のテストについて値を集めれば良し悪しの判断ができるようになってきます。
（３）リスク日程の効果
テストに限らず全ての活動に言える事ですが、どれだけ綿密に計画を立てても実際に実行をすると色々な要因で計画からのズレは起きます。ソフトのテストの日程管理についても同じで、ズレを減らすために監視と挽回対策の推進という管理をいくら頑張って行ってもズレを無くす事はできません。しかし計画したテストの終了日程までにテストが終わらないと、ソフトのリリース日を守れなくなり、ソフト開発プロジェクトとして大きな問題になってしまいます。
そのように事態が起きないように、経験を積んだテストリーダであれば、テストの日程計画の中に明示的にまたは一見しては判らないようにコッソリとリスク日程を織り込んでいます。例えばテストの設計から実施まで、細分化した作業の日程を積み上げると100日になったとします。100日をそのままテストの日程計画とすると、どこかの作業で日程遅れが出るとそのままテストの終了日程遅れに繋がってしまうので、日程管理上のリスクが高いです。そうならないように、日程計画のあちこちに散らばらして５日分の日程の余裕を忍び込ましておけば、5日分は何かが起きてもテスト終了日程に影響を出さずにすみます。これがテストリーダが織り込むリスク日程です。少しカッコいいい方をすれば、テスト終了日を守るためのリスク管理のための手法です。
リスク日程については、明示的に織り込む事もあればコッソリと織り込む事もあるので、正式なテスト報告書に記載すのが良いかどうかは判断が難しいところです。なのですが、今後の別のテスト計画を立てる時にどの程度のリスク日程を織り込んだら良いかというのは、表面には出ないですが結構重要なノウハウになるので、できればテスト報告書に計画段階で織り込んだリスク日程と、実際のテストで利用したリスク日程についても、記録を残しておくのが良いと思います。
テスト評価にはテスト効率に対する評価も必要です
テスト報告書に書くテスト評価のうち、テスト内容とテスト日程について紹介ししてきましたので、次の記事では残りのテスト効率について具体的に紹介していきます。