JSTQB ADVANCED LEVEL テストマネージャ試験概要はこちらを参照

2.テストマネジメント

2.4 テストドキュメントとその他の成果物

一般的なテストマネジメントドキュメント

• テストポリシー
  • 組織のテストに関する目的と目標を記述する
• テスト戦略
  • プロジェクトに依存しない組織の一般的なテスト方法を記述する
• マスターテスト計画（またはプロジェクトテスト計画）
  • 特定のプロジェクトに関するテスト戦略の実装について記述する
• レベルテスト計画（またはフェーズテスト計画）
  • 各テストレベルで実行する特定の活動を記述する

2.4.1 テストポリシー

テストポリシーは組織がテストを行う理由を記述する。
つまり、テストの全体的な目的を定義する。
場合によっては品質ポリシーを補完する一部となる

テストポリシーに記述する内容

• 組織がテストから得られる価値
• テストの目的を定義
• 目的を達成するためのテストの有効性と効率性を評価する方法
• テストプロセスの概要
• テストプロセスを改善する方法

2.4.2 テスト戦略

テスト戦略は組織の一般的なテスト方法を記述している

テスト戦略は次のような一般的なテスト方法を記述する

• 分析的戦略(リスクベースドテストなど）
  • テストベースを分析して、カバーするテスト条件を識別する
• モデルベースド戦略（運用プロファイルなど）
  • テストチームはシステムが存在する環境（実際の状況、及び、予想される状況）、システムに対する入力と条件、及び本来のシステムの動作方法の各モデルを作成する
• 方法論的戦略（品質特性ベースのものなど）
  • テストチームは品質標準（ISO 9126 -> ISO25000など) の事前に決定した一連のテスト条件、チェックリスト、特定のドメイン、アプリケーション、またはテストのタイプに関連する汎用的かつ論理的なテスト条件を使用する。またイテレーションから次のイテレーション、リリースから次のリリースまでの一連のテスト条件も使用する
• プロセス準拠または規格準拠戦略（米国食品医療品きょくの規定の対象となる医療システムなど）
  • テストチームは規格委員会または他の専門家達が定義した一連のプロセスに従う。このプロセスは文書化、テストベースとテストオラクルの適切な識別と使用、およびテストチーム編成を行う
• 対処的戦略（欠陥をベースにした攻撃の利用など）
  • テストチームはソフトウェアを受け取るまでテスト設計と実装を待ち、テスト対象の実際のシステムで対処する
• コンサルテーションベースの戦略（ユーザ主導のテストなど）
  • テストチームは一人以上の主なステークホルダの入力に依存して、カバーするテスト条件を決定する
• 回帰的テスト戦略（広範囲の自動化など）
  • テストチームは回帰のリスクをマネジメントする様々な技法（特に1つ以上のレベルにおける機能 / 非機能回帰テストの自動化）を使用する

その他、テスト戦略に記述する場合があるもの

• 実行するテストレベル
  • 各テストレベルの開始基準と終了基準
  • 各テストレベル間の開始基準と終了基準の関係について
  • 結合手順
  • テスト仕様化技法
  • テスト独立性（テストレベルによって異なることがある）
  • 必須の標準および任意の標準
  • テスト環境
  • テスト自動化
  • テストツール
  • ソフトウェア成果物およびテスト成果物の再利用性
  • 確認テスト（再テスト）および回帰テスト
  • テストコントロールおよびレポート
  • 欠陥マネジメント
  • テストウェアの構成管理アプローチ
  • 役割と責任

2.4.3 マスターテスト計画

マスターテスト計画では、特定のプロジェクトで実行する全てのテスト作業を対象とし作成する。
テスト戦略の実装方法（テストアプローチ）を記述する

マスターテスト計画の代表的な内容

• テストするアイテムおよびテストしないアイテム
• テストする品質特性およびテストしない品質特性
• テストスケジュールおよび予算（プロジェクトまたは運用予算と整合しなければならない）
• テスト実行サイクル及びソフトウェアリリース計画との関連
• テストを行う人々や部署と他の人々や部署との関連性と提出書類
• 記述している各レベルで、どのテストアイテムが範囲内でどれが範囲外かを示す定義
• それぞれのテストレベルに対する個別の開始基準、継続（中止 / 再開）基準、終了基準、及びテストレベル間の関係性
• テストプロジェクトリスク
• テスト活動の全体的な管理
• 各テストレベルを実行する責任の所在
• 各テストレベルにおけるインプットとアウトプット

2.4.4 レベルテスト計画

レベルテスト計画では、それぞれのテストレベルで実行する特定の活動を記述する。
テストタイプごとに記述する場合もある。
マスターテスト計画でカバーしてないスケジュール、タスク、マイルストーンの詳細についての情報をレベルテスト計画で提供する

アジャイルプロジェクトでは、スプリントテスト計画またはイテレーションテスト計画がレベルテスト計画の代わりになる場合がある

2.4.5 プロジェクトリスクマネジメント

テストマネージャによって軽減することが可能で対処すべきプロジェクトリスク

• テスト環境及びツールの準備
• テストスタッフの調達能力と資質
• テスト活動に対する標準類、ルール及び技法の欠如

プロジェクトリスクマネジメントアプローチ

• 早期のソフトウェアの準備
• テスト環境の事前テスト
• プロダクトの初期バージョンに対する事前テスト
• テスト開始基準の厳格化
• 試験性要件の強化
• 早期のプロジェクト成果物レビューへの参加
• 変更管理への参加
• プロジェクト進捗及び品質モニタリング

4つのオプションでリスクをマネジメントする

• 可能性や影響を減らす予防対策でリスクを軽減する
• コンティジェンシープランを作成して、リスクが現実化した場合の影響を軽減する
• リスクを別の部門に移して対処する
• リスクを無視する。または受け入れる

2.4.6 その他のテスト成果物

テストでは、欠陥レポート、テストケース仕様、テストログなど、その他の成果物を多数作成する

成果物の作成、文書化に関する考慮事項

• 拒否された欠陥レポートの割合など、これらの成果物の品質を監視するメトリクスを確立し、モニタリングする
• テストアナリスト及びテクニカルアナリストと協力して成果物の適切なテンプレートを選択し、カスタマイズする
• テストアナリスト及びテクニカルアナリストと協力してテスト、ログ、レポートで必要となる詳細度合いなどの標準を確立する
• 適切な技法を使用して、適切な参加者及びステークホルダによる成果物レビューを行う

テスト成果物のテンプレートはIEEE 829などの資料に基づき作成できる。
IEEE829のドキュメントを改訂して、組織で使用できる標準テンプレートを作成するのがベストプラクティスである

記事内用語解説

テストオラクル

テスト対象のソフトウェアの実行結果と比較する期待結果のソース。
オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない

テストタイプ

コンポーネント又はシステムをテストするためのテスト活動をまとめたものであり、たとえば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に商店を当てている。テストタイプは一つ又は複数のテストレベル又はテストフェーズで行われる

コンティジェンシープラン

想定外の事態が起きた時のために、事前に定めておく対応策や行動手順のこと