MENU

JSTQB(ALTM) シラバス学習:2 テストマネジメント(2.4)

2018.09.23更新

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

テストを実施する際には、テストマネジメントドキュメントが作成されます。
これらのドキュメントは組織や公式度によって作成される種類が異なり、公式度が高くなるほど全てのドキュメントが成果物として利用され、公式度が低くなるほど一部だけ成果物として利用する傾向が高くなります。

テストマネジメントドキュメントの種類と内容

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

2.4.1 テストポリシー

テストポリシーはテストの目的が定義されたドキュメントです。そして品質ポリシーの補完、もしくはその一部となります。
テストポリシーは新規開発用に加えて保守テストにも対応させ、組織全体で使用する内部標準や外部標準としても参照できるようにする。

作成者

上級テストマネジメントスタッフが、テストステークホルダグループの上級マネージャと協力して作成します。

内容

上位のドキュメントとして以下の内容を要約して記載します。

  • テストから得られる価値
  • テストの目的(ソフトウェアの確信度合いの構築、ソフトウェアの欠陥の検出、品質リスクのレベル軽減など)
  • 目的を達成するためのテストの有効性と効率性を評価する方法
  • 一般的なテストプロセスの概要
  • テストプロセスを改善する方法

 2.4.2 テスト戦略

テスト戦略には一般的なテスト方法を記載します。

ガイドライン

テスト戦略は以下のようなガイドラインに従って記載します。

  • 記載するプロセスおよび活動はテストポリシーと一貫している必要があります。
  • 異なる戦略を組み合わせることもあります。
  • 選択する戦略は組織のニーズや手段に適合させるため調整します。
  • 実行するテストレベルを記載する場合もあります。その際には、テストレベル間の開始基準と終了基準の関係についてガイダンスを示します。
  • 組織やプロジェクトによって適切なテスト戦略は異なります。

テスト戦略の種類

分析的戦略(リスクベースドテストなど)

カバーする条件の優先度に基づいてテストする順序を決める。

モデルベースド戦略(運用プロファイルなど)

実際の状況を予測して、システムの環境・入力と条件・動作方法のモデルを作成する。

方法論的戦略(品質特性ベースなど)

汎用的かつ論理的な一連のテスト条件を使用する。

プロセス準拠または規格準拠戦略(米国食品医薬品局の規定の対象となる医療システムなど)

規格委員会や専門家たちが定義した一連のプロセスに従う。

対処的戦略(欠陥をベースにした攻撃の利用など)

実際のシステムで実施する。

コンサルテーションベースの戦略(ユーザ主導のテストなど)

ステークホルダの入力からカバーするテスト条件を決定する。

回帰的テスト戦略(広範囲の自動化など)

回帰のリスクをマネジメントする技法を使用する。

その他の記載内容

テスト戦略には以下の内容を記載することもあります。

  • 統合手順
  • テスト仕様化技法
  • テストの独立性
  • 必須の標準および任意の標準
  • テスト環境
  • テスト自動化
  • テストツール
  • ソフトウェア成果物およびテスト成果物の再利用性
  • 確認テストおよび回帰テスト
  • テストのコントロールおよびレポート
  • テストの測定指標およびメトリクス
  • 欠陥マネジメント
  • テストウェアの構成管理アプローチ
  • 役割と責任

 2.4.3 マスターテスト計画

マスターテスト計画に関する項目

すべてのテスト作業が対象となり、以下のような情報を記述します。

  • 実行するレベル
  • レベル間の関連
  • テストレベルと開発活動との関係
  • テスト戦略の実装方法
  • テストポリシーと戦略の間の不整合についての情報
  • プロジェクト計画や運用ガイドを補完する情報

マスターテスト計画の内容

組織やプロジェクトによって異なりますが、以下が代表的な内容です。

  • テストするアイテムとしないアイテム
  • テストする品質特性としない品質特性
  • テストスケジュールと予算
  • テスト実行サイクルとソフトウェアリリース計画との関連
  • テストを行う人と他の人との関連性と提出書類(部署間の関連性も含む)
  • 各レベルにおけるテストアイテムの対応範囲の定義
  • 各テストレベルの開始・継続・終了の基準
  • 各テストレベル間の関連性
  • テストプロジェクトリスク
  • テスト活動全体の管理
  • 各テストレベルを実行する責任の所在
  • 各テストレベルの入力と出力

マスターテスト計画と他の活動

  • 小規模プロジェクトの場合は、1つのレベルのテストを公式としマスターテスト計画をまとめて記述することがある。
  • マスターテスト計画にテストに影響する他の活動について記述することがある。

2.4.4 レベルテスト計画

レベルテスト計画には以下の内容を記述する。

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

公式度合いが低いプロジェクトでは、単一のテスト計画がテストマネジメントドキュメントとなることも多く、レベルテスト計画にいくつかの情報要素を加えて1つのドキュメントとすることもある。

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

プロジェクトリスクはテストマネージャによって軽減できるものとそうではないもの(プロジェクトマネージャに通知して指示に従うもの)があります。

テストマネージャが対応できるリスク

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

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

以下のアプローチ手法が含まれます。

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

プロジェクトリスクマネジメントのためのオプション

オプションの選択は発生する利点と機会、あるいはコストや追加リスクを考慮して決めます。コンティンジェンシープランが特定された場合の、ベストプラクティスはトリガー(実行条件と方法)と所有者(実行者)を識別することです。

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

2.4.6 その他のテスト成果物

テストマネージャは、テストアナリストやテクニカルアナリストが作成する成果物の一貫性と品質を確保する必要があります。

成果物の例

  • 欠陥レポート
  • テストケース仕様
  • テストログ

テストマネージャの活動

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

テスト文書化の考慮事項

  • ソフトウェア開発ライフサイクル
  • 標準と規制
  • 開発されるプロダクト品質
  • プロジェクトリスク

テンプレート

テスト成果物のテンプレートはIEEE829などの資料に基づいて作成できますが、IEEE829はどの業界でも使用できるように設計されているため、これを改訂して特定の組織で使用できる標準テンプレートを作成することで、組織のプロセスが統一化されトレーニン工数の減少が期待できます。

2.5 テストの見積り

テストの見積りはベストプラクティスをプロジェクトのテスト活動に適用する作業で、マネジメント活動としてのテストの見積りは、プロジェクトの活動に対応するコストと終了日の近似値を作成することを意味します。ただし、ソフトウェア品質が低い場合や未知の場合は見積りは困難になります。

優れた見積りの特徴

  • 関連する参加者のサポートが得られる
  • コスト、リソース、タスク、人について詳細な一覧を提供できる
  • 見積り対象のそれぞれの活動について、最も可能性の高いコスト、工数、期間を算出できる

見積りに影響する要素

テストは一般的にプロジェクトのクリティカルパスのため、テストの見積りは、テスト活動のコスト、工数、期間に影響する以下のような要素を考慮します。

  • システムの品質レベル
  • システムサイズ
  • 過去のテストプロジェクトの履歴データ
  • プロセス要因
  • 物的要因(ツール、環境、ドキュメントなど)
  • 人的要因(マネージャからテスト担当者までのスキル、プロジェクトチームの関係など)
  • プロセスの複雑さ、ステークホルダの数、サブチームの構成
  • 人員増によるトレーニングやオリエンテーション
  • テストウェアの適用や開発
  • 詳細度合いの高さ
  • コンポーネントの受け入れ
  • 使える範囲が限られたテストデータ

見積りの技法

ボトムアップトップダウンのどちらでも良く、使用する技法は次のような技法から単独または複数を組み合わせても良い。

  • 直感、推測、過去の経験
  • ワークブレークダウンストラクチャ(WBS)
  • チーム見積りセッション
  • 企業の標準及び基準
  • プロジェクトの総工数またはスタッフ構成の割合
  • 組織のデータ蓄積及びメトリクス
  • 業界標準平均及び予測モデル

最終的な見積り

以下の点で優れたバランスを表すものが理想的です。

  • 品質
  • スケジュール
  • 予算
  • フィーチャ

また、見積りが利用可能な情報に基づいていることも重要です。

なぜならプロジェクトの初期など情報が十分ではない場合は、プロジェクトが進むにつれて見積りに使用した情報が変化する可能性があります。情報が変化した場合は、見積りの正確性を維持するため、再見積りが必要となります。