標準的なバグ票って?

ソフトウェアやシステム開発中に見つかった不具合を記録したものをバグ票と呼ぶ。バグ票の目的は大まかには2つに大別できる。1つは、解決されていないバグの把握と管理である。もう1つは、バグデータベースとして、後から参照することを目的としている。企業で使われているもの、オープンソースのもの等バグ票のバリエーションはかなり広い。

もっともシンプルに使われているところだと、管理の目的で、バグの症状、発見日、再現方法、対策中/解決済/保留などの状況、担当者、ID、解決日くらいがついているのではないだろうか。機能/部品名、モジュール/クラス・パッケージ名を記録して、不具合密度を求める際に利用しているところもある。

事後分析も視野に入っている場合には混入原因や本来見つけられるフェーズが入っていたりする。プロジェクト終了後や工程の区切り等に振り返って問題点や改善すべきところがないかを検討するためである。

バグデータベースのほうは、プロダクトラインや派生製品等、バージョンアップを繰り返すようなソフトウェアで、過去に類似のバグがないかどうかを調べるために使われる。テスト設計時やランダムテストの実施前等に使われることがある。

バグ管理票やバグ管理システムも千差万別で、これといってデファクトスタンダード的位置にあるツールはないようである。強いてあげるならば、MSエクセルのシートに記録する、というのが最も多いように思う。今月のThinkITでは「バグ管理の作法」というタイトルでバグ管理システムの実態調査をはじめとした特集をされている。（こちら バグ管理システムのアンケート結果はこちら）。その1つとして、エンピリカルソフトウェア工学の紹介（執筆は私の上司）もある。

ツールやバグ票の項目も千差万別であるが、バグ管理のプロセスも体制や組織により、相当多くのバリエーションがあり、かなりばらばらな印象を受けている。長くなりそうなので、こちらはまた別立てで書いてみたいと思う。