🎸

欠陥マネジメント JSTQB Advanced Levelテストマネージャ資格のキーワード解説！

2023/12/03に公開

JSTQB

概要

※シラバスを基に作成しています。

https://youtu.be/E87fNWu-s00

組織の欠陥管理プロセスと、この作業に使用されるツール（JIRA、バックログなど）は、テストチームだけでなく、ソフトウェア開発に関わるすべてのチームにとって非常に重要です。欠陥の効率的な管理を通じて収集される情報は、テストマネージャーや他のプロジェクト関係者が開発ライフサイクル全体にわたってプロジェクトの状態を理解するのに役立ちます。長期にわたってデータを収集・分析することで、テストプロセス及び開発プロセスの改善が見込める領域を見つけることができます。

テストマネージャーは、全体の欠陥ライフサイクルを理解し、それを用いてテストプロセスとソフトウェア開発プロセスの両方を監視・制御する方法だけでなく、収集すべき重要なデータに精通している必要があります。また、プロセスと選択した欠陥管理ツールの両方を適切に使用することを提唱する必要があります。

ソフトウェア欠陥の検出と管理：品質保証のためのフレームワーク

欠陥は人が成果物を作成する際に誤りを犯すと混入します。欠陥が混入する成果物には次のようなものがあります。

要求仕様
ユーザーストーリー
テクニカルドキュメント
テストケース
プログラムコード
その他ソフトウェア開発プロセスやメンテナンスプロセスで作成される成果物

欠陥はソフトウェア開発ライフサイクルの任意の場所、またはソフトウェア関連の成果物に混入する可能性があります。したがって、ソフトウェア開発ライフサイクルの各フェーズでは、潜在的な欠陥を検出し除去する活動が必要です。

静的テスト

静的テストの例

要求仕様、設計仕様をレビュー
コードを静的解析する

欠陥を早期に検出し除去するほど、システムの全体的な品質コストは低減します。欠陥を混入した同じフェーズ内で除去すると、そのフェーズの品質コストが最小化されます。さらに、静的テストが故障ではなく欠陥を直接発見することが説明されています。このため、デバッグ活動を必要とせずに欠陥を特定し除去するコストは低くなります。

動的テスト

動的テストの例

ユニットテスト（JSTQBシラバスをベースにすると画面単体や機能単体のテストをユニットテストと表現する）
統合テスト
システムテスト

故障の発生によって欠陥の存在が明らかになります。これにより実際の結果とテストの期待結果に差異が生じます。テスト担当者が不正を観察しなければ、偽陰性結果が発生することがあります。不正が観察された場合、さらなる調査が必要となり、この調査は欠陥レポートの登録から始まります。

TTD（テスト駆動開発）

テスト駆動開発では、自動化されたユニットテストを実行可能な設計仕様として使用します。コード開発時にはこれらのテストを直ちに実施します。ユニット開発完了までは一部または全てのテストが失敗します。このため、このようなテストで検出された故障は欠陥と見なされず、通常追跡されません。

欠陥管理プロセスのフェーズと責任

欠陥ライフサイクルの管理と終了状態の定義

ほとんどのテスト組織は、欠陥ライフサイクルを通じて欠陥レポートを管理するためにツールを使用します。欠陥レポートはワークフローを通じて進行し、ライフサイクルの進捗に応じて一連の状態を遷移します。これらの状態のほとんどでは、欠陥ライフサイクルの参加者がレポートの所有者となり、完了した場合にレポートを次の状態へ遷移させ（そして次の担当者に割り当てる）責任を持ちます。

次の終了状態では、さらなる活動を必要としないため、所有者が不要となります。

クローズする（基になる欠陥が解決し確認テストにより検証された場合）
キャンセルする（レポートが無効である場合）
再現できない（不具合が再現しない場合）
延期する（不具合は欠陥だが、プロジェクト内で修正しない場合）

欠陥レポートの状態とその管理

欠陥のライフサイクルは3つの主要な状態を持ちます。

初期状態（オープン・新規）
この状態でテスト担当者は、欠陥を解決する責任を持つ人が不正を再現できるように必要な情報を収集します。収集した情報は欠陥レポートに含められます。

返却状態（拒否・明確化）
レポート受取人がレポートを拒否するか、テスト担当者に追加情報を要求する状態です。これは初期の情報収集プロセスやテスト自体が不十分であったことを意味します。テストマネージャーは返却の割合を監視し、テスト担当者は追加情報を提供するかレポートが拒否されるべきものかを確認します。

確認テスト状態（解決済み・検証）
テスト担当者は確認テストを実行し、解決策によって問題が実際に解決されたかを確認します。確認テストで問題が解決されたことが示唆された場合、テスト担当者はレポートをクローズします。問題が解決されていないことが示唆された場合、テスト担当者はレポートを再オープンし前の所有者に割り当てます。前の所有者は欠陥修復のための作業を完了します。

テストプロセスにおける偽陽性と重複欠陥レポートの管理

特定の状況では、不具合が欠陥の兆候としてではなく、以下の原因により発生することがあります。

テスト環境
テストデータ
テストツールの他の要素
テスト担当者自身の誤解

テスト担当者が欠陥レポートをオープンし、その後レポートがテスト成果物の欠陥とは関連しないと判明した場合、それは偽陽性結果となります。このようなレポートは、無効な欠陥レポートとしてキャンセルされるか、クローズされます。
また、一つの欠陥が異なる症状を示し、テスト担当者にとって全く関連がないように見えることもあります。複数の欠陥レポートが登録された後でそれらが同じ根本原因に関連していることが判明した場合、通常、一つだけを維持し、他のレポートは重複としてクローズされます。

無効な欠陥レポートや重複した欠陥レポートは非効率的ですが、テストマネージャーはこれをある程度予期して受け入れています。無効や重複した欠陥レポートを全て排除しようとすると、テスト担当者は欠陥レポートを登録することを躊躇する可能性があり、結果として偽陰性の数が増えてしまいます。これは通常、テスト組織の主要な目標である欠陥検出の効率を低下させる結果につながります。

クロスファンクショナルチームによる欠陥管理プロセスとその役割

テスト組織とテストマネージャは通常、全体的な欠陥マネジメントプロセスと欠陥マネジメントツール（JIRA、バックログなど）を所有していますが、クロスファンクショナルチームは特定のプロジェクトで報告された欠陥の管理を担当することが一般的です。
テストマネージャに加えて、欠陥管理（または欠陥選別）委員会の参加者には、開発中のソフトウェアに利害関係を持つ開発者、プロジェクトマネージャ（PjM）、プロダクトマネージャ（PdM）、およびその他のステークホルダが通常含まれます。不正を発見し、欠陥管理ツールに登録した後、欠陥管理委員会はミーティングを開催し、各欠陥レポートが有効な欠陥を示しているか、そして解決すべきか、延期すべきかを決定します。
この決定を行うため、委員会は欠陥を解決する場合や解決しない場合に生じるメリット、リスク、コストを検討します。欠陥を解決することに決定した場合、委員会は欠陥解決の活動の優先度を他のプロジェクトタスクに相対して設定します。テストマネージャとテストチームは、欠陥の相対的な重要性について質問された際に利用可能な客観的情報を提供します。優れたコミュニケーションを欠陥追跡ツールで置き換えることはできませんし、優れた欠陥追跡ツールが効果的に使用されている場合、委員会のミーティングを置き換えることもできません。
コミュニケーション、適切なツールのサポート、明確に定義された欠陥ライフサイクル、および欠陥管理委員会の積極的な関与は、効率的かつ効果的な欠陥管理に不可欠です。

テストプロセスにおける欠陥データ収集とその目的

静的テストで欠陥を発見した時や動的テストで故障を検出した際には、テスト担当者がデータを収集し欠陥レポートに記録します。このデータは以下の3つの目的を果たす必要があります。

欠陥ライフサイクル全体を通じたレポートの管理
プロジェクトステータスの評価、特に製品の品質とテスト進行状況
プロセス能力の評価

欠陥レポート管理とプロジェクトステータスに必要なデータは、欠陥がライフサイクルのどの段階で検出されたかによって異なりますが、プロジェクト早期に検出されるほど情報は少なくなります。しかし、収集される核となる情報はライフサイクルを通じて、一貫していなければならず、プロジェクト全体と複数のプロジェクトにわたるプロセス関連の欠陥データを比較できるようにします。

収集された欠陥データは下記に利用します。

テスト進行の監視
制御
終了基準の評価

例えば、欠陥情報は下記の分析に使います。

欠陥密度の分析
検出され解決された欠陥の傾向分析
欠陥検出から解決までの平均時間
MTBFの分析

収集された欠陥データには、下記が含まれます。

発見者
発見者の役割（エンドユーザー、ビジネスアナリスト、開発者など）
テストの種類（使用性テスト、性能テスト、回帰テストなど）
問題の概要
問題の詳細な説明
欠陥を再現する手順
実際と期待の結果の差異
可能であればスクリーンショットやログ
欠陥が発生、検出、修正されたライフサイクルフェーズとテストレベル
欠陥の原因となった成果物
システムおよびステークホルダーへの影響度
問題解決の優先度
欠陥が存在するサブシステムまたはコンポーネント
問題を検出したプロジェクト活動
問題を特定した方法
欠陥の種類
影響を受ける品質特性
欠陥を観察したテスト環境
所有者
レポートの現状
問題を観察した特定の成果物
問題解決のための行動結論、提案、承認
欠陥対応のリスク、コスト、機会、メリット
欠陥ライフサイクルの遷移日とそれに関わるアクション
解決方法の説明とテスト推奨事項
関連するリスク、要件、テストベースの要素など、その他の情報

これらの情報は、欠陥の検出から解決に至るまでの過程を追跡し、品質管理とプロジェクト進行状況を把握するために重要です。

テストマネージャが欠陥レポートを作成する際に収集するべき情報を決定するのに役立つ様々な標準やドキュメントが利用可能です。これには、ISO 25000、IEEE 829、IEEE 1044、直交欠陥分類法などが含まれます。

欠陥レポートの情報は下記が重要

簡潔
正確
客観的
適切
タイムリー

欠陥追跡の重要性とプロセス改善への影響

欠陥レポートはプロジェクトステータスのモニタリングと報告に利用可能です。アドバンスドレベルでのプロセスの状態に関するメトリクスについて、テストマネージャはテストプロセスとソフトウェア開発プロセスの能力を評価する上で欠陥レポートの意味を理解する必要があります。

テスト進捗のモニタリング情報に加え、欠陥情報はプロセス改善の取り組みをサポートするべきです。以下に例を挙げます。

各フェーズにおけるフェーズ内阻止の評価と、欠陥検出効率の向上策を提案するためにフェーズ情報を活用する。
最も多くの欠陥が混入するフェーズを特定し、パレート分析を通じて欠陥の総数を削減するための具体的な改善策を立てる。
欠陥の根本原因を特定し、プロセス改善を通じて欠陥の総数を減少させる。
品質コスト分析を実施し、欠陥によって発生するコストを最小化するためにフェーズ情報を利用する。
欠陥が集中しているコンポーネントを特定し、技術的リスクをより深く理解し、問題があるコンポーネントのリエンジニアリングを可能にするために欠陥コンポーネント情報を活用する。

チームがソフトウェア開発ライフサイクルで見つかった欠陥を追跡しないことがあります。この行動は、効率性を高めるためやプロセスのオーバーヘッドを減らす目的で行われがちですが、実際にはテストとソフトウェア開発のプロセス能力の可視性を著しく低下させます。信頼できるデータが不足すると、以前に提案されたような改善策を実施することが難しくなります。