photo credit: harusday via photopin cc
はじめに
１０年以上前の記事だけど、バグ管理について書かれたとても良い記事を見つけました。
ぼくなりにJoel on Softwareの「やさしいバグトラッキング」を解釈してまとめてみました。
ソシム
売り上げランキング: 595,221
優れたバグ管理を行うための10のヒント
１．再現手順は最短の手順で書く
良いテスタは再現手順を最小限のステップに絞込む。これはバグを見つけなければならないプログラマにとても助けとなる。
複雑に見えるバグは再現手順が長くなりがちですが、実はもっと単純だったりします。Aをやって、Bをやって、Cすると現象が再現する。でも実はB→Cだけでも発生するかもしれません。
バグの再現手順が単純であれば、調査にかかる時間は短くなります。テストをする人はできるだけ最小の手順で再現させる方法を見つけ出すことが重要です。
２．バグフィックスの確認はバグを見つけた人が行う
バグレポートを完了できるのはそれを公開した人だけだというのを覚えておくこと。誰でもそれを解決はできるかもしれないが、見つけたバグがフィックスされたと本当に確認できるのは、それをはじめに見つけた人だけだ。
バグが検出されると、プログラマはバグを修正します。修正されたプログラムがきちんと動作するかは、バグを見つけた人が再度テストし直すというのが原則です。
他の人でも確認できないことはないですが、バグを見つけた人がOKを出してこそ、バグが修正されたと言えます。
３．修正だけが全てではない
バグを解決する方法はたくさんある。FogBUGZはバグを修正済み(fixed)、修正しない(won't fix)、延期(postponed)、再現せず(not repro)、重複したエントリ(duplicate)、仕様(by design)に分類できる。
検出されたバグはできる限り修正することが望ましいですが、"修正しない"という解もあることを覚えておきます。
バグを修正しない理由には以下のようなものがあります。
- 修正済み(fixed)：すでに直っている場合に使います。
- 修正しない(won't fix)：修正しない場合は、修正しないなりの理由を併記します。
- 延期(postponed)：緊急性が高くないバグは後回しにするということも検討します。
- 再現せず(not repro)：再現しないバグを深追いするか否かの判断が必要です。
- 重複したエントリ(duplicate)：別のバグ番号で起票されている場合に使います。
- 仕様(by design)：バグではなく、仕様であることの根拠を併記します。
４．安易な再現性なしは要注意
「再現せず」は誰もそのバグを再現できないことを意味する。バグレポートに再現手順がない場合にプログラマはしばしばこれを使う。
再現しないというのは、誰がやってもその事象が再現しないことです。
１度や２度操作してみて、再現しないからと言って、安易に片付けてしますのは危険です。発生するとしたら、どういう理由が考えられるかをまずは思考してみましょう。
再現手順が誤っていると再現しなくなってしまうバグもあるので、再現手順はきちんと書かれている必要があります。
５．再現したバージョンを管理する
あなたは注意深くバージョンを管理しておきたいと思うだろう。テスタに渡すソフトウェアのビルドにはそれぞれビルドIDをつけておくべきで、哀れなテスタがバグをフィックスしていないバージョンでバグのテストをするようなことがないようにする。
昨日はバグがあったけど、今日見たら直っていたということはよくあります。
発生した日付やビルドバージョンを管理しておくことで、どのバージョンにバグが含まれていたのかを特定しやすくなります。
デイリービルドしているプロジェクトであれば、発生日だけでもわかればソースコードのバージョン管理システムから資産を戻して再現環境を作り出すことができます。
