Recommended
Recommended
More Related Content
Featured
Featured (20)
【JSTQB_ALTM】シラバス第4章
- 2. 4.1:イントロダクション • 欠陥マネジメントによって収集される情報は... • PJの状態を把握するのに役立つ • 長期間のデータ収集および分析により、テストor開発プロセスの改善領 域を見つけられる • 欠陥マネジメントにおいてTMに求められること • 欠陥ライフサイクルおよび、それを用いたテストor開発プロセス のモニタリング＆コントロール方法の理解 • 取得すべきデータへの精通 • プロセスと、欠陥マネジメントツール双方の適切な使用の提唱
- 4. 4.2:欠陥ライフサイクルとソフトウェア開発ライフサイクル • 欠陥の発生原因 • 成果物作成時の人の誤り • 欠陥が混入しうる箇所 • 要求仕様 • ユーザーストーリー • テクニカルドキュメント • テストケース • プログラムコード • その他、開発プロセスで作成した成果物
- 5. 4.2:欠陥ライフサイクルとソフトウェア開発ライフサイクル • 欠陥は、開発ライフサイクルや開発に関連する成果物の いずれの場所にも混入する可能性がある • 故に、潜在的な欠陥を検出＆除去するための活動を、 開発の各フェーズに含める必要がある • 例）要求仕様、設計仕様、コードに対し、レビューや静的解析を行 った後に、次の工程に進む • 欠陥の検出＆除去が早いほど、全体の品質コストは低くなる • 混入と除去が同じフェーズだと、そのフェーズの欠陥に対する品質コス トは最小化される（フェーズ内阻止） • 静的テストは欠陥を直接発見できる • デバッグ活動を必要としないため、欠陥除去コストはさらに下がる
- 6. 4.2:欠陥ライフサイクルとソフトウェア開発ライフサイクル • 動的テストでは「故障の発生により」欠陥の存在が明らかになる • これにより「不正」が生じる • テスト担当者が不正を観察しない場合、偽陰性結果が発生する • テスト担当者が不正を観察すると、さらなる調査が必要になる • この調査は、欠陥レポート登録から始まる • テスト駆動開発では自動化されたUTを、実行可能な設計仕様 という形で使用する • コードを開発するとすぐにこれらを用いてテストを行う • ユニットの開発が完了するまで一部or全てのテストは失敗する • このようなテストで検出した故障は欠陥とはみなさない
- 8. 4.2.1 欠陥ワークフローと状態 • 欠陥レポートのマネジメントのためには、ツールを使用するのが一般的 • 欠陥レポートは決められたフローを通り、 一連の「状態（ステータス）」を遷移する • 各状態において、欠陥ライフサイクル参加者の1人が レポートの所有者となる • 所有者は、自身のタスク完了時に欠陥レポートの状態を 変更する責任を持つ • 「クローズ」「キャンセル」「非再現」「延期」といった終了状態 は、所有者がいなくなる（さらなる対応を必要としないため）
- 9. 4.2.1 欠陥ワークフローと状態 • 発見した欠陥に対してテストチームが対応すべき3つの状態（ステータス） 状 態 別 名 説 明 初期 「オープン」 「新規」 ・欠陥を解決する人が不正を再現できるよう、テストチームが必要な 情報を収集する 返却 「拒否」 「明確化」 ・レポートの受取人が拒否or追加情報を依頼している ┗初期の情報orテスト自体が不十分だったことを意味する ・テスト担当者は、追加情報の提供or実際に拒否されるべきものであ ることの確認を行う ・TMは、返却の割合が過剰でないかをモニタリングする 確認テスト 「解決済み」 「検証」 ・確認テストを実行し、解決策により問題が解決されたかを確認する ┗欠陥の修正が示唆される場合、レポートをクローズする ┗修正が示唆されない場合、以前の所有者にレポートを割り当てる
- 11. 4.2.2 無効および重複した欠陥レポートのマネジメント • 特定の状況では、「欠陥の兆候」以外で不正が生じる場合がある • テスト環境、テストデータ、テストウェアの影響 • テスト担当者の誤解 • 欠陥レポートをオープン後、それが欠陥によるものではないと判明した場合 • 「偽陽性」結果となる • 「無効」な欠陥レポートとして、キャンセルorクローズする
- 12. • 1つの欠陥が、テスト担当者にとって全く関連しない（ように見える） 複数の兆候を示すことがある • 複数の欠陥レポートをオープン後、 それが1つの根本原因によるものであることが判明した場合 • それらの欠陥レポートの内1つを残す • 他のレポートは「重複」としてクローズする 4.2.2 無効および重複した欠陥レポートのマネジメント
- 13. • 「無効」or「重複」レポートは非効率である • しかしこれらのレポートの発生はTMにとって、 予測可能であり受け入れるべきものである • これらのレポートを排除しようとすると、テスト担当者は欠陥レポ ートの登録をためらうようになる 偽陰性の数が増加し、欠陥検出効率が低下する 4.2.2 無効および重複した欠陥レポートのマネジメント
- 15. • テスト組織とマネージャは通常、全体的な 欠陥マネジメントプロセスと欠陥マネジメントツールを所有する • 一方で、クロスファンクショナルなチームは一般的に、 特定のプロジェクトでレポートされた欠陥のマネジメントを担当する。 • クロスファンクショナルなチーム＝「欠陥マネジメント委員会」 4.2.3 クロスファンクショナルな欠陥マネジメント
- 16. • 欠陥マネジメント委員会の参加者 • テストマネージャ • 開発者 • PM • PdM • その他のステークホルダ 4.2.3 クロスファンクショナルな欠陥マネジメント
- 17. • 欠陥マネジメント委員会が行うこと 1. ミーティングの開催 • 不正が欠陥マネジメントツールに登録された後 2. 欠陥レポートの検証 • レポートが有効な欠陥を示しているか 3. 解決or延期の意思決定 • それぞれ（解決・延期）のメリット、リスク、コストの検討 • （解決の場合）優先度の決定 • TM（テストチーム）→決定のための客観的情報を提供する 4.2.3 クロスファンクショナルな欠陥マネジメント
- 18. コミュニケーション 適切なツールの活用 適切に定義された欠陥ライフサイクル 欠陥マネジメント委員会の関与 全て、効果的/効率的な欠陥マネジメントに必要不可欠 • NG例 • 良いコミュニケーションが取れているから、欠陥追跡ツールは使わない • 欠陥追跡ツールを効果的に使っているから、欠陥マネジメント委員会 MTGは行わない 4.2.3 クロスファンクショナルな欠陥マネジメント
- 21. • データは、3つの目的を満たす必要がある • 1 : 欠陥ライフサイクル全体でのレポートのマネジメント • 2 : PJステータスのアセスメント（特にプロダクト品質とテスト進捗） • 3 : プロセス能力のアセスメント（4.4節参照） • 1と2のために必要なデータは、欠陥の検出タイミングによって異なる • 早い段階であればあるほど、必要な情報は少なくなる • ただし、核となる情報はライフサイクル全体で、かつ （理想的には）全PJで一貫している必要がある • Why？→プロセスに関連する欠陥データの比較ができるように 4.3 欠陥レポート情報
- 22. • 収集された欠陥データは、以下に活用できる • テスト進捗のモニタリング＆コントロール • 終了基準の評価 • 欠陥情報の活用例 • 欠陥密度分析 • 欠陥の傾向分析 • 検出～解決までの平均時間 • 故障強度（MTBF分析など） 4.3 欠陥レポート情報
- 23. • 収集するべき欠陥データ（1/4） 4.3 欠陥レポート情報 データ 備考 欠陥の発見者 役割（エンドユーザー、開発者、テクニカルサポートなど）も 問題の概要・詳細 再現手順・実際の結果と期待結果 可能な場合はスクリーンショット、データベースダンプ、ログ 欠陥混入、検出、除去したフェーズ 可能な場合はテストレベルも 欠陥が混入した成果物 ステークホルダへのインパクトの重要度 システムの技術的振る舞いにより決定する 問題を解決する優先度 故障のビジネスインパクトにより決定する
- 24. • 収集するべき欠陥データ（2/4） 4.3 欠陥レポート情報 データ 備考 欠陥が存在するサブシステムor コンポーネント 欠陥の偏在の分析に活用 検出時に実行していたPJ活動 問題を明らかにした識別方法 レビュー、静的解析、動的テスト、実運用など 欠陥の種類 使用する欠陥分類法に対応する 欠陥により影響を受ける品質特性 欠陥を観察したテスト環境 問題が存在するPJとプロダクト
- 25. • 収集するべき欠陥データ（3/4） 4.3 欠陥レポート情報 データ 備考 現在の所有者 問題に関する作業が現在割り当てられている人 レポートの現在の状態 欠陥追跡ツールによりライフサイクルの一部としてマネジメン トする 問題を観察 及び 解決した特定の成果物 テストアイテムとそのリリース番号など プロジェクトorプロダクト ステークホルダの利害へのインパクト 問題を解決するためのアクションの実行 または不実行に関する結論、提案、承認 欠陥を解決する、または解決しない場合の リスク、コスト、機会、メリット
- 26. • 収集するべき欠陥データ（4/4） 4.3 欠陥レポート情報 データ 備考 欠陥ライフサイクルの遷移に伴う情報 ・欠陥ライフサイクルのさまざまな遷移が発生した日付 ・各遷移でのレポートの所有者 ・欠陥の特定、修正および、解決を検証するためにプロジェク トチームメンバが行ったアクション 欠陥を最終的に解決した方法、および 解決策をテストするための推奨策 欠陥をソフトウェアの変更により解決した場合 その他の情報 ・欠陥を明らかにしたテスト ・欠陥に関連するリスク、要件、 ・他のテストベース要素など（動的テストの場合）
- 27. • 収集すべきデータを決定するのに役立つ、標準やドキュメント • ISO 9126 / IEEE 829 / IEEE 1044 / 直交欠陥分類法 収集すべきだと決定した情報が何であろうと 「完全、簡潔、正確、客観的、適切、タイムリー」な情報の入力が重要 • 欠陥レポートに関する問題は... • 「個々の欠陥の解決のため」なら、手動操作や対面コミュニケーション によりカバーできることもある • 一方で「PJステータス、テスト進捗、プロセス能力の適切なアセスメン トのため」においては「解決不可能な障害」をもたらす可能性がある 4.3 欠陥レポート情報
- 29. • TMは、テストプロセス能力＆開発プロセス能力の評価のために、 「欠陥レポートが何を意味するのか」を認識する必要がある • 欠陥情報は、プロセス改善の取り組みを支援する必要がある 4.4 欠陥レポート情報によるプロセス能力の評価 何の情報を 何に使う 欠陥の混入、検出、除去 フェーズの情報 ・フェーズ内阻止の評価 ┗各フェーズでの欠陥検出効率改善のための提案 ・品質コスト分析の実行 ┗欠陥により発生するコストの最小化 欠陥の根本原因情報 ・欠陥混入の基になる理由の確認 ┗欠陥総数削減のためのプロセス改善 欠陥の混入フェーズ情報 ・欠陥が最も多く混入したフェーズのパレート分析 ┗欠陥総数削減のための改善 欠陥コンポーネントの情報 ・欠陥の偏在の分析 ┗テクニカルリスク（リスクベースドテストの場合）の理解 ┗問題の多いコンポーネントのリエンジニアリングを可能にする
- 31. おつかれさまでした！！