TA-6.4.1 （K4）特定の欠陥の分類情報を識別、収集、および記録する。
欠陥が識別された場合の一般的な分類情報
* 欠陥を検出した活動(レビュー、監査、インスペクション、コーディング、テスト)
* 欠陥が混入したプロジェクトフェーズ(要件、設計、詳細設計、コーディング)
* 欠陥を検出したプロジェクトフェーズ(要件、設計、詳細設計、コーディング、コードレビュー、ユニットテスト、統合テスト、システムテスト、受け入れテスト)
* 可能性のある原因(要件、設計、インターフェース、コード、データ)
* 再現性(1回のみ、不定、必ず再現)
* 現象(クラッシュ、ハングアップ、ユーザインターフェースエラー、システムエラー、性能)
欠陥を調査した後に分類できる詳細分類
* 根本原因(プロセス、コーディングエラー、ユーザエラー、テストエラー、構成の問題、データの問題、サードパーティ製ソフトウェア、外部ソフトウェアの問題、ドキュメントの問題)
* 発生元(要件、設計、詳細設計、アーキテクチャ、データベース設計、ユーザドキュメント、テストドキュメント)
* 欠陥のタイプ(ロジックの問題、演算の問題、タイミングの問題、データ処理の問題、拡張による問題)
欠陥の修正が完了または延期された場合、あるいは欠陥を確認できない場合の分類情報
* 解決(コード変更、ドキュメント変更、延期、問題なし、重複)
* 修正アクション(要件レビュー、コードレビュー、ユニットテスト、構成の文書化、データの準備、変更なし)
最終の分類
* 最終的な解決策(解決済み、検証済み、終了、問題なし、延期、対応中、未解決)
練習問題
国家の消防のための制御システムを構築するプロジェクトは厳格な期限を持つ政府契約で行われており、納期が遅れるとペナルティが発生します。
受け入れ基準には、ユーザー受け入れが終了した時点での未解決欠陥数について、重大度ごとの制限が含まれています。
このシステムには、他のどのシステムにもまだ導入されていない、システムの有効性にとって重要な革新的な設計に基づく洗練されたユーザーインターフェースを実装されています。
このプロジェクトでは、ウォーターフォールのライフサイクルを使用していますが、個々の要件の優先順位に基づいて段階的な実装を行います。
このプロジェクトでは開発中に欠陥分類システムを利用し、欠陥分類システムは3つまでの別々の分類を適用することができます。
次の欠陥分類のうちどれがプロジェクトのニーズを最もよく満たしますか。
A) 症状（システムのどの面が影響を受けているか）、優先順位による未解決の欠陥、欠陥の原因の疑い（要件、設計など）。
B) 優先順位が高い未解決の欠陥、欠陥が検出されたフェーズ、欠陥の疑いのある原因（要件、設計など）。
C) 重大度別の未解決の欠陥、欠陥が混入されたフェーズ（要件、設計など）、症状（システムのどの部分が影響を受けているか）。
D) 欠陥の検出につながったプロジェクトの活動（レビュー、検査など）、重大度別の欠陥の合計、ミスがあった作業成果物。
正解：C)
A)
症状：ユーザーインターフェースの欠陥を識別するのに役立つ
未解決の欠陥：優先度ではなく重要度が必要
欠陥の原因の疑い：プロセス改善に役立つ
B)
未解決の欠陥：優先度ではなく重要度が必要
欠陥が検出されたフェーズ：フェーズ内阻止においては混入されたフェーズよりも有用性が低い
欠陥の原因の疑い：プロセス改善に役立つ
C)
重大度別の未解決の欠陥：受け入れ基準に直接関係します
欠陥が混入されたフェーズ：プロジェクトのコストと時間を節約するためのフェーズ内阻止の基礎となります
症状：ユーザーインターフェースの欠陥を識別するのに役立つ
D)
欠陥の検出につながったプロジェクトの活動：プロセス改善には有用ですが、このプロジェクトには直接関係ありません
重要度別の欠陥の合計：未解決のものが必要です
ミスがあった作業成果物：プロセス改善には有用です
出典：Sample Exam - Question ISTQB Test Analyst Syllabus Advanced Level Version 1.2