Bug's Life Wiki - Bug's Life

概要

故障管理システム(bug’s life)はBugzillaをモデルに、品質管理面を強化したツールです。

以下のような特徴があります。

Mozillaの様なオープンソース系ではなく、商用プロジェクトに向いています。
単体試験より結合試験以降の１つの故障に対して複数人が関わるような工程で威力を発揮します。
品質管理のための統計情報を取得することが出来ます。
定義体（各種区分情報）は全てＤＢで管理しているため、プロジェクトに合わせてカスタマイズ出来ます。
APサーバはTomcat、DBはMySQLなので、商用プロジェクトでも使えます。
Javaで組まれているため、プラットホームを選びません。(windowsでのみ実績あり)
Webインタフェースのため、開発場所が離れたプロジェクトでも適用することが出来ます。

提供機能

本ツールでは以下の機能を提供します。

No	分類	機能名	概要
1	故障管理	故障登録	故障の新規登録機能
2		故障更新	故障内容の更新およびステータス管理機能
3		故障参照	故障内容の閲覧機能
4		故障検索	検索条件を指定して一覧に表示する機能
5	補助	ファイル添付	ファイルのアップロード、ダウンロード
6		関連登録・参照	関連する故障番号の登録と依存関係の表示機能
7		履歴管理	更新履歴の管理・表示機能
8	一覧表示	インフォメーション	変更された直近の故障表示機能、お知らせ等の表示機能
9		マイバグリスト	自分に関係のある故障を表示する機能
10	統計	統計	統計情報の表示機能・担当者別／発行者別一覧
11	メンテ	区分管理	各種区分のメンテナンス画面
12		ユーザ管理	ユーザの登録・更新機能
13	メール	メール通知	登録・更新された故障内容をメールで通知する機能

故障管理フロー

本ツールでは故障情報を扱うためのフローを以下に想定しています。

1.試験者による故障の発見

試験者（チーム）により、試験を行った際に何らかの問題が発見された場面です。試験者は仕様書を元に試験項目表を起こし、試験を行います。実際に試験を行った際に仕様書と違う動作であった場合「問題」として、故障管理に登録されます。

この段階では、それが「バグ」なのか「非バグ」なのかを切り分けせず、まず問題として提起します。また、事象が特定できない問題の場合は、「未確認」の形でまず登録され、情報の共有を図ります。

2.判定による方針の決定

登録された問題は、リーダおよび開発者によって「バグ」「非バグ」「仕様変更」等に切り分けられ、解析の対象となるコンポーネント及び解析順を割り当てられます。また、提供目標（いつまでに）と優先度もこの段階で設定され、開発者はこれによってスケジューリングを行います。この段階では、まだ解析が始まっていないので、解析者への依頼事項や修正の方針等が連絡されます。

3.バグの解析

解析担当者は自担当分の解析をし、問題が発見出来れば解析内容を登録し、修正に入ります。また、障害によっては自担当ではなく他担当に問題があるかもしれません。その場合、自担当分の解析内容を登録し、次の解析担当者を割り当てます。

さらにエラー分析もこの段階で行います。

4.バグの修正

バグを修正し、動作が確認されると修正内容を登録します。その際に修正したソース情報やドキュメント情報も登録し、試験者に情報を提供します。また、修正ソースをすぐに提供できない（他の障害の修正が入っている等）場合、提供予定日も付加します。

5.吸収の確認

修正されたソースにより再試験をし、吸収が確認出来れば完了ですが、確認出来なければ「再開」となります。

処理フロー

故障のステータス

故障は以下の「ステータス(status)」を持ちます。そのほかに重要なのが「対処方法(resolurion)」です。対処方法＋ステータスで故障の状態を知ることが出来ます。ステータスの流れを以下に示します。

主な対処方法を以下に示します。

コード	名称	概要
01～09	バグ	この問題が「バグ」と認識されたもの
10～11	仕様通り	この問題は「仕様通り」であると認識されたもの。試験者の誤理解等がある。ただし、仕様通りではあっても改善としてソース修正が入ることがある。
12	再現せず	試験環境や条件の違い、ソースのバージョン違い等により再現しないもの。
16	重複	他の障害と重複して登録されたもの。完全に重複して申告されたものの他に、事象は違うが他障害によって引き起こされものがある。
20	仕様変更	障害として登録されたが、仕様扱いとなるもの。仕様変更番号があれば付加する。
21	保留	何らかの理由により保留扱いとなっているもの。
22	対処なし	バグではあっても対処をしないもの。次フェーズで無くなる機能やあまりにも影響範囲が大きい場合など。