追跡システムまたは欠陥追跡システムは、ソフトウェア開発プロジェクトで報告されたソフトウェアのバグを追跡するソフトウェア アプリケーションです。これは、問題追跡システムの一種と見なすことができます。
多くのバグ追跡システム、例えばオープンソースソフトウェアプロジェクトの多くで使用されているシステムでは、エンドユーザーがバグレポートを直接入力することができます。[1]他のシステムは、ソフトウェア開発を行っている会社や組織の内部でのみ使用されます。通常、バグ追跡システムは他のプロジェクト管理ソフトウェアと統合されています。
バグ追跡システムは通常、プロフェッショナルなソフトウェア開発インフラストラクチャの必須コンポーネントであり、バグまたは問題追跡システムを一貫して使用することは、「優れたソフトウェアチームの特徴」の1つと見なされています。[2]
制作
バグ追跡システムの主要な構成要素は、既知のバグに関する事実を記録するデータベースです。事実には、バグが報告された時間、その重大度、誤ったプログラムの動作、バグを再現する方法の詳細、バグを報告した人の身元、バグの修正に取り組んでいるプログラマーの身元などが含まれます。[3]
一般的なバグ追跡システムは、バグに割り当てられたステータスを通じて追跡されるバグのライフ サイクルの概念をサポートしています。バグ追跡システムでは、管理者がステータスに基づいて権限を設定したり、バグを別のステータスに移動したり、バグを削除したりできるようにする必要があります。また、システムでは、管理者がバグのステータスを設定したり、特定のステータスのバグを移動できる範囲を設定したりできるようにする必要があります。一部のシステムでは、新しいレコードが追加されたり、ステータスが変更されたりすると、送信者や割り当てられたプログラマーなどの関係者に電子メールが送信されます。
使用法
バグ追跡システムの主な利点は、開発要求 (バグと改善の両方を含む。境界はあいまいな場合が多い) とその状態について、明確な一元的な概要を提供できることです。保留中の項目 (バックログと呼ばれることが多い) の優先順位リストは、製品のロードマップ、または単に「次のリリース」を定義するときに貴重な情報を提供します。
企業環境では、バグ追跡システムを使用して、バグを修正するプログラマーの生産性に関するレポートを生成することができます。ただし、バグによって重大度や複雑さのレベルが異なるため、不正確な結果が生成される場合があります。バグの重大度は、バグを修正する複雑さに直接関係しない場合があります。管理者とアーキテクトの間で意見が異なる場合もあります。
ローカルバグ トラッカー (LBT)は通常、アプリケーション サポート プロフェッショナルのチーム (多くの場合、ヘルプ デスク) がソフトウェア開発者に伝えられた問題を追跡するために使用するコンピュータ プログラムです。LBT を使用すると、サポート プロフェッショナルは「開発者の言語」ではなく「自分の言語」でバグを追跡できます。さらに、LBT を使用すると、サポート プロフェッショナルのチームは、苦情を訴えたユーザーに関する特定の情報を追跡できます。この情報は、実際の開発キューで必ずしも必要ではありません。したがって、LBT が配置されている場合は、2 つの追跡システムが存在します。
統合プロジェクト管理システムの一部
バグおよび問題追跡システムは、統合プロジェクト管理システムの一部として実装されることがよくあります。このアプローチにより、一般的な製品開発プロセスにバグ追跡と修正を組み込むことができ、複数の製品バージョンでバグを修正し、製品のナレッジ ベースとリリース ノートを自動的に生成することができます。
分散バグ追跡
一部のバグトラッカーは、分散型リビジョン管理ソフトウェアで使用するように設計されています。これらの分散型バグトラッカーを使用すると、開発者がオフラインのときにバグレポートを簡単に読んだり、データベースに追加したり、更新したりできます。[4] FossilとVeracityはどちらも分散型バグトラッカーを備えています。
最近では、商用のバグ追跡システムも分散バージョン管理と統合され始めています。 たとえば、 FogBugzはソース管理ツールKilnを介してこの機能を有効にします。[5]
ウィキとバグ追跡システムは従来、異なる種類のソフトウェアと見なされてきましたが、 ikiwiki は分散型バグ追跡システムとしても使用できます。統合された分散方式で、ドキュメントとコードも管理できます。ただし、クエリ機能はBugzillaなどの他の非分散型バグ追跡システムほど高度でもユーザーフレンドリーでもありません。[6] org-modeについても同様のことが言えますが、これは厳密にはウィキソフトウェアではありません。
バグ追跡とテスト管理
HP Quality Centerや IBM Rational Quality Managerなどの従来のテスト管理ツールには独自のバグ追跡システムが付属していますが、他のツールは一般的なバグ追跡システムと統合されています。 [引用が必要]
参照
- アプリケーションライフサイクル管理
- 問題追跡システムの比較- バグ追跡システムを含む
- プロジェクト管理ソフトウェアの比較- バグ追跡システムを含む
参考文献
- ^ Bogomil Shopov (2014 年 9 月 8 日). 「クライアント側のバグ報告を実装する」。2014 年 11 月 13 日時点のオリジナルよりアーカイブ。2014年11 月 17 日閲覧。
- ^ Joel Spolsky (2000 年 11 月 8 日). 「Painless Bug Tracking」 . 2010 年10 月 29 日閲覧。
- ^ Kaner, Cem (2000 年 7 月). 「Bug Advocacy」(PDF) . kaner.com . pp. 81, 98 . 2021 年 5 月 19 日閲覧。
- ^ Jonathan Corbet (2008 年 5 月 14 日). 「分散バグ追跡」. LWN.net . 2009 年1 月 7 日閲覧。
- ^ 「FogBugz の機能」。Fogbugz.com。2013年7 月 5 日時点のオリジナルよりアーカイブ。2010 年 10 月 29 日閲覧。
- ^ Joey Hess (2007年4月6日). 「Ikiwiki による統合された問題追跡」. NetworkWorld.com . IDG . 2014年11月10日閲覧。
外部リンク
- Curlieのバグ追跡ソフトウェア
- バグを効果的に報告する方法 ( Simon Tatham著)
- 配布されているバグ追跡ソフトウェアの一覧
