【JSTQB ALTM 】「2. テストマネジメント」のまとめ
用語
レベルテスト計画
通常、一つのテストレベルを扱うテスト計画書
マスターテスト計画
複数のテストレベルやテストタイプの調和のために使用するテスト計画書
プロダクトリスク
プロダクトの品質に影響を与えるリスク
プロジェクトリスク
プロジェクトの成功に影響を与えるリスク
品質リスク
品質特性に関連するプロダクトリスク
リスク
将来、否定的な結果を生む要素
リスク分析
リスク識別とリスクアセスメントを行うプロセス
リスクアセスメント
識別されたリスクを検証し、リスクレベルを決定するプロセス
リスク識別
リスクを発見し、認識し、および記述するプロセス
リスクレベル
影響度と可能性に基づいて、定性的または定量的に表現したリスクの重要度
リスクマネジメント
リスクを扱うプロセス
リスク軽減
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス
リスクベースドテスト
対応するリスクのタイプとリスクのレベルに基づき、テストの活動とリソースの利用をマネジメントし、選択し、優先順位付けするテスト
テストアプローチ
テストタスクの実装方法
テスト条件
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分
テストコントロール
テストプロジェクトが計画から逸脱した場合に、軌道修正するための対策を考えて適用する活動
テストディレクタ
テストマネージャをマネジメントする上級マネージャ
テスト見積り
テストのさまざまな局面に紐付けられた概算
テストリーダー
大規模なプロジェクトで、テストマネージャに報告を行い、特定のテストレベルやテスト活動に責任を持つ個人
テストレベル
具体的にインスタンス化したテストプロセス
テストマネジメント
テスト活動の計画、見積り、監視、コントロール。主としてテストマネージャによって実施される
テストモニタリング
テスト活動のステータスのチェック、計画済み、または予測されるステータスからの逸脱の識別、関係者へのステータスの報告を行う活動
テスト計画
テスト計画書を策定し、更新すること
テストポリシー
組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント
テスト戦略
特定の状況におけるテスト目的の達成のための、テスト実施方法の記述
ワイドバンドデルファイ（Wideband Delphi）
専門家によるテスト見積り技法。チームメンバーから集めた知識を用い、正確な見積りをするもの
2.2 状況に応じたテストマネジメント
マネージャーの職責
リソース（要員、ソフトウェア、ハードウェア、インフラストラクチャなど）を確保して活用し、付加価値をもたらすプロセスを実行すること
プロセスの対象はテストプロセス
テストプロセスは、プロジェクトまたはプログラム全体の成功に対する貢献によってのみ（または、より深刻な故障を防ぐことによって）価値を付加できる
テストプロセスを計画しコントロールする必要がある
ステークホルダ、ソフトウェア開発ライフサイクル、成果物のニーズと状況に応じて、ほかの関連する活動と成果物を含むテストプロセスを適切に準備する必要がある
（K4）ステークホルダ、状況、およびソフトウェア開発ライフサイクルモデルを含むソフトウェアプロジェクトまたはプログラムのニーズを分析し、最適なテスト活動を識別する。
（K2）ソフトウェア開発ライフサイクル活動と成果物がテストに与える影響、およびテストがソフトウェア開発ライフサイクル活動と成果物に与える影響を理解する。
（K2）経験ベースのテストおよび非機能テストに関するテストマネジメントの問題を管理する方法を説明する。
2.2.1 テストステークホルダについて
テストステークホルダーは、以下の品質に関心を持つ人々
テスト活動；直接的または間接的な関与
テスト成果物；直接的または間接的な受理
テストステークホルダと役割
開発者、開発リーダ、開発マネージャ
テスト対象のソフトウェアを実装し、テスト結果を受け取り、結果に基づいて対応する
データベースアーキテクト、システムアーキテクト、設計者
テスト対象のソフトウェアを実装し、テスト結果を受け取り、結果に基づいて対応する
上級管理職、プロダクトマネージャ、プロジェクトスポンサ
テストカバレッジの定義、テスト結果のレビュー、テスト結果に基づく意思決定に関与
プロジェクトマネージャ
プロジェクトを成功へと導くための管理を担当
プロジェクトを成功させるために、品質、スケジュール、フィーチャ、予算に優先度のバランスをとる
テスト活動に必要なリソースを獲得し、テストマネージャと協力してテストの計画とコントロールを行う
テクニカルサーポート、顧客サポート、ヘルプデスクのスタッフ
提供されたソフトウェアのフィーチャと品質によりメリットを受けるユーザと顧客をサポートする
直接及び間接的なユーザ
エンドユーザまたはソフトウェアが提供、またはサポートするアウトプットを利用したサービスを受けたりする
テストマネージャは、テストステークホルダを識別する必要がある
ステークホルダとテストとの関係の本質、およびテストチームがステークホルダのニーズに応える方法について理解する必要がある
2.2.2 その他のソフトウェア開発ライフサイクル活動と成果物
テストマネージャは、その他の活動とその成果物がテストに与える影響、およびテストがその他の活動とその成果物に与える影響を理解して、テスト活動を計画しガイドする必要がある
アジャイル開発手法を使用する組織
テストマネージャは開発マネージャと協力して、テスト担当者をテスト駆動開発の活動に統合し、連携して活動するように支援する
テスト担当者は、ユニットテストのカバレッジと効果を増加させるための提案を行い、ソフトウェアとその実装について深い理解を得るために、ユニットテストをレビューする。
また、状況を評価して独自の自動テスト、特に機能の回帰テストを、構成管理システムに統合できる
テストはイテレーティブモデルと同様に進行するが、様々なテストレベルでテスト実行が開発活動と重複することを含み、様々なテスト活動が高い度合いで開発活動と重複する
テストは次の項目に密接に結びつき、関係している
要求エンジニアリングおよび要求管理
テストマネージャは、要件の変更を認識し、この変更に対応し
てテストコントロール活動を実行することに加えて、スコープおよびテスト工数の見積り時に要件を考慮する必要があるテクニカルテストアナリストとテストアナリストは、要件のレビューに参加する必要がある
プロジェクトマネジメント
テストマネージャは、テストアナリストおよびテクニカルテストアナリストと協力し、スケジュール要件とリソース要件をプロジェクトマネージャに伝える必要がある
テストマネージャは、プロジェクトマネージャと協力し、プロジェクト計画の変更を理解し、テストコントロールアクションを実行して、これらの変更に対応する必要がある
構成管理、リリース管理、および変更管理
テストマネージャはテストチームと協力して、テスト対象を配布するプロセスとメカニズムを確立し、テスト計画の中にそれらを取り込む必要がある
テストマネージャは、テストアナリストおよびテクニカルテストアナリストに対して、ビルド検証テストを作成し、テスト実行中のバージョン管理を確実に行うように指示することが可能である
ソフトウェアの開発と保守
テストマネージャは開発マネージャと協力して、欠陥マネジメント（第4 章を参照）に参加することに加えて、各テストリリースの内容と日程など、テスト対象の配布を調整する必要がある
テクニカルサポート
テストマネージャはテクニカルサポートマネージャと協力して、テスト終了作業時にテスト結果を適切に提供する必要がある
テストマネージャはテクニカルサポートマネージャと協力して、テストプロセスを改善するために、運用時の故障を分析する必要がある
技術ドキュメントの作成
テストマネージャは技術ドキュメントマネージャと協力し、テストを行うためのドキュメントをタイムリーに提供することに加えて、これらのドキュメントに記載された欠陥をマネジメントしなければならない。
これらを怠ると、テストプロセスの有効性および効率性が最適化できない場合がある！！
2.2.3 テスト活動とその他のライフサイクル活動の連携
シーケンシャルモデル（ウォータフォールモデル、V モデル、W モデルなど）
イテレーティブモデルまたはインクリメンタルモデル（ラビッドアプリケーション開発（RAD）、ラショナル統一プロセス（RUP)）
フィーチャの各グループに対して、成果物と活動を含む様々なプロジェクトフェーズが発生する
このフィーチャはシーケンシャルに行うこともあれば、重複した形態で行うこともある
多くの場合、テスト実行には、テストレベルの重複が発生する。各テストレベルはできるだけ早期に開始し、より上位の後続するテストレベルが開始した後にも継続して行う場合がある
アジャイル（スクラム、XP）
イテレーションが短いイテレーティブライフサイクル
各イテレーションの成果物と活動が完結してから、次のイテレーションが開始する
テストはイテレーティブモデルと同様に進行するが、テスト実行が開発活動と重複することを含み、様々なテスト活動が高い度合いで開発活動と重複する
テストマネージャの役割は通常、直接的なマネジメント上の役割から技術的な専門家またはアドバイザとしての役割に変化する
スパイラル（スパイラルモデル）
実現可能性の確認、および設計と実装の決定を行うために、プロジェクトの早期にプロトタイプを使用して試行する
また、ビジネス優先度とテクニカルリスクのレベルに基づいて、プロトタイプを使用して試行する
これらのプロトタイプに対してテストを行い、未解決の技術的問題が残っている部分を特定する
主な技術課題が解決すると、プロジェクトはシーケンシャルモデルまたはイテレーティブモデルに従って進行する
テスト活動とライフサイクルを連携させるために、テストマネージャは組織で使用するライフサイクルモデルを詳細に理解する必要がある
テストプロセスをシステムテストレベルに適用すると
プロジェクト計画と同時にシステムテスト計画を開始
システムテストの分析および設計は、要求仕様から、システムおよびアーキテクチャ設計仕様（上位レベル）を経て、コンポーネント設計仕様（下位レベル）までプロセスと並行して行う
システムテスト実装活動は、システム設計時に開始する場合があるが、これらの活動の大部分は通常、コーディングおよびコンポーネントテストと同時に実行する
この場合、システムテストの実装活動への取り組みは、システムテスト実行の開始数日前まで継続してしまいがち
システムテストの実行は、システムテスト開始基準にすべて合致したときに始まる。終了条件に合致するまで継続する
システムテスト終了作業は、終了基準に合致しシステムテスト実行の終了を宣言してから始まる
イテレーティブライフサイクルまたはインクリメンタルライフサイクルでは、必要に応じて同じタスクを実行するが、タイミングと範囲が異なる。
テストの実行とレポートも、チームが使用するライフサイクルに影響を受ける場合がある。次のイテレーションを開始する前に完全なレポートを作成し、レビューセッションを実行し、次のイテレーションに入る。
=> 修正と調整を行うことができる（振り返り）
テストマネージャは、テスト計画やプロジェクト計画において、各レベルに対して、ソフトウェア開発ライフサイクルとテストプロセスの任意の選択した組み合わせに対して、プロジェクト固有の調整を行う必要がある
組織、プロジェクト、成果物のニーズに応じ、Foundation Level シラバスで定義されているテストレベルに加え、次のような追加のテストレベルを定義できる
ハードウェア－ソフトウェア統合テスト
システム統合テスト
フィーチャ相互作用テスト
顧客プロダクト統合テスト
各テストレベルでは以下の項目を明確にする必要がある
テスト目的
テストのスコープとテストアイテム
テストベース（このベースのカバレッジを測定する手段を伴う、例えばトレーサビリティ）
開始基準及び終了基準
テスト成果物（結果レポートを含む）
適用可能なテスト技法（これらの技法を使用して、適切なカバレッジを確保する方法を伴う）
測定指標およびメトリクス（カバレッジ測定など、テスト目的、開始基準と終了基準、および結果レポートに関連するもの）
テストツール（特定のテスト作業に適用できる場合）
リソース（たとえばテスト環境など）
責任を負う要員およびグループ（テストチーム内またはチーム外）
組織、規制、およびその他の標準への準拠（該当する場合）
ベストプラクティスは、これらの要素をすべてのテストレベルにわたって明確に定義し、同様のテストの異なるレベル間で発生する無駄で危険なギャップを避けることである。
2.2.4 非機能テストのマネジメント
非機能テストの計画をしないと、リリース後にシステムで、深刻な、壊滅的な品質問題が検出される可能性がある
テストマネージャはリスクと成約に基づいて、実行する非機能テストを選択する必要がある
テストマネージャが十分な専門知識を持っていない場合は、テスト計画の責任の一部を、非機能テスト活動に割り当てられたテクニカルテストアナリストに委任する必要がある。テストアナリストには以下を支持する
ステークホルダの要件
必要なツールの使用
テスト環境
組織的要因
セキュリティ
テストマネージャの重要な考慮事項
非機能テストをSDLCに統合する
すべての機能テストが完了してから非機能テストを開始するのは誤り
リスクに応じて優先度付けし、順番を決める
イテレーティブサイクルでは
イテレーションのペースが速いので、洗練されたテストフレームワークの構築が必要
イテレーションより非機能テストの設計に時間がかかる場合は、独立して活動する
2.2.5 経験ベースのテストのマネジメント
テストマネージャは、経験ベースの技法、特に探索的テストのメリットに加えて、これらの課題を認識する必要がある
探索的テストをマネジメントする１つの方法
テストセッションと呼ばれる30から120分の短い時間にテスト作業を分割する
各セッションは、テストチャータ（テストの目的を達成するための指針）をカバーする
テストマネージャがテストチャータをテスト担当者へ伝える
テストチャータでテスト条件を示すことで、テストへの集中力が高まり、複数の担当者が同時に探索的テストを実行しても、重複を防ぐことができる
事前に設計したテストセッションに自律的かつ自発的なテストを統合する
テスト担当者に事前に定義したテストで明示した手順以上のものを探求する権限を付与する（時間を割り当てる）
探索的テストセッションの開始時に、テスト担当者は、テストのために必要なセットアップ作業を確認し実行する。
セッションでは、テスト担当者はテストするアプリケーションについて学習し、適用される技法およびアプリケーションについて学習した内容に従ってテストを設計して実行し、すべての欠陥を調査して、ログにテスト結果を記録する（テストの再現性が求められる場合は、テスト担当者はテストの入力、活動、およびイベントもログに記録する必要がある）。セッションの終了後、報告を行う場合があり、これにより後続のセッションの方向性を設定する。
2.3 リスクベースドテストとその他のテストの優先度付けと工数配分のアプローチ
2.3.1 リスクベースドテスト
リスクベースドテストでは、ステークホルダが参加して行われるプロダクト品質リスク分析において、品質リスクを識別し評価する
品質リスク
プロダクト内に品質問題が存在する可能性がある状況
正確性に関する機能リスク
レポートでの不正な計算
効率性と応答時間に関する非機能リスク
ユーザ入力に対する応答のおくれ
仕様性と分かりやすさに関する非機能リスク
画面とフィールドの分かりにくさ
リスクベースドテストは、次の4つの主な活動で構成される
リスク識別
リスクアセスメント
リスク軽減
リスクマネジメント
2.3.1.1 リスク識別
リスクの識別方法
専門家へのインタビュー
第三者によるアセスメント
リスクテンプレートの使用
プロジェクトの振り返り
リスクに関するワークショップ
ブレインストーミング
チェックリスト
過去の経験の活用
リスク識別プロセスでは、ステークホルダのサンプルを広範囲に取り込むことにより、重要なプロダクト品質リスクを数多く検出しやすくなる。
2.3.1.2 リスクアセスメント
識別したリスクを分類（性能、信頼性、機能性など）して、それぞれのリスクに関連する可能性や影響を判断する
リスクのレベルを決定する場合、リスク顕在化の可能性および顕在化した際の影響を評価する。
リスクの可能性に影響する要因
技術およびチームの複雑性
ビジネスアナリスト、設計者、プログラマの個人的な問題およびトレーニングの問題
チーム内の衝突
供給者側との契約の問題
チームの地理的な分散
レガシーアプローチ対新しいアプローチ
ツールと技術
劣悪なマネジメントまたは技術的なリーダーシップ
時間、リソース、予算、およびマネジメントのプレッシャー
早期からの品質保証活動の欠如
高い変更率
高い初期欠陥率
インターフェースと統合の問題
プロジェクトリスクおよびプロダクトリスクに影響する要因
影響を受けるフィーチャの使用頻度
ビジネス目標の達成に対するフィーチャの重要性
イメージの悪化
業務の喪失
財政的、環境保護的、社会的損失または責任の可能性
民事上または刑事上の法的拘束
ライセンスの喪失
妥当な回避策の欠如
故障の判明による否定的な評判
安全性
リスク分析プロセスでは、何らかのコンセンサスに達する方法を含める必要があり、最悪の場合でも、合意したリスクレベルを確立しなければならない（たとえば、管理職の指示、またはリスクアイテムの平均値、中央値、または最頻値の採用により合意するなど）
2.3.1.3 リスク軽減
テストの開発と実行に伴う工数は、リスクのレベルに比例する。
つまり、リスクが高いと、より精緻なテスト技法（ペアワイズテストなど）を使用し、一方、リスクが低いと、あまり精緻でないテスト技法（同値分割法やタイムボックスを使った探索的テストなど）を使用する
さらに、リスクのレベルは、プロジェクト成果物（テストを含む）のレビューの適用、独立性の度合い、テスト担当者の経験の度合い、および確認
テスト（再テスト）と回帰テストの実行度合いの決定に影響を与える。
プロダクト品質リスクは、テスト実行開始前に軽減することが可能である。たとえば、リスク識別時に要件に関する問題を検出した場合、プロジェクトチームは軽減活動として、徹底的な要求仕様のレビューを実施できる
2.3.1.4 ライフサイクルにおけるリスクマネジメント
リスクマネジメントは、ライフサイクル全体で行うのが理想である。組織にテストポリシードキュメントやテスト戦略ドキュメントがある場合、プロダクトリスクおよびプロジェクトリスクをテストでマネジメントする包括的なプロセスを記述し、リスクマネジメントをテストのすべての段階にどのように統合したり、どのように影響をおよぼしたりするかを示す必要がある。
リスクに対する認識がプロジェクトチーム内に浸透している成熟した組織
重要なリスクは、特定のテストレベルで早期に対処するだけではなく、初期のテストレベルでも対処する（たとえば、性能を主要な品質リスク領域として識別した場合、性能テストをシステムテストで早期に開始するだけではなく、性能テストをユニットテストおよび統合テストでも実行する）
リスクを識別するだけではなく、リスクの原因、およびリスクが顕在化した場合の結果も識別する
「縦型探索」（depth-first）
高リスクのテストをすべて、低リスクのテストよりも先に実行したり、厳格なリスク順にテストを実行したりする
「横型探索」（breadth-first）
サンプリングアプローチを使用して、識別したすべてのリスクアイテムからテストのサンプルを選択することもある
この方法では、リスクに基づいて選択に重みを付け、同時に、すべてのリスクアイテムを少なくとも1 回はカバーするようにする
リスクベースドテストを縦型探索と横型探索のどちらで進めても、すべてのテストを実行しないうちにテストに割り当てた時間を消費してしまう可能性がある。リスクベースドテストでは、その時点における残りのリスクレベルについてテスト担当者が管理部門にレポートし、管理部門でテストを延長するか、あるいは残りのリスクをユーザ、顧客、ヘルプデスク／テクニカルサポート、運用スタッフに移転するかを決定できる
テストマネージャは各テストステークホルダが理解できる方法で、リスクに関するテスト結果を報告する必要がある。
2.3.2 リスクベースドテストの技法
探索的テストの悪い例
テスト担当者が品質リスクを分析するアプローチ
欠陥の影響ではなく欠陥の可能性に過剰に注目してしまう場合があ
クロスファンクショナルなステークホルダからの入力は含まれない。テスト担当の主観的なアプローチになる
テスト担当者のスキル、経験、好みに依存している
コストを最小化するのと同時に、リスクベースドテストの利点を獲得するために、多くの実務者は軽量のリスクベースのアプローチを採用している。このアプローチは、非公式アプローチの反応の速さと柔軟性と、より公式的なアプローチの権限や合意形成を合わせ持つ
軽量なアプローチ
実用的リスク分析とマネジメント（Pragmatic Risk Analysis and Management ： PRAM）
リスクベースの戦略と要件ベースの戦略をあわせて使用することを推奨
体系的ソフトウェアテスト（Systematic Software Testing： SST）
リスク分析への入力として要求仕様が必要となるので、要求仕様が提供される場合以外は使用できない
プロダクトリスクマネジメント（Product Risk Management：PRisMa）
リスクベースの戦略と要件ベースの戦略をあわせて使用することを推奨
これらの技法は、リスクベースドテストの通常の属性に加えて、次の属性を持っている
特に効率性の問題が重要となる業界でのリスクベースドテストに関する経験に基づいて、時間とともに進化する
初期のリスク識別およびリスクアセスメントにおいて、ビジネス的および技術的観点の両方を代表する、クロスファンクショナルなステークホルダによるチームの広範な関与が前提となる
プロジェクトのもっとも早い段階で導入した場合、および品質リスクを軽減するために最大に作用するオプションの場合、およびリスクを最小化するようにリスク分析の主な成果物と副産物がプロダクトの仕様と実装に影響を与える場合に、最適化している
生成された出力（リスクマトリクスまたはリスク分析テーブル）を、テスト計画とテスト条件、および後続するすべてのテストマネジメント活動とテスト分析活動のためのベースとして使用する
すべてのレベルのテストステークホルダにとっての残存リスクが何か、ということが分かるようなテスト結果の報告に役立てることができる
テストマネージャは要件によって示されていない重要なリスクを、特に非機能領域で見逃していないことを確認する必要がある
入力として、優先度付けした適切な要件が提供された場合、一般的にリスクレベルと要件の優先度との間に強い相関関係が見られる
また、これらの技法の多くは、リスク識別プロセスとリスクアセスメントプロセスを、テストアプローチに関するステークホルダ間の合意を形成する手段として使用することを推奨する
これは強力な利点ではあるが、このためにステークホルダは、グループのブレインストーミングセッションまたは1対1 のインタビューに参加するために時間を割く必要がある
ステークホルダの参加が不十分な場合
リスク分析でギャップが発生する
品質リスク分析活動のリーダは、ステークホルダとともに創造的かつ積極的に作業を行い、最善の合意を達成する必要がある
軽量な技法の特徴
可能性と影響の2つの要因のみを使用する
シンプルで定性的な判定と尺度を使用する
この特徴によって
柔軟性と広い範囲のドメインへの適用性
あらゆる経験とスキルを持つチーム（非技術要員、若手要因など）へのアクセシビリティをもつ（利用しやすい）
公式で重いアプローチ
ハザード分析
各リスクの根底にあるハザードの識別を試み、分析プロセスを上流に拡張する
エクスポージャーコスト
リスクアセスメントプロセスで、各品質リスクアイテムに対して、次の3つの要因を決定する
リスクアイテムに関連する故障が発生する可能性（割合で提示）
リスクアイテムに関連する一般的な故障が本番環境で発生した場合の損失コスト（金額で提示）
このような故障をテストするコスト
故障モード影響解析（FMEA;Failure Mode and Effects Analysis）およびそのバリエーション
品質リスク、その考えられる原因、および起こりうる影響を識別し、重要度、優先度、および検出率を割り当てる
品質機能展開（QFD;Quality Function Deployment）
テストに関連した品質リスクマネジメント技法であり、特に、顧客またはユーザの要件に対する理解が誤っている、または不十分なことから生じる品質リスクに関連する
フォールトツリー解析（FTA）
実際に（テストまたは本番で）観察されたさまざまな故障、または潜在的な故障（品質リスク）が、根本原因分析の対象となる
最初に故障の原因となる欠陥を分析し、次にこれらの欠陥の原因となるエラーまたは欠陥を分析し、さまざまな根本原因を識別するまで分析を続ける
リスクベースドテストで使用する必要がある具体的な技法
アジャイルプロジェクトでは、品質リスク分析は各スプリント期間の初期に完全に取り込み、リスクの文書化はユーザストーリーの追跡に統合する
システムオブシステムズ（相互接続したドメインと複数レベルのネットワークに組み込まれた複数の分散システムや異機種環境のこと。通常、共通的な管理構造を持たずに、広範囲に専門領域間をまたがる共通の問題や目的に対処する。）では、それ全体および各システムで、リスク分析が必要になる。セーフティクリティカルまたはミッションクリティカルなプロジェクトでは、より高いレベルの公式度合いと文書化が必要になる。
リスクベースドテストのもっとも重要な成功要因
ステークホルダの適切なチームがリスク識別とリスクアセスメントに関与すること
すべてのステークホルダは、プロダクトの品質の構成要素について独自に理解し、品質に関して独自の優先度と関心事を持っている
また、ステークホルダは、ビジネスステークホルダとテクニカルステークホルダの2 つの大きなカテゴリに分類される傾向がある。
ビジネスステークホルダ
顧客、ユーザ、運用スタッフ、ヘルプデスクスタッフ、テクニカルサポートスタッフなどを含む。
これらのステークホルダは顧客とユーザを理解しているので、リスクを識別し、その影響をビジネスの観点から評価できる
テクニカルステークホルダ
開発者、アーキテクト、データベース管理者、ネットワーク管理者などを含む
これらのステークホルダはソフトウェアが失敗に至る基本的な過程を理解しているので、技術的な観点からリスクを識別し、可能性を評価できる
リスクアイテムを識別するプロセス
リスクの膨大なリストを生成するプロセス
ステークホルダはリスクアイテムについて議論する必要はない
ステークホルダは、リスクのレベルに関する評価について、合
意を形成することが重要
ステークホルダが品質リスク分析プロセスに適切に関与する利点
テストマネージャは重要な利点を得ることができる
要件が不明確または不足しているプロジェクトでも、適切なチェックリストを使用してガイドすると、ステークホルダがリスクを識別できる
これが実現するのは、より完全なテストベース（この場合は品質リスクアイテムのリスト）を使用するからである
リスクベースドテストのテスト終了作業
テストチームは、重要度の低い欠陥よりも高い割合で重要度の高い欠陥を検出したか？
テストチームは、テスト実行期間の早期に重要な欠陥のほとんどを検出したか？
テストチームは、テスト結果をリスクの観点でステークホルダに説明できたか？
テストチームによりスキップしたテストがあった場合、そのテストは実行したテストよりも関連するリスクのレベルが低かったか？
テストマネージャは
長期にわたって、品質リスク分析プロセスの効率性の改善に努めるとともに、これらのメトリクスに関してプロセスの改善目標を設定する必要がある
これらのメトリクス、テストチームが達成する戦略的目的、および特定
のメトリクスと成功のための基準に基づくマネジメントによって生じる活動との関係を、慎重に考慮する必要がある
2.3.3 テストを選択するためのその他の技法
テスト技法
要件ベースドテスト
曖昧性レビュー
一般的な要件の欠陥チェックリストを使用することにより、要件の曖昧性を識別し除去する
テスト条件分析
要求仕様を詳細に読み、カバーするテスト条件を識別する
これらの要件に優先度が割り当てられている場合は、この優先度を使用して工数を割り当て、テストケースに優先度付けすることができる
優先度が割り当てられていない場合は、要件ベースドテストとリスクベースドテストをあわせて使用しないと、テストの適切な工数と順序を決定するのは困難である
原因結果グラフ；入力、刺激（原因）、関連する出力（結果）を図式表現したもの。テストケースの設計で使用できる。
テストケースの設計時にテストベースのギャップを識別する。これにより、ドラフトの要件に基づいてテスト設計を開始した際に、ソフトウェア開発ライフサイクルの早期に欠陥を識別できる
原因結果グラフの採用における主な障害の1 つは、グラフ作成が複雑なことである
要求ベースドテストの一般的な障害、要求仕様が曖昧、検証不能、不完全、または存在しないこと
モデルベースのアプローチ
システムの実際の使用状況を正確に描けるように、ユースケース、ユーザ（ペルソナとも呼ばれる）、入力、および出力を組み合わせて活用する
これにより、機能だけではなく、使用性、相互運用性、信頼性、セキュリティ、および性能もテスト可能となる
系統的アプローチ
テストする主な機能領域と非機能領域のチェックリストと、既存のテストケースのリポジトリとを組み合わせることで十分な可能性がある
チェックリストは通常、発生した変更の種類と量に基づいて、工数の割り当てとテストの順序付けに関する経験則を提供する
このようなアプローチが、ごくわずかな変更以外のテストで使用される場合、有効性が低下する傾向がある。
変更が小さい場合に効果的
対処的アプローチ
テスト実行の前には、テストの分析作業、設計作業、または実装作業をほとんど行わない
テストチームは、実際に提供されたプロダクトに対する対応に焦点を当てる。バグの偏在を検出すると、そこでさらなるテストを実施する
優先度付けと割り当ては、完全に動的に行う
対処的アプローチは他のアプローチの補完として機能するが、単独で採用した場合は、重要ではあるが少数のバグしか発生していないアプリケーションの主要な領域を見逃す傾向がある
2.3.4 テストプロセスにおけるテストの優先度付けと工数の割り当て
テストマネージャは、どのような技法または技法の組み合わせを使用する場合でも、それらをプロジェクトとテストプロセスに組み込む必要がある
シーケンシャルライフサイクル（たとえばV モデルなど）では、テストチームは定期的な調整を行いつつ、要件フェーズでテストの選択とテスト工数の割り当てを行い、最初にテストの優先度付けを行う
イテレーティブライフサイクルまたはアジャイルライフサイクルでは、イテレーションごとのアプローチが必要になる
テストの計画作業とコントロールでは、リスク、要件、および利用方法プロファイルが増大する程度を考慮し、それに対応する必要がある
テストの分析、設計、および実装では、テスト計画作業で決定された割り当てと優先度付けが適用されるべきである。この情報はテストプロセスを進めていくガイドに使われるだけでなく、注意深い分析やモデリングを行う目
的で、通常テストプロセスの中で詳細化する。この詳細化は通常、設計および実装で発生する。
テスト実行では、テスト計画作業で決定した優先度に従ってテストを実行すべきである。
テスト結果と終了基準ステータスを評価しレポートする場合、テストマネジャは、リスク、要件、利用方法プロファイル、およびチェックリストに関して、評価し、レポートする必要がある
終了作業で、テストステークホルダのニーズと期待に関連するメトリクスと成功のための基準を評価する必要がある。これには品質に関する顧客およびユーザのニーズと期待を含む。テストがこれらのニーズと期待を満たした場合のみ、テストチームが本当に有効に機能したと言える
2.4 テストドキュメントとその他の成果物
一般的に組織やプロジェクトには、次の種類のテストマネジメントドキュメントが存在する。
テストポリシー - 組織のテストに関する目的と目標を記述する
テスト戦略 -プロジェクトに依存しない組織の一般的なテスト方法を記述する。
マスターテスト計画（またはプロジェクトテスト計画） - 特定のプロジェクトに関するテスト戦略の実装について記述する
レベルテスト計画（またはフェーズテスト計画） - 各テストレベルで実行する特定の活動を記述する。
2.4.1 テストポリシー
組織がテストを行う理由を記述する。つまり、組織が達成する必要があるテストの全体的な目的を定義する
このポリシーは、組織の上級テストマネジメントスタッフが、テストステークホルダグループの上級マネージャと協力して、作成する
テストポリシーは広い意味での品質ポリシーを補完する
品質ポリシーは品質に関するマネジメントの全体的な価値と目標を記述する
テストポリシーでは上位のドキュメントとして、以下の内容を要約して記述する
組織がテストから得られる価値を要約する
ソフトウェアの確信度合いの構築、ソフトウェアの欠陥の検出、品質リスクのレベルの軽減など、テストの目的を定義する
これらの目的を達成するためのテストの有効性と効率性を評価する方法について記述する
ベースとして一般的なテストプロセスの概要を記述する
組織がテストプロセスを改善する方法を指定する
2.4.2 テスト戦略
組織の一般的なテスト方法を記述している
プロダクトおよびプロジェクトのリスクマネジメント、テストレベルへの分割
テストに関する上位の活動を含む（組織によっては、ソフトウェア開発ライフサイクル、リスクのレベル、または規制上の要件が異なる場合、異なる戦略を採用することがある）
テスト戦略は次のような一般的なテスト方法を記述する
分析的戦略（リスクベースドテストなど）
テストチームはテストベースを分析して、カバーするテスト条
件を識別する要件ベースドテスト
テスト分析により要件からテスト条件を導き出し、これらの条件をカバーするようにテストを設計し実装する
その後、各テストによりカバーする要件の優先度に基づいて、テストを実行する順序を決め、テストを実行する
テスト結果は、たとえば、要件をテストし合格した、要件をテストし不合格となった、要件をまだ完全にテストしていない、要件のテストがブロックされている、などの要件のステータスに関してレポートする
モデルベースド戦略（運用プロファイルなど）
テストチームは（実際の状況または予想される状況に基づいて）、システムが存在する環境、システムに対する入力と条件、および本来のシステムの動作方法の各モデルを作成する
系統的戦略（品質特性ベースのものなど）
テストチームは品質標準（たとえば ISO 9126 [ISO9126]から改訂中のISO 25000 [ISO25000]など）の事前に決定した一連のテスト条件、チックリスト、あるいは特定のドメイン、アプリケーション、またはテストのタイプ（たとえばセキュリティテストなど）に関連する汎用的かつ論理的な一連のテスト条件を使用する
プロセス準拠または規格準拠戦略（米国食品医薬品局の規定の対象となる医療システムなど）
テストチームは規格委員会または他の専門家達が定義した一連のプロセスに従う
対処的戦略（欠陥をベースにした攻撃の利用など）
テストチームはソフトウェアを受け取るまでテストの設計と実装を待ち、テスト対象の実際のシステムで対処する
フィーチャ、メニューの選択、および画面に対応する一連のテストチャータを開発する。各テスト担当者には一連のテストチャータが割り当てられ、それを使用して探索的テストセッションを構築する
コンサルテーションベースの戦略（ユーザ主導のテストなど）
テストチームは一人以上の主なステークホルダの入力に依存して、カバーするテスト条件を決定する
回帰的テスト戦略（広範囲の自動化など）
テストチームは回帰のリスクをマネジメントするさまざまな技法（特に1 つ以上のレベルにおける機能／非機能回帰テストの自動化）を使用する
テスト戦略では、以下の内容を示すこともある。
統合手順
テスト仕様化技法
テストの独立性（テストレベルによって異なることがある）
必須の標準および任意の標準
テスト環境
テスト自動化
テストツール
ソフトウェア成果物およびテスト成果物の再利用性
確認テスト（再テスト）および回帰テスト
テストのコントロールおよびレポート
テストの測定指標およびメトリクス
欠陥マネジメント
テストウェアの構成管理アプローチ
役割と責任
2.4.3 マスターテスト計画
特定のプロジェクトで実行するすべてのテスト作業を対象とする
マスターテスト計画では、特定プロジェクトへのテスト戦略の実装方法（テストアプローチ）を記述する
また、テストポリシーおよびテスト戦略との間で整合性がとれていなければならず、整合性がとれない箇所では、その逸脱や例外について記述する必要がある（逸脱により引き起こされる可能性がある影響を含む）
マスターテスト計画の代表的な内容
テストするアイテムおよびテストしないアイテム
テストする品質特性およびテストしない品質特性
テストスケジュールおよび予算（プロジェクトまたは運用予算と整合しなければならない）
テスト実行サイクルおよびソフトウェアリリース計画との関連
テストを行う人々や部署と他の人々や部署との関連性と提出書類
記述している各レベルで、どのテストアイテムが範囲内でどれが範囲外かを示す定義
それぞれのテストレベルに対する個別の開始基準、継続（中止／再開）基準、終了基準、およびテストレベル間の関連性
テストプロジェクトリスク
テスト活動の全体的な管理
各テストレベルを実行する責任の所在
各テストレベルにおける入力と出力
2.4.4 レベルテスト計画
それぞれのテストレベルで実行する特定の活動を記述する
マスターテスト計画を詳細化したものもこれに含む
アジャイルプロジェクトでは、スプリントテスト計画またはイテレーションテスト計画が、レベルテスト計画の代わりになる場合がある
2.4.5 プロジェクトリスクマネジメント
次のような一部のプロジェクトリスクについては、テストマネージャによって軽減することが可能であり、対処すべきこととなる
テスト環境およびツールの準備
テストスタッフの調達能力と資質
テスト活動に対する標準類、ルールおよび技法の欠如
プロジェクトリスクマネジメントへのアプローチには、
早期のテストウェアの準備
テスト環境の事前テスト
プロダクトの初期バージョンに対する事前テスト
テストの開始基準の厳格化
試験性要件の強化
早期のプロジェクト成果物のレビューへの参加
変更管理への参加
プロジェクトの進捗および品質のモニタリングなどを含む。
プロジェクトリスクを識別し分析した後は、次の主な4 つのオプションでそのリスクをマネジメントする。
可能性や影響を減らす予防対策でリスクを軽減する。
コンティンジェンシープランを作成して、リスクが現実化した場合の影響を軽減する。
リスクを別の部門に移して対処する。
リスクを無視する、または受け入れる。
プロジェクトリスクに対するコンティンジェンシープランが特定された場合、ベストプラクティスはトリガー（コンティンジェンシープランを実行する条件と方法を決定する）と所有者（コンティンジェンシープランを実行する人）を識別することである
2.4.6 その他のテスト成果物
テストマネージャは、次の活動を通じて、これらの成果物の一貫性と品質を確保する必要がある。
拒否された欠陥レポートの割合など、これらの成果物の品質を監視するメトリクスを確立しモニタリングする。
テストアナリストおよびテクニカルテストアナリストと協力して、これらの成果物の適切なテンプレートを選択しカスタマイズする。
テストアナリストおよびテクニカルテストアナリストと協力して、テスト、ログ、およびレポートで必要となる詳細度合いなど、これらの成果物の標準を確立する。
適切な技法を使用して、適切な参加者およびステークホルダによるテスト成果物のレビューを行う。
テスト成果物のテンプレートは、IEEE829 のドキュメントを改訂して、特定の組織で使用できる標準テンプレートを作成するのがベストプラクティスである。テンプレートを一貫して適用することで、トレーニングの必要性が減少し、組織全体でプロセスの統一化を達成する
2.5 テストの見積り
見積りは特定の運用またはプロジェクトに関わる活動に対応するコストおよ
び終了日の近似値を作成することになる。
優れた見積りには次のような特徴がある。
経験を積んだ実務者の英知の結集となり、関連する参加者のサポートも得られる
プロジェクトのコスト、リソース、タスク、人について詳細な一覧を提供する
見積り対象のそれぞれの活動に対し、もっとも可能性の高いコスト、工数、期間を算出する
テストの見積りは、これらのベストプラクティスを、プロジェクトまたは運用に対応するテスト活動に適用することである。
見積りの際に設定した仮定は、見積りの一部として常に記述する必要がある。
テストの見積りでは、テスト活動のコスト、工数、期間に影響をおよぼすあらゆる要素について考慮する必要がある。これらの要素には次のものを含む（ただし、これらのみではない）。
システムに求められる品質レベル
テスト対象となるシステムのサイズ
過去のテストプロジェクトの履歴データ（他の組織の業界データまたはベンチマークデータを含む場合もある）
プロセス要因。テスト戦略、開発または保守ライフサイクルおよびプロセスの成熟度、プロジェクト見積りの正確性など
物的要因。テスト自動化およびツール、テスト環境、テストデータ、開発環境、プロジェクトドキュメンテーション（たとえば要件、設計など）、再利用可能なテスト成果物など
人的要因。マネージャおよび技術リーダ、管理職および上級管理職の責務と期待、プロジェクトチームのスキル、経験、態度、プロジェクトチームの安定性、プロジェクトチームの関係、テストとデバッグ環境サポート、優れた請負業者やコンサルタントの利用可能性、ドメインの知識など
プロセス、技術、組織の複雑さ、テストに関わるステークホルダの数、サブチームの構成と場所
著しい人員増によるトレーニングやオリエンテーションの必要性
新しいツール、技術、プロセス、技法、カスタムハードウェア、各種のテストウェア（テストプロセスで生成される中間成果物）の適用や開発
詳細度合いが高いテスト仕様の作成要求（特に馴染みのない文書化標準の場合）
コンポーネントの受け入れが時間的に前後する場合（特に統合テストやテスト開発の場合）
使える範囲の限られたテストデータ（たとえば時間の影響を受けるデータなど）
テストに提供されるソフトウェアの品質も、テストマネージャが見積りで考慮すべき大きな要因
テストの見積りの技法
直感、推測、および過去の経験
ワークブレークダウンストラクチャ（WBS）チーム見積りセッション（たとえばワイドバンドデルファイ）
企業の標準および基準
プロジェクトの総工数またはスタッフ構成の割合（たとえばテスト担当者と開発者の割合）
組織のデータ蓄積およびメトリクス（欠陥の数、テストサイクルの数、テストケースの数、各テストの平均工数、関連する回帰テストサイクルの数を見積るメトリクス抽出モデルを含む）
ファンクションポイント、コードの行数、見積った開発者の工数、他のプロジェクトパラメータなどの、業界平均および予測モデル（たとえば[Jones07]を参照）
2.6 テストメトリクスの定義および使用
テストメトリクスは、次の1 つ以上のカテゴリに分類される。
プロジェクトメトリクス。実行済み、合格、不合格のそれぞれのテストケースの割合など、確立しているプロジェクト終了基準に対する進捗を測定する。
プロダクトメトリクス。テスト範囲、欠陥密度など、プロダクトのいくつかの属性について測定する。
プロセスメトリクス。テストで検出された欠陥の割合など、テストプロセスまたは開発プロセスの能力を測定する。
人的メトリクス。指定されたスケジュールでのテストケースの実施など、個人またはグループの能力を測定する。
テストの進捗を測定するメトリクス、つまりプロジェクトメトリクスの使用
に重点を置く
テスト担当者は
メトリクスを利用することにより、継続的に結果を報告することができ、それらの状況を一貫して追跡できる
テストマネージャは
メトリクスの定義：
メトリクスは有用なものに限定する必要がある。
メトリクスは、プロジェクト（進捗）、プロセス（欠陥割合）、プロダクト（テスト範囲、欠陥密度）ごとの目的に従って定義しなければならない。
単一のメトリックではステータスや傾向に関して誤って解釈される可能性があるので、メトリクスはバランスをとって定義しなければならない。
メトリクスを定義する上で、後でメトリクスの値だけが独り歩きして誤解が生じたりしないように、その解釈については、すべてのステークホルダからの合意を求める。
定義するメトリクスは、多くの場合、適切な数よりも多くなりすぎる傾向がある。
メトリクスの追跡：
メトリクスのレポートやメトリクスの集計に要する時間を短縮するために、生データからメトリクスを算出するまでを極力自動化すと良い。
ある特定のメトリックにおいて時間の経過によりデータが変化する場合、メトリックを定義した段階で合意した解釈以外の情報が影響していることもある。
テストマネージャは、測定値が期待している値から逸脱する可能性と、その逸脱の理由を入念に分析しなければならない
メトリクスのレポート：
レポートの目的は、マネジメントのために、速やかに理解できる情報を提供することである。
特定の時期での「スナップショット」や、時間の経過に伴うメトリックの変化を提示することにより、傾向を評価できる。
メトリクスの有効性：
テストマネージャは、報告された情報を検証しなければならない
メトリック用に取得された測定値が、プロジェクトの本当のステータスを反映していなかったり、過度に良い傾向または悪い傾向を示したりすることがある。
テストマネージャは、データを提示する前に、正確性、およびデー
タから読み取れるメッセージについて確認しなければならない
テスト進捗のモニタリングの対象には、次の5つの主要な要素がある。
プロダクト（品質）リスク
欠陥、テスト、カバレッジ
開発プロジェクトまたは運用期間を通して、特定の方法で測定し、
報告することが多い。このような測定は、テスト計画で定めた終了基準に関連する場合、テスト作業の完了を判断するための目標基準を提供する
確信度合い
調査を通して、またはカバレッジを代替メトリックとして使用
することにより測定できるが、主観的な報告になることが一般的
各要素に関連するメトリクス
プロダクトリスク
テストに合格することによって完全に対応されたリスクの割合
一部またはすべてのテストが不合格となるリスクの割合
テストが完了していないリスクの割合
リスクカテゴリで分類されたリスクのうち、対応されたリスクの割合
最初の品質リスク分析後に識別したリスクの割合
欠陥
レポート済みの（検出された）総数と解決済みの（修正された）総数の比
平均故障間隔（MTBF）または故障率
欠陥に関連するメトリクス
欠陥の数または割合：
特定のテストアイテムまたはコンポーネント
根本原因
欠陥の起源（たとえば、要求仕様、新しいフィーチャ、リグレッションなど）
テストリリース
混入／検出／除去されたフェーズ
優先度／重要度
拒否されたレポートまたは重複レポート
欠陥のレポートから解決に至るまでのタイムラグの傾向
新たな欠陥（daughter bug とも呼ばれる）を発生させた欠陥修正の数
テスト
計画、仕様化（実装）、実行、合格、不合格、ブロック、スキップしたテストの総数
回帰テストおよび確認テストのステータス（不合格となった回帰テストおよび確認テストの傾向および総数を含む）
計画している1 日当たりのテスト時間と実際のテスト時間との比
テスト環境の可用性（計画されたテスト時間のうち、テストチームがテスト環境を使用できる時間の割合）
テストカバレッジ
要件および設計要素のカバレッジ
リスクのカバレッジ
環境／構成のカバレッジ
コードカバレッジ
活動をモニタリングするメトリクス
テスト計画をモニタリングし、活動をコントロールするためのメトリクス
リスク、要件、および他のテストベース要素のカバレッジ
欠陥検出
テストウェアの開発とテストケースの実行に関する計画時間と実時間
テスト分析活動をモニタリングするためのメトリクス
識別されたテスト条件の数
テスト分析時に検出した欠陥の数（たとえば、テストベースを使用してリスクまたは他のテスト条件を識別することにより検出した数など）
テスト設計活動をモニタリングするためのメトリクス
テストケースによりテスト条件を網羅している割合
テスト設計時に検出した欠陥の数（たとえば、テストベースに対するテストを開発する際に検出した数など）
テスト実装活動をモニタリングするためのメトリクス
構築済みのテスト環境の割合
ロードしたテストデータレコードの割合
自動化したテストケースの割合
テスト実行活動をモニタリングするためのメトリクス
計画したテストケースで、実行、合格、および不合格となったテストケースの割合
実行、または合格したテストケースにより網羅したテスト条件の割合
レポート、または解決した欠陥の計画数と実際の数
達成したカバレッジの計画と実際の比
テストの進捗および完了の活動をモニタリングするためのメトリクス
計画したテスト条件、テストケースもしくはテスト仕様の数、結果を合格・不合格ごとに分類した数
発生した欠陥の総数を、重要度、優先度、現在の状態、影響を受けたサブシステム、または他の方法で分類した数（第4 章を参照）
変更の発生数、受け入れ数、ビルドした数、テスト済みの数
計画上のコストと実際のコストとの比
計画上の期間と実際の期間との比
テストのマイルストンのために計画した日数と実際に要した日数
テスト関連のプロジェクトマイルストン（たとえばコードフリーズなど）のために計画した日数と実際に要した日数
プロダクト（品質）リスクのステータス、軽減したものと軽減していないものの比、主なリスク領域、テスト分析後に検出された新しいリスクなど
進捗を妨げたイベントまたは計画された変更により無駄になったテスト活動、コスト、または時間の割合
確認テストと回帰テストのステータス
テスト終了活動をモニタリングするためのメトリクス
テスト実行中に実施したテストケース、合格したテストケース、不合格となったテストケース、ブロックしたテストケース、およびスキップしたテストケースの割合
再利用可能なテストケースとしてリポジトリにチェックインしたテストケースの割合
自動化したテストケースと自動化予定のテストケースの割合
回帰テストに統合したテストケースの割合
解決済みの欠陥レポートおよび未解決の欠陥レポートの割合
テスト成果物として識別し、保管したものの割合
アジャイルチームでは、テストはバーンダウン・チャートに示されるユーザストーリーの進捗の一部を構成する
リーンマネジメント技法を使用する場合、ストーリーベースのテスト進捗は、カンバンの列を通してユーザストーリーカードを移動させることによってモニタリングする
テストコントロールの目的は、プロジェクトまたはテストが成功に向かうよう軌道修正することである。テスト結果を使用してプロジェクトのコントロール活動に影響を与えるか、活動を測定する際に、次のオプションを考慮する必要がある。
品質リスク分析、テストの優先度、およびテスト計画の見直し
リソースの追加、またはプロジェクト活動やテスト活動の追加
リリース日の延期
テスト終了基準の緩和または厳格化
プロジェクトの対象範囲（機能および非機能）の変更
テストレポートは、プロジェクトマネージャにとっては、欠陥についての詳細情報が重要で、ビジネスマネージャにとっては、プロダクトリスクステータスが、報告されるべき重要になる
2.7 テストのビジネスバリュー
テストマネージャは、テストのステークホルダが、この最適なテスト量とテストにより提供される価値を理解できるようにする必要がある
テストは、組織、プロジェクト、運用に対し、定量的と定性的の両面において価値をもたらす。
定量的な価値としては、リリース前に予防／修正する欠陥の検出、リリース前に判明する欠陥の検出（修正していないが回避策と共に文書化している）、テスト実行によるリスクの軽減、プロジェクト／プロセス／プロダクトステータスについての情報提供などが挙げられる。
定性的な価値としては、品質による評判の向上、スムーズで予定を立てやすいリリース、確信度合いの向上、法律上の免責、システムが果たすべき使命が台無しになるリスクや、生命損失のリスクの軽減などが挙げられる
品質コスト（不良品質コスト）
テストの定量的価値および効率性を測定するために確立された方法
品質コストは、以下の4つのカテゴリに分類する
予防コスト
保守性が良く、セキュリティを強化したコードを記述するような開発者へのトレーニング
評価コスト
テストケースの記述、テスト環境の構成、要件のレビュー
内部失敗コスト
提供前の、テストまたはレビュー期間中に検出した欠陥の修正
外部失敗コスト
顧客に提供した欠陥ソフトウェアに関連するサポートコスト
テストマネージャは、この4 つのカテゴリでコストを判定することにより、テストに対する説得力のあるビジネスケースを作り出すことができる。
評価コスト：レビュー工数、テスト設計工数、テスト実行工数が該当す
内部欠陥コスト：レビューで検出した欠陥の修正工数、テストで検出した欠陥のデバッグ・修正工数が該当する
外部欠陥コスト：リリース後の欠陥修正工数が該当する
テストに価値をもたらしている状態
評価コスト（テスト担当者が欠陥を見つけなかった場合でもテストに要したコストや、テストを開発するために要したコスト）で、残りは内部失敗コスト（検出した欠陥に付随する実際のコスト）になる
評価コストと内部失敗コストの合計は通常、外部失敗コストを十分下回っている
評価コスト＋内部失敗コスト ＜ 外部失敗コスト
2.8 分散テスト、アウトソーステスト、およびインソーステスト
分散テスト
テスト活動が複数の地域で行われる
関係するすべてのチームに属するすべての人々が、自分の役割と責任だけでなく、他のグループの役割と責任も明確に理解して、誤解や非現実的な期待を避ける必要がある
マネジメントを適切に行わないと、ギャップ(出荷時の品質リスクが増す)や重複(作業効率が低下する)が発生し、テスト作業はうまくいかない可能性がある。
2つのテストグループが異なる方法を使用したり、テストグループが開発グループやプロジェクトマネジメントグループと異なる方法を使用したりすると、特にテスト実行において大きな問題になる
アウトソーステスト（オフショア）
テスト活動を、同じ企業の従業員でなく、プロジェクトチームと同じ地域にいない人たちによって、1 つの地域または複数の地域で実行する
インソーステスト（常駐）
テスト活動を、プロジェクトチームと同じ地域に存在するが同僚の従業員でない人々によって実行する場合
テスト活動のすべてにおいて、方法論の調整が共通して必要になる
このようなテスト活動では、共通して明確なコミュニケーションチャネルの他、使命、業務、提出書類に対する要望を十分にまとめる必要がある
プロジェクトチームは、非公式なコミュニケーションチャネルにあまり依存してはならない
コミュニケーションを行う方法を定義することが重要
この定義では、問題のエスカレーション、コミュニケーションされる情報の種類、使用されるコミュニケーション方法などのトピックに対応する必要がある
このようなテスト活動のすべてにおいて、方法論の調整が共通して必要
たとえば、クライアントがアジャイル開発を使用し、テストサービスプロバイダがシーケンシャルライフサイクルを想定する定義済みのテスト方法を所有する場合、テストサービスプロバイダにテストアイテムを提供するタイミングと提供する状態が、論点になる
分散テストの場合、テスト作業を複数の地域に分割することを明示し、これを合理的に決定しなければならない
マネジメントを適切に行わないと、ギャップ（出荷時の品質リスクが増す）や重複（作業効率が低下する）が発生し、テスト作業はうまくいかない可能性がある。
テスト活動のすべてにおいて、プロジェクトチーム全体の力で、それぞれのテストチームが、組織、文化、言語、地理的な境界を越え役割を正しく果たすという信用を勝ち取り維持することが、きわめて重要
2.9 業界標準適用のマネジメント
テストマネージャは、標準、標準の使用に関する組織のポリシー、標準の使用が必須なのか、必要なのか、または役立つのかどうかを把握する必要がある
国際標準または国際的な標準になることを目的としたもの
国内標準、例えば国際標準を国レベルで適用したもの
ドメイン固有のひょうじゅん、例えば国際標準または国内標準を特定のドメインに適合したものや、特定のドメイン向けに作成したもの
テストに主眼としている標準
ISO9126（ISO 25000 に改訂中）、ISO 12207 [ISO12207]、ISO 15504 [ISO15504]など、ソフトウェアテスト担当者にとって有用な、多くの標準を推進してきた。
IEEE 829 [IEEE829]やIEEE 1028 [IEEE1028]など、ソフトウェアテスト担当者にとって有用な、多くの標準を提案してきた。
航空関連システムのドメインでは、米国連邦航空局の標準DO-178B（およびEU 版のED 12B）が、民間航空機で使用するソフトウェアに適用される
医療システムドメインには、米国食品医薬品局（FDA）のTitle 21 CFR
Part 820 [FDA21]がある。この標準は、一定の構造的および機能的なテスト技法を推奨している。また、ISTQB シラバスと一貫性のあるテスト戦略と原則を推奨している
Title 21 CFR Part 820：医療システムドメインの米国食品医薬品局(FDA)
IEEE829：テストドキュメントの標準を定義する国際標準である。
BS 7925-2：英国のソフトウェアテストに関する国内標準である。
DO-178B：民間航空機で使用するソフトウェアに適用される標準である。テストを主眼としていないもの
CMMI
ソフトウェアプロセス改善フレームワークである。このフレームワークには、検証と妥当性確認の2 つのキープロセスエリアがあり、これらは、テストのレベル（それぞれシステムテストと受け入れテスト）として解釈されることがある。また、テスト戦略を記述した部分もあり、分析的な要件ベースドテストをテスト戦略の一部として包含することを要求している
PMI とPRINCE2
それぞれ北米とヨーロッパで一般的に使用しているプロジェクトマネジメントフレームワークである
ITIL
ITグループが、自分の所属する組織に価値あるサービスを確実に提供できるようにするフレームワークである
この記事が気に入ったらサポートをしてみませんか？