本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した結合テスト計画書のテンプレートをご提供しております。
テスト計画を立てたことがないという方もいらっしゃるかもしれませんが、この計画は品質に直結する内容となるため、なんとなくテンプレートに沿って、書いていけばよいと考えているかたは、要注意です。
非常に重要な作業となりますので、計画書の各章に記載すべき内容や何のための項目なのかをしっかり理解してから記述するようにしてください。
また、テスト計画書については、外部結合テスト以降の工程では、自社だけではなく他社も含めて検討するべき事項やお客様の運用を考慮した運用テストの内容なども盛り込んでいく必要があるため、しっかりとコミュニケーションをとって、抜けもれなく計画書に盛り込むようにしましょう。
結合テスト計画書（章立て）
今回は、結合テストに関するテストの計画書のテンプレートをご紹介していきます。
まず、本テンプレートは、中規模程度の案件を想定した構成となっていますので、5千万以下の小規模案件ではもう少し簡素化した内容でもよいでしょう。
逆に、数億以上の規模の案件になってくると、ここで紹介する内容以上に検討すべき事項も増えてきますので、まずはベースとなる内容を理解して、不足する内容があれば、追加検討することをお勧めします。
【結合テスト計画書（章立て）】参考
目次
改訂履歴や用語集については、すべてのドキュメントにページを追加しておくようにしましょう。
また、第一章の本書の目的と構成についても同様で、すべてのドキュメントには基本的にドキュメントの目的や構成を記載するように習慣化しましょう。
- はじめに
- 本書の目的
- 本書の構成
- 基本事項
- テストの目的
- 基本方針
- 結合テストの位置づけ
- テスト計画
- テスト範囲（スコープ）
- テスト対象
- )内部結合テスト
- )外部結合テスト
- )性能（パフォーマンス）テスト
- )テスト対象外機能
- )責任範囲（責任分界点）
- テスト実施環境
- )サーバ環境
- )クライアント環境
- )補足）テスト対象ブラウザ
- )テストツール
- テストスケジュール
- )全体スケジュール
- 体制と役割
- )実施体制（全体）
- )実施体制と役割（弊社）
- 成果物
- )成果物一覧
- テスト開始・終了条件
- テスト工程の進め方
- )各作業工程の進め方
- )テスト要員とトレーニング計画
- )テスト設計
- )テスト実装
- )テスト実行
- )回帰テスト実施概要
- )テスト証跡の対象と取得方法
- 管理方針
- )テストの進捗管理
- )インシデント管理
- )テスト品質管理
- )想定されるリスクと対策
- )コミュニケーション方法
- 添付資料（Appendix）
各章のサンプルと解説例
本サイトで提供している計画書のサンプルPPTの抜粋と説明例をご紹介いたします。
※以下のサンプルは、有料員様へご提供している資料のより抜粋したものが含まれます。
１．本書の目的
こちらのスライドでは、まず計画書の作成目的を明記しています。
例では、コールセンター管理システムの結合テストの実施計画、品質管理、テスト計画、テスト観点の整理を目的としていると記載しています。
実際には、これらの計画を整理して、関係各社と協議するための資料という位置づけになると思います。
※図をクリックすると拡大表示されます。
２．基本事項
基本事項では、テスト実施の目的や方針について概要レベルで定義しましょう。何のために結合テストを実施するのか目的を明確に定義しましょう。※目的が曖昧になるということは何のためのテストか理解できていないということですのでよく考えましょう。
結合テストの位置づけ（機能テスト）
下図の例では、各テスト工程ではどの範囲をどのようにテストするのかを示していますが、これらは最初のテスト方針（全体テスト方針書）の中で記載しておくとよいでしょう。その中で、今回の結合テストはこの部分のテストを実施するということを示せればよいでしょう。
内部結合テスト
- 処理結合テスト：コンポーネント間の結合テスト
- 機能結合テスト：機能（プログラム）間の結合テスト
- 業務結合テスト：要件定義で定義した業務フローの要件通りに動作するか検証する結合テスト
結合テストの位置づけ（非機能テスト）
また、非機能に関するテスト方針としては、性能テストやセキュリティテスト、基盤テストなどに関してのテスト方針を記載します。
RFPでお客様から提出されていた非機能の要件については最低限網羅し、セキュリティテストに関しては、どこまでどのようにテストを実施するのか具体的に記載するとよいでしょう。
性能テスト
オンライン（画面）
・端末から処理をリクエストし、レスポンスを受け取るターンアラウンドタイムが目標値を満たしていることを確認する
バッチ処理
・指定の時間内に処理が完了するようにスループット（処理件数/時間）が目標値を満たしていることを確認する
セキュリティテスト
・ロールやプロファイルなどの設定がセキュリティ要件を満たした設定となっているか確認する。
・外部ユーザがサーバ内の機密情報にアクセスできないような権限コントロールとなっていることを確認する。
・SQLインジェクションやクロスサイトスクリプティングなどへの対応が実施されているか確認する。
基盤テスト
Salesforceでは、インスタンスの負荷状況を自動的に判断し、
処理負荷が高くなるとオートスケールし、負荷が一定以上高くならないように制御されている。
また、サービス基盤に関しては、開発ベンダー側での制御は一切できない仕様となっているため、基盤に関するテストは実施しない方針とする。
２．テスト対象
性能（パフォーマンス）テスト
性能テストに関しては、機能単位で、制約事項や測定項目を記述し、それを踏まえて指標値を設定するように記述します。
※指標値については、事前にお客様と検討・合意した内容を記述するようにしましょう。
負荷テストの実行について
“テスト日の少なくとも 2 週間前までにパフォーマンステストの承認申請を行う必要があります。
この 2 週間前までの通知のない要求は拒否される場合があります。
要求を送信するには、ヘルプポータルに移動して、[Network and Performance (ネットワークとパフォーマンス)] > [Notify Salesforce of an upcoming activity (活動の予定を Salesforce に通知)] > [Schedule a Performance Test (パフォーマンステストをスケジュール)] を選択します。
30 日の期間を超える要求は承認されません。この場合は、複数の要求が必要です。“
３．テスト実行環境（サーバ環境）
テスト実行環境については、以下はサーバ環境についての例ですが、ほかにクライアント環境についても端末（PC、スマートフォン、タブレット）とOS（windows、Mac、iOS、Android）、利用アプリケーション（ソフトウェア）などの条件も記載が必要です。
また、どの工程でどの環境を利用するのか、環境移行計画についても計画し、関係各社と協議しておきましょう。
サーバ環境
結合テストでは、以下の環境を用意し利用する。
Salesforce側システムでは、開発環境で作成したリソースの単体テストまでを実施し、その後、リソースを
変更セットに取りまとめて、各テスト環境へ移送する。
5.体制と役割
テスト実施の体制と役割では、外部結合テストの場合、テストケースやデータ作成などで相手システムの担当者とコミュニケーションをとる必要があるため、だれが何の役割で、コミュニケーションパスはどのようになっているのか確認しておきましょう。
また自社内の体制についても役割と責任を明確にしておきましょう。
7.テスト開始・終了基準
テスト開始・終了基準については。記載すべき事項は一般的な内容が多いですが、それぞれプロジェクトの基準に合わせて、記載内容を検討しましょう。
参考
- テスト設計及び関係者のレビューが完了していること。
- 単体テストのすべてのテストケースが終了しており、検出されたバグについてはすべて対応済みであること。
- 結合テスト開始時点でリリースできない機能がある場合（追加開発、仕様変更対応、残バグ）については、別途追加実施するためのテスト計画・設計が行われていること。
- テスト対象のリソース（メタデータやプログラム等）がソースコード管理システムにてバージョン管理され、テスト実行時点のテストケースとソース・モジュールのバージョンの紐づけが可能となっていること。
終了基準
- 全てのテストケースの実行(再テスト含む)が完了していること。
- 発見したバグを分析し、同様のバグが潜在していないか（横並びチェック）確認済みであること。
- 発見した全てのバグを改修していること。また、設計書にエラーが存在した場合は、修正を完了していること。
- 全てのバグを改修後、必要なテストケースについて回帰テストが実施済みであること。
品質分析が完了しており、適切な改善策が実施されていること。
8.テスト実施手順
10.管理方針
１）進捗管理
テストの進捗を正確に測るためには、全体のテストシナリオ、テストケースの総数や重みづけを考慮して、具体的な日程に落とし込んでいくとよいでしょう。
そのうえで、ある程度バッファを持たせておくことで、バグが発生した際にもスケジュールが遅延しないようにコントロールすることができます。
さらに、日々の進捗確認で、進捗率が思わしくなく、遅延しそうなリスクを早期に検出し、リカバリー策を検討することができます。
進捗管理：テストの進捗については、以下の進捗管理表を用いて、テストの予実管理を実施する。
インシデント（故障）管理：テストのインシデント管理については、インシデント管理表を用いて管理する。
３）品質管理
テスト品質の基準値については、基本的には過去の類似プロジェクトを参考に算出することが一般的です。
テスト品質
テストの品質管理として、以下の施策を実施する。
①テスト実施によるバグの検出を行い、検出率が規定範囲内であるかどうか判断する。
【バグ検出率】指標値：N％からNN%の間
テスト指標としてテストケース100件につき、バグ検出件数はN～NN件を目標とします。
※バグ検出率は弊社過去の実績と一般的な開発プロジェクト指標に照らして算出しております。
サンプルは以上となります。
2.テスト計画書の作成方法
結合テスト計画書テンプレートの利用方法（具体的な記載事項）については、以下の記事を参考にしてください。
-
-
参考テスト計画書の作成（結合テスト）（１）計画書の構成~基本事項の記載
みなさん、こんにちは。今回の記事は、テスト計画書の作成がテーマとなります。 最近は本サイトへのアクセスも増えてきており、特にプロジェクト管理やテスト計画などに関してのお問い合わせやテンプレートのご要望 ...
続きを見る
３.テスト計画書のダウンロード
資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。
一般公開資料
update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加
結合テスト計画書（結合テスト）（PPTl版）のダウンロードはこちら
以下は、スプレッドシートでの表示となります。
結合テスト計画書（結合テスト）（PPTl版）のダウンロードはこちら
まとめ
テンプレート関連の記事
