意外と知らない?テスト計画書に記載すべき9つの項目

これから書く項目がテスト計画時に定義されていなかった(検討されていなかった)ために、炎上してしまったプロジェクトをよく見かけました。

「何で定義しなかったの?」と担当PLに聞きましたが、「定義が必要だと思っていなかった。。」といった答えが返ってきたので、意外と重要だと気付かれていない項目もあるかもしれない。と思い、まとめてみることにしました。

※以下結合テスト、システムテストの機能テストフェーズのテスト計画書に記載することを前提にしています。

1.テストの種類と目的
大体のテスト計画書には「どのようなテストをするか」は記載されているのですが、「何を目的としたテストなのか」を明記していないテスト計画書をたまに見かけます。

大切なのは、目的を明確化し、ステークホルダー間で「今回のテストは大体このような内容のテストをするのだな」という認識をあわせる事です。

2.参考資料
今回のテスト計画を立てるにあたって、どのような資料を参考にしたのかを記載します。

例えば、外部仕様書や画面遷移図などが該当します。

参考資料を記載することで、「どの程度の資料を基に立てられた計画なのか」を示すことができます。
テスト計画書を見る人も、「RFPと画面遷移図から立てた計画だから、概算のテスト計画だろう」といった具合に計画の精度を予測することができるようになります。

3.テストの範囲
今回ご紹介している項目の中でも、かなり重要な項目です。
これが明確に記載出来ていないことで、炎上しているプロジェクトを良く見かけます。

テスト計画書を作成したテスト担当者は明確に記載しているつもりでも、開発側や、PMと認識がズレていたことで、「その範囲までテストが必要とは思っていなかった。。」とか「テスト計画書のレビューの時には何も指摘はなかった。」など大きな問題に発展するケースもあります。

4.テストの粒度
この項目も、先程のテスト範囲と並んでかなりの重要項目です。

テスト範囲同様、認識の違いが発生しやすく、また認識相違による手戻りはテスト工数へ大きな影響が生じます。

5.テスト対象環境
テスト計画時に確定していることが少ないため、後回しにされやすく、そのままテスト開始間際まで忘れられてしまうことが多い項目です。

テスト工程直前になって、「サーバに接続出来ない」とか「実機が足りない」といったことも、この項目を明記していなかったことで発生しやすいトラブル内容です。

ここからの項目は、必ずテスト計画工程で定義しなければならないといった項目ではないのですが、失敗プロジェクトでは最後まで定義せずに進めていることが多々あるため、テスト計画時に明確化することをお勧めします。

6.テスト実施者入力項目
テストケースを実施する際に実施者が記入する項目の定義です。

テスト開始前まで決まっていなかったり、テスト開始後に「そういえば、この項目もいるかもしれない」となりがちです。

テスト実施後に、「あのテストは、どの環境で実施しましたか?」と聞かれた時に回答に困らないように、記載が必要な項目は事前に決めて合意を取っておきましょう。

7.テスト判定項目
テスト実施時の判定に使う項目の定義です。
例えば「OK」や「NG」などの定義はわかりやすいですが、「保留」という判定結果を使用しているときなどは、認識に相違が発生しないように定義を共有することが必要です。

8.BTS(バグトラッキングシステム)で使用する項目
後々に障害(バグ)分析する際に使用するための項目を定義します。
テスト開始前までに定義しておかなければ後で変更ができないため、最初に「BTSで入力する、この項目はこういった分析で使用します」といったところを見せ、他に分析したい内容がないかを確認しておきましょう。

9.進捗管理指標
テストの進捗分析に使用する項目を定義します。
これも、先程のBTS項目と同様に事前に他に分析したい内容がないかを確認しておきましょう。

ここまではどのような項目が必要かという説明をしましたが、次回は具体的に私が使用してきた項目例をご紹介します。

広告