JSTQB Advanced Level シラバス(テストマネージャー)を読む その８．テストマネジメント編④
こんちは。アジアの奇跡 ふっくら太郎です。
2017年8月26日(土曜)に実施されるJSTQB AdvancedLevel試験 テストマネージャー受験に向け、短期集中で、JSTQB Advanced Level シラバス(テストマネージャー)についての記事を上げていきたいと思います。
今回は、「テストマネージメント」の「2.5 テストの見積り」、「2.6 テストメトリクスの定義および使用」について、読み解きたいと思います。
[JSTQB AdvancedLevel テストマネージャー シラバス]
・ISTQBテスト技術者資格制度
Advanced Level シラバス 日本語版 テストマネージャ Version2012.J03
http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf
2.5 テストの見積り
- テストの見積りとは？
・プロジェクトに関わる活動に関するコストおよび終了日の近似値。
・テスト実行は、一般的にプロジェクトのクリティカルパスになるため、テスト
実行の見積りは、マネージメントにおいて最も重要な要素になる。
・見積りの信頼性は、ソフトウェアの品質に左右される。
・見積りの際に設定した予測欠陥数等の仮定は、見積りの一部として記述する必
要がある。
・テスト見積りは、コスト、工数、期間に影響をおよぼすあらゆる要素につい
て、考慮が必要になる。
[テスト見積りに影響をおよぼす要素(例)]
・システムに求められる品質レベル
・テスト対象のシステムのボリューム
・過去のテストプロジェクトの実績
・プロセス要因、プロセスの成熟度合い
・テストツールや環境、テストデータ等の物的要因
・プロジェクトチームの技術スキルやマネージメントスキル等の人的要因
・プロセス、技術、組織の複雑さ
・トレーニングやオリエンテーションの必要性
- テスト見積りで用いる技法
・直感、推測、および過去の経験。
・WBS (Work Breakdown Structure：作業分解構成図)
・テストチームでの見積り (ワイドバンドデルファイなど)
・企業標準、基準を用いた見積り。
・プロジェクトの総工数またはスタッフ構成の割合を用いた見積り。
・組織のデータ蓄積およびメトリクス。
(欠陥数、テストサイクル数、テストケース数、テスト実施工数など・・・)
・業界平均および予測モデル。
(ファンクションポイント、コード行数、開発工数など・・・)
- 見積りを行う上での注意事項。
・見積りには根拠が必要。
・理想の見積りは、品質、スケジュール、予算、組織とプロジェクトの目標がバ
ランス良く調整されたもの。
・プロジェクト初期段階では、見積りに使用できる情報は少ない。見積りの正確
性を維持するため、プロジェクト期間中も見積の更新が必要。
2.6 テストメトリクスの定義および使用
- テストメトリクスの分類
・それぞれのメトリックスは、複数のカテゴリに属することがある。
| メトリクスの種類 | 説明 |
| プロジェクトメトリクス | テスト消化率など、プロジェクト終了基準に対する進捗を測定する。 |
| プロダクトメトリクス | テスト範囲、欠陥密度など、プロダクトのいくつかの属性について測定する。 |
| プロセスメトリクス | テストで検出された欠陥の割合など、テストプロセスまたは開発プロセスの能力を測定する。 |
| 人的メトリクス | 指定されたスケジュールでのテストケースの実施など、個人またはグループの能力を測 定する。 |
- メトリクスを用いて行うこと
・テスト担当者
→継続的なテスト結果の報告、テスト状況の追跡。
・テストマネージャ
→ステークホルダへのプロジェクト情報を提示。
- メトリクスを扱う上での考慮事項
・メトリクスの定義
→有用な情報に限定して測定する。
→プロジェクト、プロセス、プロダクトごとの目的に従って定義する。
→メトリクスは複数用いて総合的に偏りがないよう定義する。
→メトリクスの解釈について、すべてのステークホルダから合意を取る。
・メトリクスの追跡
→効率的にメトリクスを集計するため、自動化を検討する。
→時間経過により情報が変化することで、判定基準が変わる可能性があるメト
リクスについては、テストマネージャは、測定値が期待している値から逸脱
する可能性と、その理由を分析しなければならない。
・メトリクスのレポート
→レポートの目的は、マネージメントに必要な情報を早急に提供するため。
→特定の時期での「スナップショット」や、時間経過に伴うメトリックスの変
化を提示することで、傾向を評価できる。
・メトリクスの有効性
→テストマネージャは報告された情報を検証して、データの正確性、メトリク
スの有効性を評価しなければならない。
- テスト進捗のモニタリング対象
| モニタリング項目 | 項目が持つ情報 |
| プロダクト(品質)リスク | 開発プロジェクトを通して計測することで、テスト計画で定めた終了基準に到達しているかの判断に使用できる。 |
| 欠陥 | 上と同じ。 |
| テスト | 上と同じ。 |
| カバレッジ | 上と同じ。 |
| 確信度合い | 主観的な報告の根拠としてデータを用いることができる。 |
- プロダクトリスクに関連するメトリクス
・テスト合格により完全に対応されたリスクの割合
・一部または全てのテストが不合格となるリスクの割合
・テストが完了していないリスクの割合
・リスクカテゴリで分類されたリスクのうち、対応されたリスクの割合
・最初の品質リスク分析後に識別したリスクの割合
- 欠陥に関連するメトリクス
・起票不具合総数と修正された不具合総数の比。
・欠陥の数または割合
→特定のテストアイテムまたはコンポーネント
→根本原因
→欠陥の起源
→テストリリース
→混入/検出/除去されたフェーズ
→優先度/重要度
→起票ミス (テストミス)、重複不具合
・欠陥のレポートから解決に至るまでのタイムラグの傾向
・新たな欠陥を発生させた欠陥修正数
- テストに関係するメトリクス
・計画、仕様化 (実装)、実行、合格、不合格、ブロック、スキップしたテストの
総数
・不合格となった回帰テストおよび確認テストの傾向および総数
・1日あたりのテスト生産性の予実差
・テスト環境の可用性 (計画しているテスト時間と実際に使用できる時間の割合)
- テストカバレッジに関連するメトリックス
・要件および設計要素のカバレッジ
・リスクのカバレッジ
・環境/構成のカバレッジ
・コードカバレッジ
- テスト計画をモニタリングし、活動をコントロールするためのメトリクス
・リスク、要件、および他のテストベース要素のカバレッジ
・欠陥検出
・テストウェアの開発とテストケースの実行に関する計画時間と実時間の差異
- テスト分析活動をモニタリングするためのメトリクス
・識別されたテスト条件の数
・テスト分析時に検出した欠陥数
- テスト設計活動をモニタリングするためのメトリクス
・テストケースのテスト条件網羅率
・テスト設計時に検出した欠陥数
- テスト実装活動をモニタリングするためのメトリクス
・構築済みのテスト環境の割合
・ロードしたテストデータレコードの割合
・自動化したテストケースの割合
- テストの進捗および完了の活動をモニタリングするためのメトリクス (テストの開始基準、終了基準、マイルストーンに対して割り当てられるもの)
・計画したテスト条件、テストケースもしくはテスト仕様の数
・結果を合格・不合格ごとに分類した数
・発生した欠陥の総数を、重要度、優先度、現在の状態、影響を受けたサブシス
テム、または、ほかの方法で分類した数
・変更の発生数。受入数、ビルドした数、テスト済の数
・計画上のコストと実際のコストの比
・計画上の期間と実際の期間との比
・テストのマイルストンのために計画した日数と実際に要した日数
・テスト関連のプロジェクトマイルストン
・プロダクト (品質) リスクのステータス、軽減したものと軽減していないものの
比、主なリスク領域、テスト分析後に検出された新しいリスクなど
・進捗を妨げたイベントまたは計画された変更により無駄になったテスト活動、
コスト、または時間の割合
・確認テストと回帰テストのステータス
- テスト終了活動をモニタリングするためのメトリクス
・テスト実行中に実施したテストケース、合格したテストケース、不合格となっ
たテストケース、ブロックしたテストケース、およびスキップしたテストケー
スの割合
・再利用可能なテストケースとしてリポジトリにチェックインしたテストケース
の割合
・自動化したテストケースと自動化予定のテストケースの割合
・回帰テストに統合したテストケースの割合
・解決済みの欠陥レポートおよび未解決の欠陥レポートの割合
・テスト成果物として識別し、保管したものの割合
- メトリクス測定結果の活用方法
| 分析 | テスト結果で発見した問題の傾向と原因を分析する。 |
| レポート | テストで気づいた内容をプロジェクト参加者およびステークホルダに伝える。 |
| コントロール | 一連のテストまたはプロジェクトを全体として見直し、その結果をモニタリングする。 |
- テストコントロールの目的
・テスト計画から逸脱がある場合は、プロジェクトまたはテストが成功に向かう
ように、軌道修正すること。
- テストコントロールの実行方法
・品質リスク分析、テストの優先度、およびテスト計画の見直し
・リソースの追加、またはプロジェクト活動やテスト活動の追加
・リリース日の延期
・テスト終了基準の緩和または厳格化
・プロジェクトの対象範囲 (機能および非機能)の変更
まとめ
-
テスト実行は、一般的にプロジェクトのクリティカルパスになるため、テスト実行の見積りは、マネージメントにおいて最も重要な要素になる。
-
見積りの信頼性は、ソフトウェアの品質に左右される。
-
プロジェクト初期段階では、見積りに使用できる情報は少ない。見積りの正確性を維持するため、プロジェクト期間中も見積の更新が必要。
- テストメトリクスは、「プロジェクトメトリクス」、「プロダクトメトリクス」、「プロセスメトリクス」、「人的メトリクス」の4つに分類される。中でも、JSTQBでは「プロジェクトメトリクス」の使用に重点が置かれる。
- メトリクスはテストプロセス全体で、テストプロセス自体とプロジェクト目標への進捗をモニタリングするために使用できる。
