テスト仕様書には、テスト情報とテスト管理情報を記載する。
・テスト情報
　テストの内容とテスト実行結果を記す。
　・テスト内容
　　・テストケースを洗い出す
　　　・ユーザ業務、システム業務のシナリオテスト
　　　　・実際に業務ユーザーが本番環境でシステムを利用することを
　　　　　念頭に置き、一連の業務が実施できるかを検証する。
　　　　　ユーザー受け入れテスト時に使用するユーザマニュアルを
　　　　　業務部門が作成するのか、IT部門で作成を支援する必要が
　　　　　あるのかを確認し（プロジェクト計画段階で合意する必要が
　　　　　あるが業務の繁忙を含めてIT部門による支援がどの程度必要か
　　　　　を改めて判断する）、総合テストの業務シナリオテストを
　　　　　通してユーザーオぺ―ションマニュアルを作成する必要が
　　　　　あるか確認する。
　　　　　
　　　　・システム性能／耐久テストを実施するにあたっては、
　　　　　ピーク時を想定してテストケースを設定する。
　　　　　ピーク時とは、最も多くの業務ユーザーがシステムを利用する
　　　　　時間帯のことである。（最大トラフィック発生時）
　　　　　
　　　・本番相当のインタフェースデータの取込による想定外データの
　　　　有無を確認する
　　　　・テストデータの提供依頼に関する注意点
　　　　　外部システムからデータを取得する場合には、データ提供依頼は
　　　　　数週間から数か月前までにする必要がある。
　　　　　（実際に必要な期間は組織の状況による）
　　　　　その理由は、総合テストの時期に外部システムの担当者が別の
　　　　　優先すべき対応で多忙を極めていると、データ提供が後回しに
　　　　　なってしまうからである。このような問題を回避するためには
　　　　　テスト計画の段階で、どのような
　　　　　テストデータをいつまでに提供してほしいかを伝えて合意を
　　　　　得る必要がある。
　　　　
　　　　・情報セキュリティに関する注意点＞
　　　　　・本番相当のデータを使用する場合には、情報セキュリティの
　　　　　　観点で顧客情情報等の機密情報に類するデータのマスキングを
　　　　　　施す。
　　　　　　　例）顧客名、顧客口座番号　等
　　　　　　　　　マスキングは「顧客０００１」のように、データを
　　　　　　　　　見れば何の情報か判別できるような形で実施する。
　　　　　
　　　　　・データ検証のためにマスキングができない場合は、
　　　　　　情報セキュリティ部門等の監督部署にその旨を報告し、
　　　　　　本番データの管理（データの保存場所やデータの取扱者を
　　　　　　限定するなど）を厳密に行う。
　　　　　　
　　　・システム運用に関する作業を検証する
　　　　・システム障害の検知から調査を実施するまでの一連の作業を
　　　　　検証する。
　　　　・データバックアップ／アーカイブ／パージ等のデータ管理に
　　　　　関する一連の作業を検証する。
　　　　・可用性の検証として、システムフェールオーバー等による
　　　　　切り替え／切り戻しの一連の作業を確認する。
　　　　・セキュリティ面の検証
　　　　　通信の暗号化、システム監査項目の情報が収集できているか等の
　　　　　セキュリティ関連の検証事項を洗い出す。
　　　　・その他の運用／保守作業を検証する。
　　　　　　・サーバの停止・起動、サーバ／プロセス死活監視
　　　　　　・システムリリース後の構成管理／資源管理手順　等
　　　　　
　　　　　これらの作業の検証においては、手順が整っていることに加えて、
　　　　　その作業を効率的に実施できるか、日々の業務の中で無理が
　　　　　生じないかといいう観点で検証する必要がある。
　　　　　例えば、夜間バッチ処理でシステム障害が発生するとシステムが
　　　　　メールを送信する仕組みが出来ているが、実は夜間にメールを
　　　　　確認する人がいないということでは実際の運用は回らない。
　　　　　いつ、だれがその運用作業を実施するのかという観点で検証を
　　　　　実施する必要がある。
　　　　　
　　－－－－以降は結合テストと同様－－－－
　　
　・予想結果：システムの出力結果の記載は具体的な数字や文字列にする
　　
　・テスト実行結果
　　・テスト結果（OK/NGとNGの場合の詳細内容）
　　・確認日
　　・確認者
　　・不具合対応状況（不具合一覧の管理番号とステータス）
　　　不具合の詳細情報は不具合一覧に記載するが、テストケースを
　　　完了して良いかを判断するための情報として不具合の対応状況を
　　　記載する。

・テスト管理情報
　テスト管理情報はテスト品質の妥当性確認と、テスト進捗状況の把握の
　ために使用する。
　　
　・テスト品質の妥当性確認
　・テスト進捗状況の把握
　　　テスト期間中にテストが終わるのか否かを把握するために、
　　　テストケースの完了状況と不具合の解消状況を把握する。
　　　＜進捗状況を把握するために使用する情報＞
　　　　・テストケースの合計件数
　　　　・テスト結果の確認が完了した件数
　　　　・テスト結果がNGの件数
　　　　・未解消の不具合の件数

・本番データのマスキングのツール
　情報セキュリティの観点で機密情報をマスキングする際に利用するツール
　
・性能検証のために作成するデータ複製ツール
　例えば、過去5年分のデータがデータベースに保存されている状態で
　テストを実施しようとした場合に、1か月分のデータをもとに5年分の
　データを複製するツール。

・性能テスト自動実行ツール
　業務ピーク時を想定した同時実行はツールで自動実行できると効率化の
　効果が得やすい。

総合テスト以降の不具合は、プロジェクト全体で日次レベルで管理／情報共有
することが望ましい。この工程に来てから想定以上の不具合が発生したり、
それによるスケジュールの遅延が発生すると、予定通りの日程でシステムを
リリースできるか否かに大きく影響するからである。

　不具合の管理に関する詳細の情報は結合テストの記事を参照。

　テスト終了基準の中で未達成の事項がないか記載する。
　未達成の事項がある場合は残課題対応の予定を記載する。
　問題点は端的に記載し、詳細は後述のパートに記載する。

・詳細の報告
　・テスト進捗に関する報告の観点
　　・すべてのテストシナリオ／ケースの検証が完了しているか。
　　・完了していない場合はその理由は何か。
　　・完了していないものが原因でUATの開始に影響が出ないか。

　・不具合解消状況に関する報告の観点
　　・すべての不具合が解消しているか。
　　・解消していない場合は、個別にその内容を報告する。
　　・未解消の不具合が原因で総合テストの開始に影響が出ないか。

　・品質分析に関する報告の観点
　　・テストケースの設定漏れはないか。
　　（全機能・非機能の要素を対象にしているか）
　　・設定したテストケースの密度は適切か。
　　（テストケース密度が荒すぎないか）
　　・テストケース密度に異常値（密度が低すぎる）がある場合、
　　　その理由は何か。
　　・テストケース密度が低い機能に対して追加のテストが必要ないか。

　・障害の分析に関する報告の観点
　　・障害発生件数が多すぎる機能、少なすぎるシナリオがないか。
　　・件数の過多・過小が起きている機能について、追加のテストの
　　　必要はないか。