テスト計画・不具合やバグの管理には不具合やバグの状態の定義が重要
不具合やバグの対応状況を管理するには状態（ステータス）の定義が必要
ソフトのテスト計画書には、発見した不具合やバグの状態定義と終了判断を具体的に書いておく必要があります。テストで見つけた不具合やバグの対策は複数のチームや担当者の共同作業となるので、対策の進み具合を管理するには状態定義と終了の判断について、関係する人の意識を合わせておく必要があるからです。
ソフトのテストで見つけた不具合やバグは原因を調べて対策を進める事が最重要です。対策の進み具合を管理するためには、不具合やバグが、発見から対策完了までに辿る作業どのステップにあるのかを表す状態（ステータス）の定義が必要です。状態の定義を決めて、その状態に基づいて ①不具合やバグが今どの状態にあるのか、②今の時点では誰が何の作業を担当しているのか、が明確に判るような不具合やバグの管理の仕組みをテスト計画の時点で考えておく事が大切です。
前の記事では、不具合やバグの管理に必要になる以下の７項目のうち１から３の内容を紹介したので、この記事では４項と５項について紹介します。
- 不具合の分類（バグ、テスト設様間違い、テスト実施ミス、環境不備 など不具合をどう分類するのか）
- 不具合の記録（不具合の記録では不具合の再現方法と管理情報を漏れなく書く）
- 不具合の記録方法（何かのシステムに入力するのか EXCEL 表に書くのか）
- 状態定義（個々の不具合やバグはどんな状態を遷移して最終的に終了状態に行きつくのか）
- 終了判断（誰がどんな基準で不具合の対応が終了したと判断するのか）
- 優先度付け（不具合やバグの調査や対策の優先度は誰がどうやって決めるのか）
- トラッキング（個々の不具合の状態遷移は誰がどうやって監視して遅れの対策をするのか）
４．不具合やバグの状態の定義例（不具合やバグ状態遷移例）
不具合やバグの状態（ステータス）の定義にもいろいろあります、以下のような（1）から（9）までの状態を定義するのも一つの例です。この例では、ソフトの設計や実装に原因のあるソフトのバグに対するデバッグの作業手順を元に、状態（ステータス）を定義してあります。
この例では、ソフトのバグ以外の、テスト設計やテスト環境などテストチームに原因のある問題については、ソフトのバグに対する状態の定義を読み替えて利用する必要があります。しかし、開発規模規模が大きくてテスト設計やテスト環境に原因のる問題の数が多い場合には、別の定義を決めておくほうが管理し易くなる事もありますので、どのような定義を使うのが良いかは、プロジェクトによって変わってきます。
それでは、この例の各々の状態（ステータス）について、もう少し詳しく見ていきましょう。
(1) 未着手
テストで不具合やバグが発見され、その内容が不具合管理のシステムやEXCEL表に登録された時の初期の状態です。まだ再現を試行する担当者が割り振られていないので、この件についての調査作業は始まっていない状態です。
(2) 再現作業待ち
不具合やバグの再現を試行する担当が割り振られたのですが、その担当者が他の作業をしているので本件の再現作業がまだ始まってない状態です。
(3) 再現作業中
不具合やバグの再現担当者により、再現の作業が行われてるがまだ試行の結果が出ていない状態です。（再現のために複数回の試行が必要だったり、長時間の動作が必要だったりすると再現中の状態が長く続きます）
(4) 原因調査待ち
再現方法が判明して、不具合やバグの発生の仕組み（原因）を調査する担当のソフトエンジニアが割り振られたが、その担当者が他の作業をしているので本件の調査作業がまだ始まっていない状態です。
(5) 原因調査中
不具合やバグの調査担当者により、不具合の発生の仕組みや発生原因の調査が行われてるがまだ原因が解明されていない状態です。（簡単なバグなら数時間で原因が判る場合もありますが、難しいバグだと原因が判るまでに数日から数か月も時間が掛かる事もあります）
(6) コード修正中（デバッグ作業中）
不具合やバグの発生する仕組みや原因が判ったので、修正の方法を検討し、その内容に従ってソースコードを修正し、修正効果を確認する一連のデバッグ作業を実施中の状態です。（複雑で変更箇所の多いバグの場合には数日～数週間の期間が必要な場合もあります）
(7) 再テスト待ち
設計・実装チームで修正したソースコードをマスターツリーに反映する所まで終了すると、次の作業はテストチーム引き継がれます。修正が反映されたマスターツリーから生成された実行イメージのソフトがテストチームに渡されて、不具合やバグを検出したテスト項目が再度実行されて、不具合やバグが修正されているというテスト結果が出るのを待っている状態です。
(8) 個別対策終了
不具合やバグを検出したバージョンのソフトに対する不具合やバグの対応作業が終了した状態です。この後は、必要に応じて他のバージョン（より古い場バージョン）や、開発の元になったベースコードを使っている別製品のマスターツリーへの修正の展開の要否を検討する作業に移行します。
(8) 他のマスターツリーへの横展開中
他のバージョンや同じベースコードを採用している別製品のマスターツリーに対して、潜在不具合として今回の不具合やバグの情報を横展開し、そ情報を受領したとの回答を待っている状態です。横展開した情報を元に修正を行うかどうかは、他バージョンや別製品のプロジェクトで判断する事なので、この不具合やバグについての対応としては、情報が伝わった事を確認すればそこで終了とします。
(9) 全対策終了
他のバージョンや別製品への情報の横展開の確認も含めて、発見した不具合やバグの対応が全て終了した状態です。
５．終了判断（誰がどんな基準で対応が終了したと判断するのか）
不具合やバグの管理について計画する時には、不具合やバグの対策が終了した事か、誰がどんな基準で判断するのか具体的に決めて置く事が大切です。終了判断がしっかりと決まっていて適切に運用されていないと、対策中の状態（ステータス）の不具合やバグがどんどん増えていって、管理ができなくなってしまいます。
終了判断の基準や担当者は、開発プロジェクトによっていろいろですが、いくつか例をあげると以下のような物があります。
（１）不具合やバグを検出したソフトについて修正の効果確認が終われば終了とする
例えば、Ver 2.1 のソフトのテスト項目A1でソフトのバグB1を検出したとします。ソフトのバグなので、ソフトの設計や実装チームでソースコードの修正が行われ、その修正を反映したソフトに対してテスト項目A1のテストを行ってバグB1が検出されなければ、バグB1に対する対策は終了したと判断する、という考え方です。この場合には、テスト項目B1 のテスト担当者が終了判断を行う担当者になります。
（２）不具合やバグを検出したソフトについての修正確認のテスト結果レビューが終われば終了とする
上記の考え方では、テスト担当者が判断を間違うと終了判断を間違うリスクがあります。そこで、修正されたソフトに対するテスト項目A1に対するテスト結果をレビューして、テスト結果に問題が無い事をテストリーダが確認した時点で、バグB1に対する対策は終了したと判断する、という方法でリスクを減らすという方法です。この場合には、テスト項目B1のテスト結果をレビューするテストリーダが終了判断を行う担当者アになります。
（３）不具合やバグの他のマスターツリーへの展開が終われば終了とする
ソフトのバグが新規に開発・修正したソースコードではなく、以前からあるソースコードに含まれていた場合には、バグの影響範囲は今回の不具合やバグを見付けたバージョンのソフト以外にも広がります。同じ製品の古いバージョンのソフトや、別の製品だけどベースコードが同じ製品のソフト等にも、今回のバグが潜在している可能性があります。
それらの影響範囲のマスターツリーの管理責任者に対して、潜在バグの情報を伝え終わるまでを、不具合やバグの対応とする考え方もあります。この場合には、影響範囲下の設計・実装チームリーダに対する不具合やバグ情報の展開とその回答の受領になるので、設計・実装チームのリーダが終了判断の担当者になる場合が多いです。
不具合やバグの管理には優先順位付けとトラッキングも大切です
テストで発見した不具合やバグの情報の件数が増えてくると、優先度をつけて対策を進めつつ、対策の進み具合を確認するトラッキングも必要になます。優先度とトラッキングについては次の生地で紹介しましょう。