前回の記事では、結合テストの章立から基本方針についてまで説明してきました。
結合テスト計画書の作成（第二回）では、テスト計画の詳細について説明していきたいと思います。
テスト計画書の作成手順
３．テスト計画（テスト範囲）
まずは、テスト範囲の定義について記述していきます。
このページの目的としては、システム全体の中で、どの部分について結合テストで実施するのかを明確することです。
また、結合テストで検証しない部分はどこなのかを明確にして、関係者の間で共通認識を持つことが重要です。
システム構成図ベースで範囲を囲ったり、どの部分は内部結合テストで検証するのか、外部結合テストで検証するのか、全体像がわかるように記載するとよいでしょう。あまり詳細な内容を記載する必要はありません。
テスト範囲の詳細は、別のところで説明すればよいので、ここでは全体像を把握できるレベルにしておきましょう。
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のサポートと調整するようにしてください。
まとめ
今回はここまでとなります。次回は、スケジュールや体制・役割についての説明を行います。
結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。
続きは、次の記事へ
結合テスト計画書のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。
