今回の記事では、全体テスト方針書の作成方法について説明したいと思います。
テスト方針書やテスト計画書については、本サイトの中でも特に人気のコンテンツとなっています。
本サイトでは、テスト方針書やテスト計画書のPPT(パワーポイント)テンプレートやサンプルも用意しているので合わせてご利用ください。
※2021/11/26 テスト方針書については、Excel版の内容をアップグレードしたPPT版を新規追加しました。
テスト方針書の作成手順
１．テスト方針書の章立て（目次）
まずは、テスト方針書の全体の目次をご紹介します。
【テスト方針書（章立て）】参考
目次
改訂履歴
- はじめに
- 本書の目的
- 本書の構成
- 基本事項
- 各テストの位置づけ
- テスト範囲
- 前提条件と制約事項
- テスト範囲
- テスト対象
- テスト方針
- テスト環境方針
- テスト担当者方針
- ツールの利用方針
- テスト設計方針
- テスト実施方針
- 管理方針
- 進捗管理方針
- 品質管理方針
- バグ（故障）管理方針
- 回帰テスト方針
- 課題管理方針
- 添付資料（Appendix）
- 用語集
上記は中規模程度を想定したものとなっています。小規模であればもう少し簡素なものでもよいと思いますし、大規模プロジェクトであれば、記載すべき事項はもっと多くなると思いますので、プロジェクトに合わせて、適宜変更してください。
1.はじめに
１．本書の目的
画像はクリックすると拡大表示されます。
まずは、テスト方針書を作成する目的を記述します。テスト方針書は、あくまで今回のプロジェクトでは、どのような方針でテストを進めるのかについて大枠の方針を決定するための位置づけとなります。
詳細な内容は、テスト方針書でお客様や関係者と合意した内容に基づき、各テスト工程でテスト計画書を作成していきます。
テスト方針の段階で検討しておくべき事項について合意形成することが目的となります。主に以下のような内容について定義します。
- テスト範囲やテスト対象（対象外）の明確化
- 環境や体制などのリソースに関する方針
- テスト設計や実施に関する方針
- 品質や進捗の管理方針など
２．本書の構成
構成に関しては、テスト方針書と別紙になるものがあれば定義しておきましょう。
用語集などは、方針書（本書）に入れてしまってもよいと思います。
２．基本事項
続いての基本事項では、最初に関係者間でテストに関する事前の認識合わせが必要な内容について定義しておきます。
以下の例では、今回のプロジェクトのテスト工程の定義（単体テスト、内部結合テスト、外部結合テスト...）では、対象とテスト観点についての説明をしています。
また、Salesforceのシステム構成（基盤・ミドル・アプリ）に対して、各テスト工程で、どの部分をどのようにテストするのか概要図で説明しています。
- 単体テスト（UT）では、プログラム、コンポーネント、ユニットに関する説明
- 内部結合テストでは、処理結合テスト、機能結合テスト、業務結合テストでそれぞれ何を検証するのかを説明
- 外部結合テストでは、本システムと外部システムのインタフェースに関するテストを実施と明記
上記は、機能に関するテストの説明となりますが、続いて以下の図では、非機能に関してのテストの説明を行っています。
非機能に関しては、性能・セキュリティ・基盤に関するテストの概要をそれぞれ説明しています。
特にセキュリティや基盤周りについては、Salesforceのサービスとして担保されている部分については、テストを実施しないということも明記しておきましょう。
３．テスト範囲（スコープ）
１．前提条件と制約事項
3章では、テスト範囲について記述していきます。
最初に前提条件と制約事項を明記しておきましょう。コスト・期間などの制約以外にも環境や要員などのリソースの制約等も記載します。
参考
例えば、以下のようなものが考えられます。
（前提条件）本プロジェクトで利用するクラウドサービス（Salesforce）のサービス基盤に関するセキュリティや脆弱性に関するテストは実施しない。また、Salesforceが提供する標準機能に関しては、単体テストは実施対象外とする。
（環境制約）他システムとの連携テスト実施にあたり、他システム側は現在運用している環境しかないため、連携テストでは、休祝日等の非営業日を利用して、一時的に環境の切り替えを行ってテストを実施するなど。
サービス基盤側で担保されているような内容に関しては、対象外とすることでテスト工数を削減できますが、契約段階などで事前に合意しておくとよいでしょう。
２．テスト範囲
テスト範囲については、まず全体のシステム構成を提示し、各システムのどの領域をテスト対象とするのかを線引きします。
複数のベンダーが関係している場合には、各社がどの領域をテストするのかわかるように色を変えて、〇〇社担当領域など明示しておき、各社で認識を合わせておくことがよいでしょう。
３．テスト対象（機能）
続いては、具体的なテスト機能について記述していきます。テスト方針の段階でまだ詳細な機能が不明な場合には、機能のまとまり（領域）で定義して、テスト計画の段階で詳細化してください。
３．テスト対象（非機能）
非機能に関するテスト対象と対象外の事項について記述します。
特に、処理性能やセキュリティなどのテストに関しては、どこまでどのようなテストを実施するのか曖昧なままとならないように、しっかり定義しておきましょう。
テスト対象外の事項については、なぜ実施しないのか、理由も合わせて記述するようにしましょう。
４．テスト方針
１．テスト環境方針（サーバ）
テスト環境方針では、各テスト工程でどの環境を使ってテストをするのかを定義します。
参考
単体テストでは、開発目的で作成するSandbox（Developer）と同じ環境を使ってテストを実施する。本環境については、お客様のシステム担当者様にて、〇月〇日時点の本番環境をコピーして作成していただく。
※本開発環境は、〇〇社と共同で利用することになるため、共通設定（システム設定、権限設定など）を変更する場合には、事前に通知し合意を得たうえで実施する。
補足）テスト環境構築
各テスト工程における、環境構築イメージ
例では、開発したリソースを変更セットで別環境へ移送するやり方としていますが、プロジェクトによって環境管理のやり方は異なると思います。
また、変更セットだけでは対応できない内容もあるため、それらをどのように扱うのかも決めておくとよいでしょう。
変更セットで対応できない資材については、直接gitやSandboxなどからリリースできるXgeekが提供するPipelineを利用するとよいでしょう。
XgeekやPipilineについて詳しく知りたい方はこちらの記事を参照ください。
-
-
参考Pipeline for Salesforceを使って簡単にメタデータの移行を行う（xgeek.net）
今回は、xgeek.netさんが提供する無料ツールであるPipeline for salesforceをご紹介していきたいと思います。 xgeek.netでは、今回ご紹介するPipeline以外にも、 ...
続きを見る
補足）Sandboxの種類による相違点の説明
どのテスト工程でどの環境を利用するか検討するときには、利用するSandboxの種類を選択する必要があります。
Salesforceでは、Sandboxの種類によって、格納できるデータ量・更新サイクル・利用可能な機能が異なってくるため注意が必要です。
また、お客様のご契約状況によって利用できるSandboxの種類や数が異なるため、事前に本番環境で利用可能なSandboxの状況を確認しておきましょう。
1.テスト環境方針（クライアント端末）
サーバ環境に続いて、クライアント端末についても定義しておきましょう。（端末の種類やOSの種類・バージョン、利用するアプリケーションなど）
テストする端末やOSの種類などが増えるとその分工数も跳ね上がってくるため、当初見積もりの工数や契約内容に合わせて、テスト対象を指定してください。
補足）Salesforceがサポートするブラウザの種類とバージョン
クライアント端末から利用するブラウザについては、基本的にSalesforceがサポートしているブラウザを指定するようにしましょう。
お客様によっては、サポート期限切れのIEなどが指定される場合もありますが、必ず、サポートされないことをご理解いただいたうえご利用くださいと伝えるようにしましょう。
まとめ
テスト方針に関する説明（前編）は、ここまでとなります。
続きは、次の記事へ
-
-
参考テスト方針書の作成（後編）テスト担当者方針~管理方針
前回に引き続き、テスト方針書（後編）の内容について説明していきます。 本サイトでは、テスト方針書やテスト計画書のPPT(パワーポイント)テンプレートやサンプルも用意しているので合わせてご利用ください。 ...
続きを見る
テスト方針書（PPT版）のテンプレートが必要な方は、以下の記事からダウンロードしていただくことができます。
-
-
参考テスト方針書（PPT版テンプレート）サンプル
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したテスト方針書（PPT版）のテンプレートをご提供しております。 本テンプレートは、Sa ...
続きを見る
関連記事
