Jiraって不具合追跡ツールとして作られたそうですが、分析という観点からはちょっと遠い。。
なので不具合「管理」をする上で追加したカスタムフィールドを以下にまとめた
不具合管理について
不具合を管理する意義
- 不具合追跡：不具合がどのように処理されたかを確認する
- 不具合管理：プロジェクトの不具合発生をコントロールすることが目的
追跡だけだったら、発生したことが確実に蓄積され、それらがもれなく修正・再確認・リリースされればいいのですが、「コントロールする」となれば、「なぜ」その不具合が起きたのか。
再発防止のためにはどうしたらいいのかが大事になってくるわけです。
Jiraは不具合追跡ツール？
その観点で見ると、
- タスクorバグとして「課題」を記録する
- 課題に「TODO」「進行中」「完了」といったステータスを関連付ける
- 「完了」していない課題がなくなることをひたすら目指す
ことができるようツールであることがわかります
不具合コントロールの目的
(特に継続性がある）プロジェクトに対して、「不具合」発生に対するリリース物への影響を最小にする
- 不具合に取り掛かる「優先度」を合理的に判断できるようにする
- そもそも「不具合」の発生を少なくするようにする
不具合コントロールのために必要なこと
- 優先度を判断するための必要な情報を漏れなく、最小工数で入れられる
- 不具合再発防止のための分析をするための情報を最小工数で入れられるようにする
- そして、そもそも、不具合を正しく伝えるために必要最低限の情報を漏れなく入れられるようにする
ことが大事です
不具合を正しく伝えるために必要な項目（不具合発見時報告）
カスタムフィールドを作って、課題に追加する。
- 発見方法（テストケース実施 / テスト設計 / 開発 / レビュー / 日常運用 ....)
- ラベル：後から方法が追加されるので
- 発生環境 (dev / staging /本番 ..)
- ラベル：後から方法が追加されるので
- 再現方法
- 複数行テキスト
- 期待値
- 複数行テキスト
- 問題点：期待値と異なること
- 複数行テキスト
- 発生頻度 (常に、不規則、希に、1度だけ）
- 選択リスト（単一選択）
- 参照（テスト項目書 /参考仕様書 ... テストケースとの突き合わせに必要）
- テキストフィールド（1行）
- URL
- アプリバージョン=Revision (テキストフィールド1行)
優先度判断に必要となるもの (不具合原因調査時)
- 不具合レベル（損害リスク・業務停止・運用回避（要復旧）・運用回避（復旧不要）・影響なし）
- 選択リスト（単一選択）
- 新規/潜在（潜在不具合/直近開発由来）
- 選択リスト（単一選択）
- 発生原因
- 複数行テキスト
- 影響範囲
- 複数行テキスト
- 対応方法 (対応不要 / 仕様書修正 / テスト修正 / 実装対応 / その他環境修正など )
- 選択リスト（複数選択）
再発防止に必要なこと（不具合対応後)
- 不具合種別
- 不明,仕様誤り,仕様漏れ,設計誤り,設計漏れ,実装誤り,実装漏れ, 環境設定誤り,テストデータ誤り,テスト仕様誤り, リリース誤り, 再現せず,その他
- ラベル：後から方法が追加されるので
- 対処内容
- 複数行テキスト
- 原因分析
- 複数行テキスト
- 再発防止案(防止策）
- 複数行テキスト
タスク管理に必要なこと
- 件名
- 報告者
- 報告日
- 調査完了目標日
- 調査完了日
- 調査者
- 対応完了目標日
- 対応完了日
- 対応者