テストで見つかったバグを直しても、似たようなバグが繰り返し見つかることがあります。
そんなとき、「どんなバグが多いのか」「次から何に気をつければよいのか」を考えるために役立つのが、ODC分析です。
この記事では、以下の内容をわかりやすく解説します。
- ODC分析の意味と全体像
- バグを見つけたとき・直したときの記録項目
- バグのタイプとMissing・Incorrectなどの分類
- 記録した情報を改善に活かす方法
ODC分析とは？
ODC分析とは、バグを決まった項目で整理し、その傾向から、開発やテストの改善点を考える方法です。
ODCは「Orthogonal Defect Classification」の略で、日本語では「直交欠陥分類」と呼ばれます。IBMで開発された手法です。
例えば、「バグが20件あった」だけでは、何を改善すればよいのかわかりません。
でも、「20件のうち15件は、入力チェックの抜けだった」とわかれば、「次はチェックの抜けを重点的に確認しよう」と考えられます。
バグを数えるだけでなく、内容を整理して、次の改善につなげる。これがODC分析の目的です。
本記事では、IBMの公開資料で確認できたODCの資料に基づいて説明します。
まず、ODCの全体像を軽く見てみよう
ODCでは、主に2つのタイミングで情報を記録します。
| タイミング | 呼び方 | 記録する情報 |
| バグを見つけて報告するとき | Opener（オープナー） | 見つけた状況と、利用者への影響 |
| 調査・修正をして、直した内容がわかったとき | Closer（クローザー） | 修正内容と、その部分の開発・変更の経緯 |
まずは、バグを見つけたときに記録するOpenerの項目から見ていきましょう。
Openerの選択肢
Openerでは、バグを見つけたときの状況と利用者への影響を、次の3項目に分けて記録します。
| 項目 | 簡単にいうと |
| Activity | 何をしていて見つけたか |
| Trigger | どんな条件や着眼点で見つかったか |
| Impact | 利用者にどんな影響があるか |
では、各項目について、どのような情報を記録するのか、順番に見ていきましょう。
Activity：何をしていて見つけたか
Activityは、バグを見つけたときに行っていた作業です。
| 活動の例 | 意味 |
| Design Review | 設計内容を確認する |
| Code Inspection | プログラムの内容を確認する |
| Unit Test | プログラム内部の処理を踏まえてテストする |
| Function Test | 仕様に基づいて機能の動作を確認する |
| System Test | システム全体の動作を確認する |
Activityには、実際に行っていた作業を記録します。
例えば、会員登録画面に値を入力し、仕様どおりに動くかを確認している時に問題を見つけたなら、ActivityはFunction Testです。スケジュール上はテストの期間でも、コードを読んで問題を見つけたなら、ActivityはCode Inspectionです。
Trigger：どんな条件で見つかったか
Triggerは、バグが表れるために必要だった条件です。レビューでは、問題を見つけた着眼点を表します。
テストで使う分類の一部を、簡単に示すと次のようになります。
| 分類の例 | 見つかった条件 |
| Test Coverage | ある機能の基本的な動作を試した |
| Test Variation | 入力する値や条件を変えて試した |
| Test Sequencing | 単独では正常な機能を、特定の順番で実行した |
| Workload/Stress | システムの資源の限界付近で動作させた |
| Recovery/Exception | エラー後の復旧や例外への対応処理を動かした |
この表は代表例です。実際には、各Activityに対応するTriggerから選びます。
例えば、年齢に20だけでなく、0、120、−1などを入力して問題を見つけたなら、TriggerはTest Variationです。
なお、Triggerは発見条件です。「なぜチェックが抜けたのか」といった、バグを作り込んだ根本原因とは別に考えます。
Impact：利用者にどんな影響があるか
Impactは、バグによる利用者への影響の種類です。主な例を見てみましょう。
| 分類の例 | 影響の内容 |
| Capability | 必要な機能を果たせない。ほかの影響分類に当てはまらない場合に検討する |
| Performance | 動作が遅いなど、処理速度に影響する |
| Integrity/Security | システムやデータが、意図しない、または悪意ある破壊・変更・情報漏えいから守られることに影響する |
| Reliability | システムが停止するなど、継続して正常に動くことに影響する |
| Usability | 利用者にとって、理解や操作がしにくい |
開発中に見つけたバグなら、「そのまま公開していたら、利用者にどんな影響があったか」を考えます。
Closerの選択肢
Closerでは、バグを調査・修正した後にわかったことを記録します。何をどう直したかと、問題のある部分の開発・変更の経緯を、次の5項目に分けて整理します。
| 項目 | 簡単にいうと |
| Target | 何を直したか |
| Defect Type | どんな種類の修正をしたか |
| Qualifier | 抜けていたのか、間違っていたのか、不要だったのか |
| Age | 問題のある部分の、今回の開発・変更との関係 |
| Source | 問題のある部分の、開発上の出所 |
では、各項目について、どのような情報を記録するのか、順番に見ていきましょう。
Target：何を直したか
Targetは、修正した対象です。例えば、次のような区分があります。
| 区分 | 直した対象 |
| Requirements | 要件を記した文書 |
| Design | 設計書 |
| Code | プログラム |
| Build/Package | アプリを作成・配布する仕組みや配布物 |
| Information Development | 利用者向けのマニュアルやヘルプなど |
| National Language Support | 日本語など、各言語への対応部分 |
先ほどの年齢チェックをプログラムに追加したなら、TargetはCodeです。
Defect Type：どんな種類の修正をしたか
Defect Typeは、修正の種類です
設計・プログラム向けには、次の7タイプがあります。
| タイプ | 簡単な意味 |
| Assignment/Initialization | 値の代入や、最初に設定する値の修正 |
| Checking | 入力値や条件を確認する処理の修正 |
| Algorithm/Method | 正式な設計変更を必要としない、計算方法や処理手順の修正 |
| Function/Class/Object | 機能やデータ構造など、正式な設計変更を必要とする修正 |
| Timing/Serialization | 同じデータなどを扱う処理の、順序や同時実行の制御の修正 |
| Interface/O-O Messages | 処理や部品の間で、情報を渡す方法の修正 |
| Relationship | データやプログラムの部品同士の関連付けの修正 |
例えば、年齢が正しい範囲に入っているかを確認する処理を追加したなら、Defect TypeはCheckingです。
取り決めと違う形式で、ある処理から別の処理へ情報を渡していたなら、Defect TypeはInterface/O-O Messagesです。
「会員登録機能にバグがあったからFunction」と、起きた場所や症状だけで決めるわけではありません。実際に直した内容を確認して選びます。
Qualifier：抜けていたのか、間違っていたのか
Qualifierは、問題の性質です。次の3つに分かれます。
| 分類 | 意味 |
| Missing | 必要なものがなかった |
| Incorrect | 存在するものが間違っていた |
| Extraneous | 不要なものがあった |
タイプがCheckingでも、「チェックがなかった」のか、「あったけれど条件が間違っていた」のかは違います。
そこで、タイプとQualifierを組み合わせます。
| 組み合わせ | 年齢チェックで考えた例 |
| Checking × Missing | 年齢を確認する処理がなかった |
| Checking × Incorrect | 年齢を確認する条件が間違っていた |
| Checking × Extraneous | 不要なチェックがあり、入力してよい年齢まで拒否していた |
Defect Typeで「何の修正か」を、Qualifierで「抜け・誤り・不要なもののどれか」を記録します。
Age：今回の開発や変更と、どう関係するか
Ageは、問題のある部分が、今回の開発や変更とどう関係するかを整理する項目です。
| 分類 | 意味 |
| Base | 今回変更していない既存部分にあったバグ。標準の再利用ライブラリは除く |
| New | 今回、新しい機能として開発した部分のバグ |
| Rewritten | 既存機能の設計を見直したり、書き直したりして入り込んだバグ |
| ReFixed | 以前のバグを直したことで入り込んだバグ |
例えば、今回新しく作った会員登録機能に問題があったなら、Newです。「何日前に発生したか」を記録する項目ではありません。
Source：問題のある部分は、どこから来たものか
Sourceでは、その部分の開発上の出所を記録します。
| 分類 | 意味 |
| Developed In-House | 自社のチームで開発した部分 |
| Reused From Library | ライブラリから再利用した部分 |
| Outsourced | 外部の会社から提供された部分 |
| Ported | 別の環境で使っていたものを移した部分 |
ライブラリとは、ほかのプログラムから利用できる、ひとまとまりの処理や機能です。
自社で作った会員登録機能のバグなら、Developed In-Houseを検討します。「誰がミスしたか」を記録する項目ではありません。
ODC分析のやり方
ここまで紹介した項目を、会員登録の例に当てはめてみます。
年齢のルールは「0〜120の整数」です。この機能を、自社のチームで新しく作ったとします。
バグを見つけたとき（Opener）
テスト担当者が20、0、120、−1などを入力したところ、−1でも登録できました。この時点で、Openerの情報を記録します。
| 項目 | 記録例 |
| Activity | Function Test：会員登録の動作を、仕様に基づいてテストした |
| Trigger | Test Variation：入力する値を変えて問題を見つけた |
| Impact | Integrity/Security：正しくない年齢が保存され、データの正しさが損なわれる |
Impactは、この例では「データの正しさが損なわれる」という影響を前提にしています。実際には、利用者への影響を確認して分類します。
この時点では、「なぜ−1を登録できるのか」は、まだわかっていない場合があります。報告には、再現手順や、期待する結果・実際の結果も残します。
バグを直したとき（Closer）
開発者が調べたところ、年齢の範囲を確認する処理がありませんでした。そこで、範囲外の値は登録できないようにしました。
修正内容がわかったため、Closerの情報を記録できます。
| 項目 | 記録例 |
| Target | Code：プログラムを直した |
| Defect Type | Checking：入力チェックを追加した |
| Qualifier | Missing：必要なチェックがなかった |
| Age | New：今回、新しく開発した機能だった |
| Source | Developed In-House：自社のチームで開発した部分だった |
見つけた状況をOpenerに、調べて直した内容をCloserに記録するという流れです。
記録した情報を、どう改善に使う？
バグを分類したら、複数の記録を集め、どのような問題が多いかを調べます。
例えば、入力チェックに関する20件のバグが、次のように分かれていたとします（これは説明用の架空の例です）。
| 分類 | 件数 |
| Checking × Missing：チェックがなかった | 15件 |
| Checking × Incorrect：チェック条件が間違っていた | 5件 |
チェックの抜けが多ければ、次のような対策を検討できます。
- 設計時に、入力してよい値の範囲を明記する
- プログラムを確認するときに、必要なチェックがあるか確認する
- テストで、空欄や範囲外の値も試す
さらにTriggerを調べると、こうしたバグがどのようなテスト条件で見つかっているかも確認できます。
何を直したかと、どう見つけたかを組み合わせて、開発とテストの両方を見直します。
ただし、集計だけで原因は断定できません。「なぜチェックが抜けたのか」を、設計書やプログラム、レビューの内容から確かめます。
ODC分析のメリットと注意点
ODC分析のメリットと注意点を以下に示します。
メリット
- 改善するポイントを考えやすい：
- どんな問題が多いかを整理できる
- 開発者とテスト担当者が話し合いやすい：
- 修正内容と発見条件を、共通の項目で確認できる
- 対策後の変化を調べられる：
- 似たバグが減っているかを確認できる
注意点
- 記録や分類には手間がかかる：
- 調査や修正でわかったことを正しく残す必要がある
- 人によって分類が違うと比較しにくい：
- 判断に迷う例は、チームで確認する必要がある
- バグが少ないだけでは品質を判断できない：
- テスト不足で、見つかっていない可能性もある
分類は改善の手がかりです。記録するだけで終わらず、調査・対策・効果確認まで進めることが大切です。
本記事のまとめ
この記事では「ODC分析」について、以下の内容を説明しました。
- ODC分析は、バグを分類し、開発やテストの改善に活かす方法です。
- Openerでは、発見時の作業・発見条件・利用者への影響を記録します。
- Closerでは、修正対象・修正の種類・問題の性質・開発や変更の経緯を記録します。
- タイプは修正の種類、Missing・Incorrect・Extraneousは問題の性質を表します。
- 分類した情報を集め、実際の原因を調べて、対策と効果確認につなげます。
お読みいただきありがとうございました。