第8回「ソフトウェアの不具合を追跡するには」では、不具合報告書のライフサイクルと状態、処理方法について説明しました。今回は、不具合報告書に記述すべき項目を紹介します。また、トリアージという考え方についても紹介します。
不具合報告書の書式に用意すべき項目には、次のようなものがあります。
これらの項目について、詳細に見ていきましょう。
ユニークなIDを記入する項目です。不具合(報告書)を一意に特定できるように、不具合報告書には通しの番号を付けます。同じ書式でたくさん書かれる文書には、どんなものであれ、通し番号を付けるべきです。メーリングリストやメールマガジンなどの文書には、よく通しの番号が振られていますね。それと同じことです。もっとも、一意に不具合報告書を特定できれば、このIDが必ずしも「通し」の番号である必要はありません。このIDの中に、製品名の略称や、不具合が発生したビルドの番号、報告者のイニシャルなどを含めるといった工夫をすることもできます。
このIDにより、不具合報告書はほかの不具合報告書(またはその他の文書)から参照できるようになります。例えば、不具合報告書が重複して書かれてしまったとき、開発者は最初の不具合報告書のID番号だけをその不具合報告書に追記し、「重複した(同件の)不具合」という形で解決済みとします。また、顧客から報告された不具合の場合には、当該の不具合報告書のID番号を顧客に伝えることで、顧客に安心してもらえます。きちんと不具合がハンドルされ、追跡されていることを示すからです。
不具合を、簡潔かつ具体的に説明する項目です。具体的な不具合の内容が想像できる内容にします。例えば、「不具合を見つけました」とか、「入力画面の不具合」といったものではいけません。もっと具体的な内容を記述してください。例えば、メールソフトなら「大きなファイルを添付できない」とか、施設予約システムなら「会議室の定員に小数を入力できてしまう」といった内容にします。
どんなことを書くべき項目かは、説明の必要はないでしょう。ただし、手間をかけずに報告書に記入できる工夫が、より必要となる項目です。数百〜数千もの不具合報告書に、同じこと(製品名)を手書き(手入力)するのは、多いなる工数の無駄遣いです。
状態と処理方法は、前回説明しています。不具合報告書のライフサイクルを管理する上で、特に重要な項目です。
不具合が認められるサブシステムの名前を記入する項目です。プロジェクトリーダーは、この情報を参考にして担当者をアサインします。開発するソフトウェアの規模が大きく、また報告される不具合の数が非常に多いとき、このような情報がないと適切な担当者を速やかにアサインすることが難しくなります。
この不具合を担当する担当者たちの名前を記入する項目です。不具合報告書は、その状態により、これを担当するチーム(ロール)が決まります。もちろん、具体的な担当者の名前を記入しておく必要があります。プロジェクトメンバーは、自分の名前が記入されている不具合報告書を追跡することで、これらを自身のタスクリストとして扱えます。文書の状態が変わるたびに、「担当者」という項目を書き直すのは良くありません。不具合報告書には、あらかじめ「開発担当」「QA担当」といった各担当者を記述する項目を用意しておき、不具合の状態とともに「現在の担当者」も遷移する、といった理解をすべきです。
(Reproduced Version/Build#)
QAが不具合報告書を新規に作成するとき、それを再現できた(発見した)ビルドの番号を記入する項目です。
(Resolved Version/Build#)
開発者が、不具合を解決する予定の、もしくは不具合を解決したビルドの番号を記入する項目です。この不具合報告書の状態を[解決済み]にするとき、必ずこの項目も記入してください。この番号のビルドがリリースされたら、QAはそのビルドをテストして意図したとおりに解決されているかを確認します。また、開発者は、この不具合を実際に解決する前に、解決する予定のビルド番号を先に記入しておいても構いません。これにより、解決の見通しを不具合の報告者に示せます。この項目は、不具合の状態が[開始]のときは不具合解決の計画を表し、[解決済み]のときは不具合解決の実績を表すわけです。どちらの場合でも、この項目に書かれた番号のビルドがリリースされたら、QAの作業が発生するということですから、この項目の意味が混乱することはありません。
このほか、この不具合の解決を確認したビルド番号や、この不具合をリグレッションしたビルド番号を記入する項目を用意することもあります。
不具合が再現した環境を記入する項目です。不具合が見つかったソフトウェアを動作させていたマシンのCPUやメモリ容量、OSのバージョンなどを記入します。このほか、ソフトウェアのドメインによって、この項目に記述する内容は変わってきます。例えば、Webアプリケーションであれば、ブラウザの種類とバージョンもこの項目に含まれるべきでしょう。不具合を再現するための非常に重要な情報となりますから、皆さんのドメインに応じて、この項目を過不足なく準備してください。
深刻度は、この不具合がどれだけ深刻なものかをユーザーの視点から示すもので、3〜5段階の数値がよく使われます。例えば、ユーザーの業務に支障が出たり、データを失う可能性がある不具合は深刻度が高く、単に見た目の不具合であれば深刻度は低くなります。Severityは重要度と訳されることもありますが、深刻度という方がより適切だと思います。不具合とは、ソフトウェアの「病気」もしくは「けが」のようなものなのだからです(深刻なけがのことを、重要なけがとはいいませんね)。もっとも、不具合報告書のテストケースとしての側面に注目すれば、深刻度を重要度と言い換えても差し支えないかもしれません。
優先度は、この不具合を解決する優先度を決める順位で、やはり3〜5段階の数字がよく使われます。開発者は、次にどの不具合の解決に着手すべきかを判断するために、優先度を使って不具合報告書を順序付けます。深刻度が高ければ、優先度も高くなるとは限りません。例えば、回避方法があれば優先度は低くなります。逆に、深刻度が低くても優先度は高くなる場合もあります。
これらの情報は、トリアージの際の重要なインプットとなります。トリアージについては後で説明します。
「いつも再現する」「ときどき再現する」などと記入する項目です。あらかじめいくつかの選択肢を用意しておくとよいでしょう。品質の高い不具合報告書には、必ず「いつも再現する」と書かれるべきです。「再現しない」と書かれた不具合報告書は価値が低いものです。そのまま開発者に「再現しない」という形で突き返されてしまう可能性もあります。また、「ときどき再現する」というのは、マルチスレッドを利用したソフトウェアなどでは実際にあるため、書かれるべきでないとはいい切れません。しかし、再現のための条件を絞り込めていないわけですから、やはり「いつも再現する」と記入された不具合報告書よりも相対的に品質が低いものです。
詳細な再現手順を記入する項目です。再現のための一番具体的な情報となるので、この項目も非常に重要です。再現するために必要かつ十分なだけの情報を簡潔に書くことが肝要です。不具合を再現できる最小のセットを作成することは不具合の原因を突き止めるうえで非常に重要なことです。この再現手順は、QAによりテストケースに転記されます。あるいは、不具合報告書の再現手順をそのままテストケースとして利用することもありますから、再現手順にはテストケースと同程度の品質を求めるべきです。
不具合の調査に必要な資料があれば添付します。再現時のログファイルや、再現手順を補足説明する画面ショット、再現のためのテストデータなどです。
この不具合を回避する運用方法があれば、記入します。この情報も、開発者が不具合の原因を突き止めるための材料となります。また、QAがテストする際のインプットにもなります。この回避方法を、最終ビルドのリリースノートに転記する形で、エンドユーザーに伝える必要が出るかもしれません。もし回避方法を発見したなら、忘れず記入してください。
時の担当者は、この不具合報告書の状態を遷移させるときに、その根拠を追記します。また、このときの日時も合わせて追記します。
Copyright © ITmedia, Inc. All Rights Reserved.