今回は、結合テストの計画書作成に関する最後の記事となります。

テスト計画のスケジュールや体制・役割からの説明となります。

テスト計画書の作成手順

５．テストスケジュール

テスト実施のスケジュールを記述します。まずは、テスト全体スケジュールを定義します。

テストスケジュールについては、マスタスケジュールのマイルストーンを意識したうえで、関係各社と調整しておく必要があります。

特に外部結合テストについては、関係各社の進捗に影響されるため、早い段階で大枠の調整をしておき、詳細なスケジュールはテスト工程が近づいてきたら調整をするとよいでしょう。

テスト開始後も、バグの発生や他社の状況により変更になることは多々ありますので、必要に応じて早めに調整するようにしましょう。

１）体制と役割

スケジュールの次は、体制と役割について記述します。

まずは、お客様や関係各社を含めた全体の体制図を提示しましょう。

体制については、プロジェクト規模や契約、自社の立ち位置などにより異なりますが、全体統括（テスト全体の取り纏めを実施する人）は明確にしておきましょう。

全体責任者以下は、システム単位や機能（モジュール）単位など、プロジェクトに応じて設定してください。

体制図では、上下の関係（報告ルート）を定義することも重要となります。だれがその領域（チーム）を取り纏めて、誰に報告するのか明確にしておきましょう。

体制図と合わせて、各社の詳細な役割についての説明ページを追加しておくことをお勧めします。

テスト実施における各社の役割（テスト計画の作成や実施の進行は誰が実施するのか、またテストデータは誰が作成するのか）を定義。

また、不具合が発生した際の責任分界点など明確に定義しておき、各社と認識合わせをしておきましょう。

２）自社の体制について

つづいて、自社内の体制と役割について詳細に記載します。担当者レベルで、誰が何をするのか記述します。

自社内のテスト責任者（全体の取り纏め）は、テスト計画の立案や各種レビュー、報告などを担当します。

その他の役割としては、テスト設計者、実施者、不具合発生時の故障対応者、テスト品質の分析を行う品質管理者など、プロジェクトに合わせて役割と担当者を定義してください。

６．成果物

テスト工程の成果物を定義します。

成果物については、基本的に契約時点で工程ごとに作成予定の成果物を提示していると思いますので、同じものを定義すればよいでしょう。

ただし契約時点で具体的に提示していない場合は、具体的な成果物名に落とし込んで記述するようにしてください。

成果物の説明やできればテンプレートについてもお客様と合意しておいたほうがよいでしょう。

７．テストの開始と終了条件（クライテリア）

つづいて、テストの開始・終了基準について記述します。

こちらの基準については、一般的に決まった内容を記述することが多いです。プロジェクト特有の事項があれば追記する形が良いと思います。

例えば結合テストの開始条件は、以下のようなものがあります。

• 単体テストのすべてのテストケースの実施が終了し、検出されたバグについてはすべて対応済みであること
• テスト設計及び関係者のレビューが完了していること
• 結合テスト開始時点でリリースできない機能がある場合（追加開発、仕様変更、残バグ）については、別途追加実施するためのテスト計画（スケジュール）が検討済みであること

つづいて、終了基準の例

• 全てのテストケースの実行（再テストを含む）が完了していること
• 検出したバグの分析が完了し、同様のバグが潜在していないか（横並びチェック）を実施済みであること
• バグの改修が完了し、回帰テストが実施済みであること

８．テスト実施手順

テスト実施手順については、テスト計画書では、関係各社との間でテスト全体の大きな流れについて認識合わせをするための概要レベルで記載すればよいでしょう。

※実際の手順書は、エクセルベースの詳細な手順書を作成してください。

記載内容としては、各テスト工程ごとに、実施内容と作業手順（概要）、担当者、成果物を以下のようにマトリクスにして時系列でまとめるとよいでしょう。

流れとしては、一般的にテスト計画→要員計画（トレーニング）→テスト設計→テスト環境準備→テスト実施→品質分析→（再テスト）→完了報告といった感じになります。

特にトレーニングについて、ある程度経験があるメンバーが集まっている小規模プロジェクトではあまり実施することはないと思いますが、テスト品質を高めるためには、お客様の業務内容やプロセスの理解、作成したシステムに関する理解、テスト仕様書の作成方法、テスト技法、テストの実施手順などを理解したうえで実施することが望ましいです。

ただし、QCDに係る制約等により、実施が難しい場合もありますので、その場合はテスト管理者が最低限の教育と品質チェックをしっかり行う体制をとるようにしましょう。

１０．管理方針

１）進捗管理

管理方針には、テスト工程で管理すべき内容（進捗管理、インシデント管理、コミュニケーション管理、品質管理など）についての方針を記述します。

以下は、進捗管理方針についての説明資料（サンプル）ですが、テスト実施の際には、具体的な実施予定に対する消化率を計測するために以下のような表を用いて管理するなどの方針を記述するとよいでしょう。

※テスト実施の予実については、少なくとも日時単位で把握するようにしましょう。

全てのテストケースを算出して、テスト期間（実際のテスト可能な営業日数）で割ると、1日あたりに消化すべきケース数が算出できると思います。

ただし、テスト期間全体で割ると、終了がぎりぎりになってしまい、想定外の不具合が発生した場合などにリカバリーできなくなるため、予めバッファを考慮して前倒しで終了する予定を組むようにしたほうがよいでしょう。

お客様への定例会で進捗を報告する場合には、進捗率と合わせて、バグの発生件数や対応状況も報告するようにしましょう。

２）インシデント管理

つづいては、インシデント（バグ・故障・欠陥）管理についての方針を記述します。

方針としては、以下のような管理表（Excel）を用いて、件数や発生内容、バグの傾向分析を実施するなど記述すればよいでしょう。

もしくは、インシデント管理専用のツールやサービスを利用する場合には、それらを用いてどのような内容を管理するか記述してください。

クリエイティブコンテンツラボトウキョウが用意した、故障管理表のテンプレートを利用する場合は、以下よりダウンロードしてください。

テストの品質管理について

参考

故障管理表（バグ管理表）（Excelテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

３）品質管理

管理方針3つ目は、品質管理について記述しています。

テストの品質管理方針については、最低限プロジェクト計画書に記載の内容は定義するようにしてください。

バグの検出率などの指標に関しては、各社の過去プロジェクトやプロジェクト独自の指標を検討して記載します。

※一般的な開発指標を用いても構いませんが、お客様に説明して納得していただける根拠は必要となります。

その他の管理方針

上記以外にも、コミュニケーション管理、回帰テスト管理などページを追加して必要な事項はもれなく定義するようにしましょう。

まとめ

今回は、結合テストに関するテスト計画書のサンプルと合わせて、記述内容や考え方を説明してきましたが、いかがでしたでしょうか。

結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

参考

テスト計画書（結合テスト）（PPTテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

関連記事

結合テスト計画書の作成（第二回）では、テスト計画の詳細について説明していきたいと思います。

テスト計画書の作成手順

３．テスト計画（テスト範囲）

まずは、テスト範囲の定義について記述していきます。

このページの目的としては、システム全体の中で、どの部分について結合テストで実施するのかを明確することです。

また、結合テストで検証しない部分はどこなのかを明確にして、関係者の間で共通認識を持つことが重要です。

システム構成図ベースで範囲を囲ったり、どの部分は内部結合テストで検証するのか、外部結合テストで検証するのか、全体像がわかるように記載するとよいでしょう。あまり詳細な内容を記載する必要はありません。

テスト範囲の詳細は、別のところで説明すればよいので、ここでは全体像を把握できるレベルにしておきましょう。

1.テスト範囲（スコープ）

つづいてのページでは、同じくテスト対象について記述しますが、工程ごとにどのようなテストをするのか詳細していきます。

２．テスト対象

１）内部結合テスト

内部結合テストでは、前の記事で説明した通り、処理結合テスト、機能結合テスト、業務結合テストの3種類があります。

それぞれについて、どのシステム（領域）のどの業務/機能/処理（コンポーネント）の結合を検証するのかを明確に記述します。

処理結合テストでは、コンポーネントの単位に気を付けてください。（粒度を合わせるように）

また、業務結合テストについては、基本的に要件定義で検討した業務フローに沿ってシナリオを作成することになりますが、イレギュラーケースや想定している業務オペレーションや端末、アクター（権限）など考慮してシナリオを検討してください。

さらに計画書のレビューと合わせて、テストシナリオ、テストケースについては、お客様側の担当部門の方にも参加していただき、対面レビューを実施することをお勧めします。

システムを作成する側やお客様のシステム部門だけでシナリオを検討、レビューすると特にイレギュラーなオペレーションなどの考慮が不十分となることが多く、品質低下につながります。

２）外部結合テスト

外部結合テストについては、外部システムとのインタフェーステストが中心となります。

まずは、インタフェース一覧で、システム間、機能間のインタフェース（どこから（送信元）どこ（送信先）に対して、どのような処理方式で連携するのか）を洗い出して、それぞれの連携対象に対して、どのようなテストを実施するのか検討しましょう。

外部結合テストでは、他社（他システムのベンダー様）との連携テストとなることが多いため、しっかりとコミュニケーションをとって、テストシナリオ、テストケースについては、関係各社で協議・レビューして決めていくようにしましょう。

その際、テストデータはだれが作成するのかを明確にし、テストケースで必要となるテストデータが網羅できるように作成依頼をしておきましょう。

テスト実施にあたっては、不具合が発生した際のエスカレーション方法や責任分界点など明確にしておく必要があります。

最後に、テスト実施手順についても各社と認識合わせをしておきましょう。

3）性能（パフォーマンス）テスト

続いて、パフォーマンステストの実施に範囲や方法について記述していきます。

以下の例では、オンラインとバッチに分けて記述しています。

性能テストに関しても要件定義で検討したテスト方針に基づいて、処理毎の指標値を決めて、どのように測定するのか記述していきましょう。

特にWEBアプリケーションのテストで、端末（PC/タブレット/スマートフォンなど）から処理のリスクエストをしてレスポンスが返ってくるまでのターンアラウンドタイムで計測するのか、ネットワーク通信などは除外したサーバ内部処理のみの性能にするのかによって、指標値が大きく異なるため、この部分の認識合わせは重要となります。

以図のように、具体的にどの部分をテストするのか図示するとよいでしょう。

②バッチ処理

バッチ処理の性能テストについて記述します。

以下の例では、バッチのスループット検証として、1時間あたり9,000件の処理が可能かどうかの検証を記載しています。

また制約事項や前提条件がある場合には、それらを忘れずに記述しましょう。

特にSalesforce特有のガバナ制限を意識しないといけない処理に関しては、具体的なガバナ制限について記述しておきましょう。

バッチ系処理では、大量データで5000万件を超過するデータを扱う場合のテストや1外部APIを大量にコールアウト（Callout）するような処理がある場合には必ずテストを実施してガバナ制限に抵触しないかどうか検証するようにしましょう。

また、ヒープサイズを大量に消費するようなサイズの大きいファイルの読み込みなどについても必ずテストを実施するようにしましょう。

Salesforce環境で負荷テストを実施する場合には、上記に記載の通り、事前にサポートへ連絡して、承認を得る必要があります。

テスト計画の際に、申請タスクの落とし込みと、申請のリードタイムも考慮したスケジュールを作成する必要があります。

添付で、具体的に意識するべきガバナ制限について記載しておくのもよいでしょう。

４）テスト対象外機能

つづいては、結合テストで検証しない対象について明記しておきます。

対象外のシステムや機能・処理と合わせて、実施しない理由も記述します。例えば、環境による制約のため、テストが実施できないという場合など。

ただし、制約によりテストできない場合でも、まったくテストを実施しないということではなく、Mockをつかってテストを実施するなど代替案がある場合には必ず実施するようにしましょう。どうしてもできない場合の最終手段として有識者による机上での検証を行ってください。

５）責任範囲（責任分界点）

最後に、テストの責任範囲について記述します。

特に複数社による開発を行う場合にはこの記述が重要となります。（他社と同じモジュールやオブジェクトに対して設定・開発を行っているなど）

不具合が発生した場合に、誰の責任になるのか責任の所在を明確にします。

関係各社で協議したうえで、内容を記述するようにしましょう。

３．テスト実行環境

次にテスト実行環境について、記述していきます。

１）サーバ環境

まずはサーバ環境について記述します。結合テストの工程では、どのサーバを用意して利用するのか説明します。

Salesforceの場合、結合テスト専用のSandboxを用意してテストを実施することが多いと思います。

Sandboxの種類によって、ストレージの制限や更新間隔が異なったり、コピーされるデータが異なるため、これらの違いを把握したうえで環境の定義をするように心がけましょう。

２）クライアント環境

サーバの次は、クライアント環境について記述します。

テストを実施する端末の種類（PC/スマートフォン/タブレット）やOS、利用するBrowserなどについて記述します。

例では、Salesforceがサポートしているブラウザの種類を捕捉として添付しています。

特にIEなどサポートが終了しているブラウザもあるため、常に最新のサポートブラウザを確認するようにしましょう。

また、ブラウザの種類だけではなく、バージョンの確認も忘れないようにしましょう。

※OSのバージョンやアプリケーションのバージョンは過去分のバージョンまで組み合わせると莫大な工数が必要となってくるため、契約工数の範囲内で対応できる範囲で実施するように計画してください。

４）テストツール

最後にテストツールについて記述します。テストの種類と利用するツールについての説明を行います。

ツールを使って負荷テストをする場合は、サーバ側へかなり負荷がかかるため、実施する場合には必ずSalesforceのサポートと調整するようにしてください。

まとめ

今回はここまでとなります。次回は、スケジュールや体制・役割についての説明を行います。

結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

続きは、次の記事へ

参考

テスト計画書の作成（結合テスト）（３）スケジュール~管理方針

みなさん、こんにちは。 今回は、結合テストの計画書作成に関する最後の記事となりま…

続きを読む

結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

参考

テスト計画書（結合テスト）（PPTテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

関連記事

最近は本サイトへのアクセスも増えてきており、特にプロジェクト管理やテスト計画などに関してのお問い合わせやテンプレートのご要望が多いため、今回は、Salesforceプロジェクトのテスト計画書の作成方法をご紹介していきたいと思います。

テスト計画書（結合テスト）のテンプレート（サンプルあり）もご用意いたしました。

サポーターさん

結合テストのテスト計画書テンプレートをぜひご利用ください

では、さっそくテスト計画書の作成方法について説明していきたいと思います。

1.結合テストのテスト計画書作成

今回は、結合テストにフォーカスしたテスト計画書となっております。

では、まずテスト計画書で記載する事項について説明していきます。

結合テスト計画書（章立て）

まず、一般的なプロジェクト計画書の章立ては以下のようになります。

※中小規模の案件（ライセンス費用など込みで、5千万程度以下の案件くらい）であれば、もう少し簡略化した計画書を作成してもよいでしょう。

自社のテンプレートがないという方は、Creative Content Lab Tokyoが作成したテスト計画書のサンプルを参考に作成してみてください。

結合テスト計画書のサンプルドキュメント

結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

テンプレートのサンプル画像をいくつか掲載しておきます。

※画像はクリックすると拡大表示されます。

１．本書の目的

※図をクリックすると拡大表示されます。

２．基本事項

結合テストの位置づけ（機能テスト）

結合テストの位置づけ（非機能テスト）

２．テスト対象

性能（パフォーマンス）テスト

３．テスト実行環境（サーバ環境）

5.体制と役割

8.テスト実施手順

10.管理方針

１）進捗管理

３）品質管理

サンプルは以上となります。

テスト計画書の作成にあたって

テスト計画書のサンプルをご覧になられましたでしょうか。

初めてテスト計画書を作成する方は、どのような考え方で、計画書を作成していくのかわからないことも多いと思います。

まずは、各章で何を記載するべきか、どういう観点で書いていけばいいのか理解することが大切です。

テンプレートを使って同じように書いていけば、ある程度の品質の計画書を作成することはできますが、担当するプロジェクトの特性や制約、進め方によって不要な部分があったり、逆に必ず追記しなければならない事項が存在する場合もあるため、まずはしっかり自分の頭の中で整理してください。

特に他システムと連携する外部インタフェースの結合テストでは、他社と協業しての作業が必要となるため、体制や役割、スケジュール、テスト環境や手順のすり合わせが重要となってきます。

テスト計画書の作成手順

では、結合テストのテスト計画書の作成手順を説明していきたいと思います。

基本的にはテンプレートの各章で記載すべき事項などを中心に説明していきます。赤文字の内容については、特に注意してください。

表紙

まずは、表紙の作成から。会社のテンプレートによって表示位置やサイズなど様々ですが、基本的には以下のような構成が一般的です。

1. 顧客名（左上）
2. プロジェクト名（上下中央）
3. 版数（中央下段）
4. 作成日、作成者（会社）（中央下段）

※このあたりは、自社のテンプレートを使う場合には、自社の規定に合わせて変更してください。

１．本書の目的

続いて、本書の目的について記載します。テスト計画書の目的を概要レベルで記載してください。

また、本書の構成についてもプロジェクトの規模や会社の方針、または提案書の内容に合わせて成果物の構成は変更してください。

結合テスト工程で必要となる成果物は以下のようなものがあります。

※上記についても、本サイトでテンプレートとしてご提供させていただいておりますので、ぜひご利用ください。

２．基本事項

第2章では、基本事項に関しての記載をしています。まずは、結合テストの目的について記載します。

１．テストの目的

実施範囲（何と何の結合テストを実施するのか）や目的（何が正しいことを検証するのか、また正しくない動作の場合の対処（発覚した欠陥を除去し品質を高めるなど）を記述します。

２．基本方針

ここでは、テスト方針書などで検討した方針に基づき、結合テストに関する基本方針を記述します。

内容としては、テストの実施方針や、テストレベル、制約事項（ｘｘにより〇〇は検証しないなど）、スケジュールなど、関係者と握っておくべき結合テストの方針を明確に記述します。

３．結合テストの位置づけ（機能テスト）

次は、結合テストの位置づけについて説明しています。まずは、機能テストについての説明となります。

プロジェクトや会社によって、テスト工程の分け方や、テストの分類などが異なる場合もありますので、適宜テーラリングしてください。

ここでは、結合テストを内部結合テストと外部結合テストの２つに大きく分類しています。

また内部結合テストに関しては、以下の3つに分類しています。

• 処理結合テスト：コンポーネント間の結合テスト
• 機能結合テスト：機能（プログラム）間の結合テスト
• 業務結合テスト：業務フローに基づいた業務間の結合確認の業務結合テスト

外部結合テストに関しては、外部システム等とのインタフェーステスト（API連携やファイル連携など）と位置付けています。

上記資料の左側は、Salesforceのサービス基盤と設定・開発作成したアプリケーションで分けており、機能テストでは、赤い部分の機能に関しての、内部結合テスト、外部結合テストを実施するという意味合いで記載しています。

テスト実施にあたっては、Salesforceのアーキテクチャを理解して、関係者に説明下うえで、どの部分について、どのようなテストを実施するのか説明するのがよいでしょう。

３．結合テストの位置づけ（非機能テスト）

つづいては、非機能要件のテストの位置づけについての説明となります。

非機能に関しても、どの範囲までどのようなテストをするのか、事前に検討する必要があります。

非機能の全体像は、IPAが公開している非機能要求グレードに全体像が記載されています。その中からSalesforceの利用にあたって必要な検証事項を洗出しして、お客様と各事項に対して、どのレベルまでテストをするのか、検討しましょう。

IPA（情報処理推進機構）へのリンクは以下となります。（クリックすると外部サイトが開きます）

Salesforceの非機能のテストとしては、アプリケーションや基盤についての性能（パフォーマンス）検証、セキュリティ検証を実施することが多いと思います。

ただし、Salesforceでは、サービスに影響を与える可能性があるため、性能（負荷）テストの実施には注意が必要です。

具体的には、salesforceのサポートへ事前に連絡し、実施する内容について（実施の必要があるのか）の承認や、実施する場合の環境や日時の調整を行う必要があります。詳しくは以下を参照してください。

以下、Salesforceヘルプサイト

基本事項に関する説明は以上となります。

つづいては、第3章（テスト計画（テスト範囲））からとなります。

続きは、次の記事へ

参考

テスト計画書の作成（結合テスト）（２）スコープ～テスト実施環境

前回の記事では、結合テストの章立から基本方針についてまで説明してきました。 結合…

続きを読む

結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。

参考

テスト計画書（結合テスト）（PPTテンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

関連記事