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

» 2004年12月01日 12時00分 公開
[津田義史(豆蔵),@IT]
前のページへ 1|2|3       

処理方法(Resolution)

  不具合報告書の状態が[開始]から[解決済み]に遷移するときに、開発者が取れるアクションのことを処理方法(もしくは対処方法)といいます。よく使われる処理方法について、以下に紹介しておきます。これらは、先に紹介した[状態]とはまったく別のものなので注意してください。開発するソフトウェアのドメインによっては、ここに紹介した以外の対処方法も用意しておくとよいでしょう。

・修正済み(fixed)

 不具合の報告者が、最も期待する処理方法です。このとき、開発者は修正が反映されるビルドの番号や、どのソースコードを修正したかなどを不具合報告書に追記します。また、より簡単な再現方法があれば、それも追記します。QAは、意図したとおりに修正されていることを当該のビルドで確認しなければなりません。

・再現しない(works for me)

 不具合が再現しない場合、開発者は「再現しない」という形で不具合報告書を[解決済み]にします。もちろん、QAがこれに同意できない場合には、再現のために必要な情報(より詳細な再現手順など)を追記して、不具合報告書を開発者に差し戻します。

・重複(duplicate)

 同件ということもあります。同じ内容の不具合がすでにほかの不具合報告書にて報告されている場合には、開発者は先に書かれた不具合報告書のID番号だけを重複した不具合報告書に追記し、「報告の重複」として[解決済み]にします。それ以上の情報は記入せず、続きはすべて先に書かれた不具合報告書で行うべきです。もちろん、QAがこれに同意できなければ(「重複した報告」ではないと考えられれば)、その理由を追記して開発者に差し戻します。

・不具合ではない(not a bug)

 その動作が不具合ではなく、仕様どおりであると開発者が考える場合には、ソースコードに手を入れることなく、このような形で不具合報告書を[解決済み]とします。そのときは、必ずそのよりどころとなる仕様書などへのリンクを不具合報告書に追記してください。

・制限事項(limitation)

 ソフトウェアによる制限と、ハードウェアによる制限があります。最終ビルドでも、この不具合が制限事項として残る場合には、「制限事項」という形で[解決済み]とします。開発中だから制限事項であって、そのうち制限解除するという場合には、このような形で[解決済み]としてはいけません。制限解除できたビルドにて、「修正済み」という形で[解決済み]とします。

・第三者のソフトウェアの不具合(third party software bug)

 購入したライブラリやコンポーネント、データベース製品などに不具合がある場合です。当該のソースコードがない場合には、開発者は手の出しようがありません。第三者(ライブラリやコンポーネントのベンダ)に、不具合をレポートして、修正を依頼しなければなりません。この場合、第三者からの返答が来るまで[解決済み]にするのを待つことがあります。

・間接的に修正(indirectly fixed)

 実装が追加されたり、ほかの不具合の修正などにより、(いつの間にか)間接的に修正されて再現しなくなった場合です。以前のビルドでは再現するが、最新のビルドではなぜだか再現しない場合にこの処理方法を選択します。本当に修正されたのか、どの部分のソースコードの修正により解決されたのかが不明なため、この処理方法はなるべく選択したくないところです。

・このバージョンでは修正しない(defer)

 次のメジャーバージョンを開発するときには修正するが、現在開発中のバージョンでは諸般の事情により修正しません。これにより[解決済み]とされて、QAの承認を得ていったんクローズされた不具合報告書は、次のバージョンの開発が始まったときに再開(reopen)されなければなりません。同じ製品の次のバージョンの開発を間近に控えているようなときは、その不具合報告書の状態を再開する(差し戻す)工数を削減するため、この処理方法により[確認済み]とされた不具合報告書についてはクローズしないこともあります。

・修正しない(won't fix)

 それが不具合であることは開発者も認識しているが、不具合の深刻度に対して修正のコストが見合わない場合には、このような形で[解決済み]とします。QAが同意できるように、修正しない理由を追記しなければなりません。エンドユーザーも納得できるような理由がなければ、QAも「修正しない」という解決に同意することはできません。

・お蔵入り(obsolete)

 UIやアーキテクチャが大きく変更されたことにより、再現手順のとおりに操作できなくなったなど、報告された不具合が古い内容となり、再現手順に意味がなくなった場合はこのような形で[解決済み]とします。これにQAが同意した場合には、その不具合報告書の再現手順はテストケースとしても利用されません。つまり、リグレッションテストのインプットとしては使われなくなります。

・情報不足(need more information)

 不具合を再現するための情報が不足している場合には、開発者はいったんこのような形で不具合報告書を[解決済み]とすることがあります。QAは、この不具合報告書の状態をそのまま[確認済み]にしても構いませんし、より詳細な再現手順を追記して開発者に差し戻しても構いません。

 このほか、ソフトウェアのドメインによっては、ここに挙げた以外の不具合の解決方法があるでしょう。必要なものを足して、不要なものを削り、皆さんのドメインに最適の処理方法のセットを作成してください。

よくある間違い

 不具合報告書の管理と運用は、知らない人には結構難しいものらしく、間違ったやり方をよく見ることがあります。筆者がよく見かける間違いを以下に紹介しましょう。

・状態と処理を一緒くたにしている

 筆者が最も多く目にする間違いは、不具合の状態と処理方法とを混同してしまうことです。例えば、不具合報告書の取り得る状態として[修正済み]や[再現しない]を用意してしまうと、現在その不具合がどのような状態にあるのか、分からなくなってしまいます。開発のフェイズが進むにつれ、開発者が選択できる不具合の処理方法は増やしても構いません。しかし、不具合が取り得る状態を無節操に増やしてしまうと、各不具合の状態を正しく追跡できなくなってしまいます。先に示した不具合報告書の状態遷移図をよく眺めてみてください。不具合報告書が取り得る状態はそう多くありません。もちろん、開発するソフトウェアのドメインによっては不具合報告書が取り得る状態の種類をカスタマイズする必要もありますが、状態と処理方法は明確に区別されるべきです。

・不具合報告書の妥当性を検査するプロセスがない

 不具合報告書を記述できる権限が複数人に与えられている場合、相矛盾する内容の不具合が報告されてしまうことがあります。このため、不具合報告書が記述されたら、まずその妥当性を検査してコミットし、開発者の解決作業にゴーサインを出すプロセスが必要です。不適切な報告書に基づき、開発者が作業しても仕方がありませんね。このようなモデルをV&V(Validation & Verification)ということがあります。Validation(妥当性検査)とは、「正しいソフトウェアを作っているか」、Verification(確認)とは「正しくソフトウェアを作っているか」ということです。先に示した不具合報告書の[Open]という状態は、[Validated]と呼ぶべきかもしれません。この問題に対するもっとも簡単な解決は、不具合をオープンできる権限を少人数に絞ることです。複数人が不具合を報告してもよいが、それらをオープンできるのはQAマネージャだけ、といった形にします。

・不具合報告書の解決を確認するプロセスがない

 前述したValidationのプロセスがないという問題に対して、こちらはVerificationのプロセスがないという問題です。つまり、不具合の状態が[解決済み]から[確認済み]に遷移しないということです。開発者により解決されたと報告された不具合は、本当に解決したのか、QAが確認しなくてはいけません。このプロセスが欠けていると、不具合の数はいつまでたっても収束しません。不具合の解決と確認は、開発者とQAの二人三脚で行われるべきです。

 次回は、不具合報告書に記述すべきほかの項目について説明します。お楽しみに。

この記事に対するご意見をお寄せください

managemail@atmarkit.co.jp


著者紹介

▼津田義史

 5年間、某外資系ソフトウェアベンダでパッケージ製品の開発とグローバリゼーションに従事。その後、オブジェクト指向技術に疑問を感じ、2000年に豆蔵に入社。現在は、コンサルティングを通して、間違った開発プロジェクトをみることが多く、改めてソフトウェアというものが難しい仕事であることを実感する毎日。興味の対象は、C++のテンプレートを使った静的な多態性の活用だが、最近はC++のコードを書く機会そのものが少ない。


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ