オープンソースのバグトラッキング・ツール「BugTracker.NET」を使う：連載：VBで実践！ 外部コンポーネント活用術（1/3 ページ）

バグの報告と修正状況を管理するASP.NETで作られたお手軽バグトラッキング・ツールを紹介。バグ管理していますか？

[岸本真二郎，デジタルアドバンテージ]

powered by Insider.NET

連載目次

バグ管理していますか？

　バグトラッキング・ツールとは、バグの発生、開発担当者へのバグの通知とアサイン、バグの修正、修正の確認など、ソフトウェアのバグに関する一連の作業を記録／管理するためのツールです。ソフトウェアの開発工程では、テストの段階でバグの報告が行われ、指摘された内容の修正を行い再度テストする、といった作業を繰り返しますが、それらの作業をスムーズに行えるようにすることがバグトラッキング・ツールの目的といえるでしょう。

　今回は、連載タイトルの「外部コンポーネント活用術」からちょっと脱線してしまいますが、オープンソースとして配布されているバグトラッキング・ツールである「BugTracker.NET」を紹介します。

　ツールを利用した作業の基本的な流れとしては、テスター（もしくはアプリケーションのユーザー）がバグを発見、報告し、対応に割り当てられた開発者がそれを修正するとともに、ツールに状況を記録していきます。典型的なバグトラッキングのシナリオは次のようになります。

1. バグの報告（テスター／ユーザー／開発者自身などから）
2. 修正担当者の割り当て
3. 修正作業
4. 修正内容のチェック（正しく修正されているかチェック）
5. 完了（クローズ）（修正されていなければ3に戻る）

　次の画面はBugTracker.NETの実行画面です。WebアプリケーションとしてASP.NETで実装されています。

バグ情報（desc列のリンク）をクリック

画面1 BugTracker.NETのバグ情報一覧ページ（上）とバグ情報の詳細ページ（下）
バグ情報の詳細ページでは、コメントとして入力された内容がページ下部に新しい順に表示されていく。

　こういったツールを利用してバグの報告と修正の記録が行えるようになると、開発担当者はバグに関する情報収集を楽に行え、自分に割り当てられた作業の確認や、修正後の進ちょく状況（修正内容が再テストでパスしたかなど）の把握が容易になります。

　また、開発をマネジメントする側から見ると、アプリケーションのバグ発生率や、特定の開発者やモジュールにバグの発生が偏っていないか、特定の障害によってスケジュールに影響が出ていないかなどをチェックするのに役立ち、プロジェクトを見通しよくすることができます。

BugTracker.NETは「軽い」バグトラッキング・ツール

　Visual StudioのユーザーならTeam Foundation Serverという選択肢もありますが、本稿で紹介するBugTracker.NETは大規模なアプリケーション構築のための重厚なツールというよりむしろ、バグの報告と修正状況の管理に特化した非常に軽いツールです。

　また、オープンソースのWebベースのツールでは、PerlやPHPなどで記述され、データベースにはMySQLが前提……といったものが多いのですが、このBugTracker.NETは、ASP.NETによるWebアプリケーションで（ロジックの記述はC#）、バックエンドのデータベースにはSQL Server（Express Editionも利用可能）を使用しています。このため、マイクロソフト・テクノロジに精通したプログラマーにとっては動作環境に特に前知識を必要とせず、インストールや運用がとても楽に行えます。

　残念ながら日本語対応はされていないので、ドキュメントやブラウザで表示される内容が英語になってしまいますが、列見出しの「タイトル」が「Title」と表示される程度なので、ほとんど問題にならないでしょう。

　BugTracker.NETでは主に以下の内容を記録することでバグ管理を行います（設定により項目を追加することも可能です）。

管理項目	用途
タイトル	バグの名称
重要度	バグの深刻度（高、中、低）
担当者	担当者の割り当て
ステータス	バグ対応の進ちょく状況。未割り当て、進行中、チェックイン、クローズ（完了）など
内容	発生状況、再現手順などを詳細に記述
表1 BugTracker.NETで管理するバグ情報の主な項目

　これらの項目の中で特に重要なのが「ステータス」です。これは上述したバグ管理のシナリオの進ちょく状況を表します。

　バグを発見したテスターは新規にバグ情報を登録します（可能であれば担当者を指定します）。このときのステータスは「新規（new）」です。BugTracker.NETではバグ情報を登録／修正すると、関係者（メンバー）にメールが送信されます（設定により変更できます）。

　担当者は、指摘されたバグ情報を確認してバグ修正を開始します。作業の開始とともにステータスを「進行中（in progress）」に変更します。バグ修正が終わったら、担当者はステータスを「チェックイン（checked in）」にして、修正が完了したことをメンバーに伝えます。

　そうするとテスターはバグの再現チェックを行い、正しく修正されていればこのバグ情報を「クローズ（closed）」します。以上でこのバグに関するシナリオは終了です。

　もしも修正後のテストで再度不具合が発生した場合は、ステータスが「再オープン（re-opened）」となり、担当者がもう一度修正作業を行うことになります。それ以降は「クローズ（closed）」するまで同じ作業の繰り返しとなります。