みなさん、こんにちは。
今回は、結合テストの計画書作成に関する最後の記事となります。
テスト計画のスケジュールや体制・役割からの説明となります。
テスト計画書の作成手順
５．テストスケジュール
テスト実施のスケジュールを記述します。まずは、テスト全体スケジュールを定義します。
テストスケジュールについては、マスタスケジュールのマイルストーンを意識したうえで、関係各社と調整しておく必要があります。
特に外部結合テストについては、関係各社の進捗に影響されるため、早い段階で大枠の調整をしておき、詳細なスケジュールはテスト工程が近づいてきたら調整をするとよいでしょう。
テスト開始後も、バグの発生や他社の状況により変更になることは多々ありますので、必要に応じて早めに調整するようにしましょう。
１）体制と役割
スケジュールの次は、体制と役割について記述します。
まずは、お客様や関係各社を含めた全体の体制図を提示しましょう。
体制については、プロジェクト規模や契約、自社の立ち位置などにより異なりますが、全体統括（テスト全体の取り纏めを実施する人）は明確にしておきましょう。
全体責任者以下は、システム単位や機能（モジュール）単位など、プロジェクトに応じて設定してください。
体制図では、上下の関係（報告ルート）を定義することも重要となります。だれがその領域（チーム）を取り纏めて、誰に報告するのか明確にしておきましょう。
体制図と合わせて、各社の詳細な役割についての説明ページを追加しておくことをお勧めします。
テスト実施における各社の役割（テスト計画の作成や実施の進行は誰が実施するのか、またテストデータは誰が作成するのか）を定義。
また、不具合が発生した際の責任分界点など明確に定義しておき、各社と認識合わせをしておきましょう。
２）自社の体制について
つづいて、自社内の体制と役割について詳細に記載します。担当者レベルで、誰が何をするのか記述します。
自社内のテスト責任者（全体の取り纏め）は、テスト計画の立案や各種レビュー、報告などを担当します。
その他の役割としては、テスト設計者、実施者、不具合発生時の故障対応者、テスト品質の分析を行う品質管理者など、プロジェクトに合わせて役割と担当者を定義してください。
６．成果物
テスト工程の成果物を定義します。
成果物については、基本的に契約時点で工程ごとに作成予定の成果物を提示していると思いますので、同じものを定義すればよいでしょう。
ただし契約時点で具体的に提示していない場合は、具体的な成果物名に落とし込んで記述するようにしてください。
成果物の説明やできればテンプレートについてもお客様と合意しておいたほうがよいでしょう。
７．テストの開始と終了条件（クライテリア）
つづいて、テストの開始・終了基準について記述します。
こちらの基準については、一般的に決まった内容を記述することが多いです。プロジェクト特有の事項があれば追記する形が良いと思います。
例えば結合テストの開始条件は、以下のようなものがあります。
- 単体テストのすべてのテストケースの実施が終了し、検出されたバグについてはすべて対応済みであること
- テスト設計及び関係者のレビューが完了していること
- 結合テスト開始時点でリリースできない機能がある場合（追加開発、仕様変更、残バグ）については、別途追加実施するためのテスト計画（スケジュール）が検討済みであること
つづいて、終了基準の例
- 全てのテストケースの実行（再テストを含む）が完了していること
- 検出したバグの分析が完了し、同様のバグが潜在していないか（横並びチェック）を実施済みであること
- バグの改修が完了し、回帰テストが実施済みであること
８．テスト実施手順
テスト実施手順については、テスト計画書では、関係各社との間でテスト全体の大きな流れについて認識合わせをするための概要レベルで記載すればよいでしょう。
※実際の手順書は、エクセルベースの詳細な手順書を作成してください。
記載内容としては、各テスト工程ごとに、実施内容と作業手順（概要）、担当者、成果物を以下のようにマトリクスにして時系列でまとめるとよいでしょう。
流れとしては、一般的にテスト計画→要員計画（トレーニング）→テスト設計→テスト環境準備→テスト実施→品質分析→（再テスト）→完了報告といった感じになります。
特にトレーニングについて、ある程度経験があるメンバーが集まっている小規模プロジェクトではあまり実施することはないと思いますが、テスト品質を高めるためには、お客様の業務内容やプロセスの理解、作成したシステムに関する理解、テスト仕様書の作成方法、テスト技法、テストの実施手順などを理解したうえで実施することが望ましいです。
ただし、QCDに係る制約等により、実施が難しい場合もありますので、その場合はテスト管理者が最低限の教育と品質チェックをしっかり行う体制をとるようにしましょう。
１０．管理方針
１）進捗管理
管理方針には、テスト工程で管理すべき内容（進捗管理、インシデント管理、コミュニケーション管理、品質管理など）についての方針を記述します。
以下は、進捗管理方針についての説明資料（サンプル）ですが、テスト実施の際には、具体的な実施予定に対する消化率を計測するために以下のような表を用いて管理するなどの方針を記述するとよいでしょう。
※テスト実施の予実については、少なくとも日時単位で把握するようにしましょう。
全てのテストケースを算出して、テスト期間（実際のテスト可能な営業日数）で割ると、1日あたりに消化すべきケース数が算出できると思います。
ただし、テスト期間全体で割ると、終了がぎりぎりになってしまい、想定外の不具合が発生した場合などにリカバリーできなくなるため、予めバッファを考慮して前倒しで終了する予定を組むようにしたほうがよいでしょう。
お客様への定例会で進捗を報告する場合には、進捗率と合わせて、バグの発生件数や対応状況も報告するようにしましょう。
２）インシデント管理
つづいては、インシデント（バグ・故障・欠陥）管理についての方針を記述します。
方針としては、以下のような管理表（Excel）を用いて、件数や発生内容、バグの傾向分析を実施するなど記述すればよいでしょう。
もしくは、インシデント管理専用のツールやサービスを利用する場合には、それらを用いてどのような内容を管理するか記述してください。
クリエイティブコンテンツラボトウキョウが用意した、故障管理表のテンプレートを利用する場合は、以下よりダウンロードしてください。
テストの品質管理について
-
-
参考故障管理表（バグ管理表）（Excelテンプレート）サンプル
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した故障管理表（バグ管理表）のテンプレートをご提供しております。 内部テストやユーザ受け ...
続きを見る
３）品質管理
管理方針3つ目は、品質管理について記述しています。
テストの品質管理方針については、最低限プロジェクト計画書に記載の内容は定義するようにしてください。
バグの検出率などの指標に関しては、各社の過去プロジェクトやプロジェクト独自の指標を検討して記載します。
※一般的な開発指標を用いても構いませんが、お客様に説明して納得していただける根拠は必要となります。
その他の管理方針
上記以外にも、コミュニケーション管理、回帰テスト管理などページを追加して必要な事項はもれなく定義するようにしましょう。
まとめ
今回は、結合テストに関するテスト計画書のサンプルと合わせて、記述内容や考え方を説明してきましたが、いかがでしたでしょうか。
結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。
-
-
参考テスト計画書（結合テスト）（PPTテンプレート）サンプル
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した結合テスト計画書のテンプレートをご提供しております。 テスト計画を立てたことがないと ...
続きを見る
関連記事
