こちらの記事ではJSTQBのシラバスのうち、第5章テストマネジメント分野<5.3テストのモニタリングとコントロール～5.6欠陥マネジメント>における以下の分野の学習内容及び学習してみて私が思ったことについて記載します。
【JSTQB(FL)対策】第5章テストマネジメント<5.3テストのモニタリングとコントロール～5.6欠陥マネジメント>
1. テストのモニタリングとコントロール
テストモニタリングの目的はテスト活動に関連する情報を取集し、可視化をし、フィードバックをかけることである。
テストコントロールは収集、報告されたテストの実施結果に基づき、ガイドや補正のアクションをすることである。
テストコントロールの作業の一部としては以下のものがある。
・リリースの遅延などといった識別したリスクが実際に発生した場合はテスト優先度の見直しを行う。
・テスト環境やほかのリソースの利用ができるか否やでテストスケジュールの変更を行う。
・再作業が発生した場合に、テストアイテムが開始基準と終了基準を満たすかを再評価する。
1-1. テストで使用するメトリクス
メトリクスは収集したデータに分析を加えてわかりやすいデータに変換したもの。メトリクスは以下の項目をテスト活動の期間中及び終了時に収集する。
・テスト活動の計画したスケジュールや予算に対する進捗
・テスト対象の品質
・テストアプローチの十分性
・テスト目的に対するテスト活動の結果
代表的なテストメトリクスには以下のものがあげられる。
・計画したテストケースの準備の完了、または実装した割合
・計画したテスト環境の準備が完了した割合
・実行・未実行や合格・不合格のテストケース数などといったテストケースの実行
・欠陥密度や故障率などといった欠陥情報
・要件、ユーザーストーリー、受け入れ基準、リスク、コードのテストカバレッジ
・タスクの完了、リソースの割り当てと稼働状況、工数
・テスト活動に費やすコスト
1-2. テストレポートの目的、内容、読み手
テストレポートはテスト活動の進捗及びテストの結果をまとめた報告書のことである。
テストレポートの目的はテスト活動の期間中と終了時の両方の時点におけるテスト活動の情報要約し周知することである。
テストレポートには以下の２種類のレポートがある
・テスト進捗レポート
・テストサマリーレポート
テスト進捗レポート
テスト進捗レポートはテスト活動の期間中に作成するレポートのことである。
典型的なテスト進捗レポートは以下のものが含まれる。
・テスト活動の状況及びテスト計画書に対する進捗
・進捗を妨げている要因
・次のレポートまでの間に計画されているテスト
・テスト対象の品質
テストサマリーレポート
テストサマリーレポートはテスト進捗レポートと対照的にテスト活動の終了時に作成するレポートのことである。
典型的なテストサマリーレポートは以下のものが含まれる。
・テストの要約
・テスト期間中に発生した出来事
・テスト活動のスケジュールなどといった計画からの逸脱
・終了基準、または完了の定義に対するテストとプロダクト品質の状況
・進捗を妨げた要因
・欠陥、テストケース、テストカバレッジ、活動進捗、リソース消費のメトリクス
・残存リスク
・再利用可能なテスト作業成果物
2. 構成管理
構成管理とは。構成管理ではテスト支援のために以下のことを明確にする。
・すべてのテストアイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残して各アイテム間の関連付けを行う。
・テストうぇあのすべてのアイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残し、各アイテム間の関連付けを行う。
・識別したすべてのドキュメントやソフトウェアアイテムは、テストドキュメントに明確に記載してある。
3. リスクとテスト
3-1. リスクの定義
リスクは将来に否定的な結果となる事象が起きる恐れを含むものである。
リスクレベルはそのような事象が発生する可能性とその影響で決まる。
リスクには後述するプロダクトリスクとプロジェクトリスクがある。
3-2. プロダクトリスクとプロジェクトリスク
プロダクトリスクは成果物がユーザー、及び(または)ステークホルダーの正当なニーズを満たすことができないといった、プロダクトが低品質になってしまうリスクを指す。
プロダクトリスクの事例の一部として以下のものを含む。
・ソフトウェアの意図されている機能が想定通りに動かなかったり、ユーザーや顧客、ステークホルダーのニーズ通りに動かなかったりする可能性がある。
・システムアーキテクチャーが十分に非機能要件をサポートしない場合がある。
・特定の計算が正確な結果にならないことがある。
・ループ制御構造が正確にコーディングされていない場合がある。
・高性能なトランザクション処理システムでも応答時間が不適切な場合がある。
・ユーザーエクスペリエンス(UX)のフィードバックがプロダクトの期待と異なる可能性がある。
プロジェクトリスクはプロジェクトの目標達成に対して障害を与えるリスクのことを指す。
プロジェクトリスクの事例の一部として以下のものを含む。
・プロジェクトの懸念事項
→リリース、タスク完了、終了基準または完了の定義達成の遅延により、テスト活動のスケジュールの進捗が悪い。
→不正確な見積もり、高優先度のプロジェクトへの資金の再割り当て、組織全体経費削減により資金不足に陥る。
→プロジェクト終盤での変更発生により作業の大規模なやり直しが発生する。
・組織の懸念事項
→人員不足、または人員のスキルやトレーニングが不足している場合がある。
→人間関係における問題や衝突の恐れがある。
→ビジネス上の優先度競合によりユーザーや専門家などの都合がつかない場合がある。
・政治的な懸念事項
→テスト担当者が自分たちのニーズ及び(または)テスト結果を十分に伝えられない場合がある。
→開発・テスト担当者がテストやレビューで発見された事項をうまく改善ができない場合がある。
→テストで発見された欠陥情報を真摯に受け止めないなど、テストから期待できるものを正しく評価しようとしない場合がある。
・技術的な懸念事項
→要件の定義が不十分である
→制約のために要件を満たさない場合がある。
→テスト環境が予定していた期限までに用意できない場合がある
→データ変換及び移行の計画、それらのツールによる支援に遅れが発生する場合がある。
→開発プロジェクトの弱点がプロジェクトの作業成果物間のセ号性や品質に影響を与える場合がある。
→不適切な欠陥マネジメントやその類似問題により、欠陥やほかの技術的負債が累積する場合がある
・供給者側の懸念事項
→サードパーティが必要プロダクトまたはサービスを提供できない場合がある。
→契約上の懸念事項がプロジェクトの問題の原因になる場合がある。
3-3. リスクベースドテストとプロダクト品質
プロダクトリスクを軽減する予防措置としてリスクベースのアプローチが採用される。
リスクベースのアプローチでは分析結果を使用して以下のように対処をする。
・適用するテスト技法の決定。
・実施するテストレベル及びテストタイプの決定。
・テスト実行範囲の決定。
・重大な欠陥を早期に検証するためのテストの優先順位の決定。
・テスト以外の活動でのリスク軽減方法がないかの検討。
リスクベースドテストは以下のように進める必要がある。
・うまくいかないところの分析
・リスク重要度の決定
・重大なリスクの処理方法の実装
・実際にリスクが発生した時に備えるためのコンティンジェンシープランの作成。
4. 欠陥マネジメント
欠陥マネジメントは欠陥の認識や修正などに関するマネジメントを指す。
典型的な欠陥レポートには以下のような目的がある。
・開発者が欠陥の情報を提供したり、欠陥を修正したりする。
・テストマネージャーに対し、作業成果物の品質やテストへの影響を追跡する手段を提供する。
・開発プロセス及びテストプロセスを改善するためのヒントを提供する。
5. エピローグ
第5章テストマネジメント分野<5.3テストのモニタリングとコントロール～5.6欠陥マネジメント>を学習してみて、テストマネジメントをするうえでどのようなレポートを作成するのかやどのようなリスクに直面するのかなどについて学習ができたため、今後案件でテストマネジメントをすることになった際の大きな参考になったと思いました。