ソフトウェアの不具合を追跡するには：開発プロセス再入門（8）（2/3 ページ）

[津田義史（豆蔵），＠IT]

不具合報告書のライフサイクル

　以下に、不具合報告書のライフサイクルを示します。これは不具合報告書の状態遷移をUMLの状態遷移図で表したものです。

不具合報告書の状態遷移

　この文書をインスタンス化する（不具合報告書を作成する）のは誰でも構いません。が、不具合報告書がどうあるべきかを理解していない人（プロのQAではない人）が記述した場合、その不具合報告書の品質に問題が出ることがあります。このため、プロジェクトによっては、不具合報告書を作成できる人をQAだけに制限することもあります。不具合報告書が最初に記述されたとき、その状態は［新規］になります。以下に、不具合報告書の状態と、各状態における担当者を列挙します。

・新規（New）

　担当者は開発マネージャ（もしくはQAマネージャ）です。QAが記述した不具合報告書の妥当性を検査し、この不具合にしかるべき開発者を割り当てます。この段階で、不具合報告書が［解決済み］に遷移したときの担当者（QA）を一緒に割り当てることもあります。

・開始（Open）

　 担当者は開発者です。このほか、この状態を指して［割り当て済み］（Assigned）などと呼ぶこともあります。不具合を解決する方法はいくつかあります。開発者は、複数の処理方法の中から1つを選択し、実際にその不具合に対するアクションを実施したうえで、不具合報告書の状態を［解決済み］とします。ここで開発者が取れるアクション（処理方法）は、後で説明します。

　不具合報告書が［開始］された後で、アサインされた開発者が、この担当者として不適格であることが判明することもあります。この場合には、最初にアサインされた開発者もしくは開発マネージャにより、違う開発者が担当者としてリアサインされます。これは最初の担当者が能力的に不適格であったというわけではなく（まれにそういう場合もありますが）、不具合の原因であるサブシステムを読み違えたことによるものです。最初にアサインされた開発者は、不具合に関する調査結果を追記して、次の担当者にこの不具合報告書を受け渡します。あるいは、特定の開発者の負荷が重過ぎるので、負荷分散のために開発者をアサインし直すことあります。また、不具合報告書を再開して、この状態にまで差し戻したときも、担当者をアサインし直すことがあります。

・解決済み（Resolved）

　担当者はQAです。特にQAをアサインしない場合、この不具合を報告した人がこの不具合のQAも担当することに決めておくとよいでしょう。というのは、この不具合を報告した人が、最も適切にこの不具合が解決されたかどうか判断することができると期待できるからです（不具合を発見した人と、その不具合の報告書を記述する人が異なる場合もあるでしょうが）。［解決済み］の状態を指して、［保留］（Pending）ということもあります。

　担当者は、開発者が選択した処理方法に同意できるか判断・検証し、問題なければ不具合報告書の状態を［確認済み］にします。例えば、開発者が「修正済み」という形で不具合を解決していれば、その修正が反映される（と報告された）ビルドがリリースされた後に、正しく修正されているかどうかをそのビルドでテストして確認し、この不具合報告書の状態を［確認済み］とします。開発者が選択した不具合の処理方法にQAが同意できなければ、不具合報告書の状態を［開始］に差し戻します。

・確認済み（Verified）

　担当者はQAマネージャ（もしくはプロジェクトリーダ）です。「修正済み」という形で解決されているものは特に問題になりません。担当者は、一応内容を確認したうえで、これを［終了］という状態にします。「不具合ではない」「修正する予定はない」といった形で［確認済み］になっている不具合は、担当者は本当にそれで問題ないか吟味したうえで、［終了］という状態にします。このとき、担当者が処理方法に問題があると判断すれば、その理由を不具合報告書に追記したうえで、これを［開始］の状態にまで差し戻すことができます。

・終了（Closed）

　担当者はいません。これで最後です。ソフトウェアの開発を終えるときには、どんな形であれ、すべての不具合報告書の状態を［終了］にしなければいけません。

　ただし、［終了］となった不具合報告書でも、テストケースとして価値のあるものですから破棄してはいけません。例えば、［終了］となった不具合報告書でも、その再現手順はリグレッションテストのインプットとして利用されます。また、ユーザーから不具合の報告を受けたときに、［終了］となっている不具合報告書の中から、同件と思われる不具合を見つけることもあります。そのユーザーが古いバージョンのソフトウェアを使っていたら、この問題がどのバージョンで修正されているかをユーザーに知らせることもできます。不具合報告書は、ユーザーサポートの際にナレッジベースとして活用できます。

　同件と思われる不具合がすでに報告されており、この不具合報告書が「修正済み」という形で解決・確認されていて、ユーザーが使っていたのが最新のビルドであれば、以前修正したはずの不具合が再発したことになります。このデグレードを修正するための重要な情報が、その不具合報告書に記述されているかもしれません。このときも、不具合報告書を再開して［開始］の状態にまで差し戻します。

　つまり、［終了］という状態は、プロジェクトリーダによる確認が済んだということを示す便宜的な状態であって、その不具合を未来永劫追放することができたという意味ではありません。開発作業が継続されているオープンなソフトウェアの場合には、不具合報告書を［終了］にするタイミングがないので、［終了］という状態が運用されないこともあります。