障害レポートはその障害に対して担当者がどこまで対処を終えたかを表すステータスを持ちます。
不具合が検出され、その不具合の対処が完了するまでのフローは、ステータスの状態遷移によって表すことができます。
「Defect Life Cycle」という言葉で検索することで似たような様々な種類の状態遷移図を見ることができますが、本サイトではわかりやすく、そして規則性をもって表せるよう考慮して以下のようにまとめました。
起票 → （担当割当中） → 担当割当済 → （調査中） → 調査済 → （対処中） → 対処済 → （検証中） → 検証済 → （承認中） → 完了
基本的にかっこの部分は含めなくても進捗の管理はできるかなと思いますが、かっこ部分もステータスとして含めておくと、今「誰が」「何をしているのか」がレポート上でわかりやすいです。
ただ、あまりこだわって細かくやり過ぎると業務が複雑になり運用に乗りづらいというデメリットもあるので、この辺りは臨機応変に対応していけば良いかと思います。
1. 起票【Opened】
不具合を検出し、不具合内容を記載した障害レポートを発行した状態。
起票者やテスト責任者は不具合原因の調査を行う担当者の割り当てを開始する。
↓ 担当割当中【assign】（by 起票者、テスト責任者など）
2. 担当割当済【Assigned】
調査担当者が割り振られた状態。
担当者は不具合の発生原因や故障箇所の特定を開始する。
↓ 調査中【investigate】（by 調査担当者、設計者、プログラマなど）
3. 調査済【Investigated】
不具合の原因が判明し、対処方法が検討された状態。
開発担当者はプログラム修正や障害原因の除去処置を開始する。
↓ 対処中【fix】（by 開発担当者、プログラマなど）
4. 対処済【Fixed】
検討された対処方法によってプログラム修正などの何らかの処置が施された状態。
起票者あるいはテスターは対処内容に問題がないかの検証および RT（リクグレッションテスト）を行う。
↓ 検証中【verify】（by 起票者、テスター、開発担当者など）
5. 検証済【Verified】
対処内容の検証が完了し、問題ないことが確認された状態。
↓ 承認中【approve】（by テスト責任者、PLなど）
6. 完了【Closed】
本障害についてやるべきことがすべて完了した状態。
上記は通常のパターン、一般的なルートですが、図1 のようにイレギュラーケースが存在します。
3a. 既存障害【Duplicate】
すでにレポートとして挙げられている既知の障害であり、以降の内容は先に発行したレポートに記述される。
本レポートはここで完了とする。
3b. 処置なし【Reject】
現象がまったく再現しない、見当違いの指摘、内容が不明瞭などこれ以上調査・修正の必要性がないと判断されたもの。
本レポートはここで完了とする。
3c. 仕様通り【On Spec】
発生した現象は仕様通りに動作した結果であり、問題ないと判断されるもの。
本レポートはここで完了とする。
3d. 将来検討【Deferred】
今は一旦保留するが、将来的には何らかの対処を行うもの。
プロジェクトの都合により対処を延期するもの。
本レポートはここで完了とする。
5a. 差し戻し【Test failed】
修正確認テストの結果、不具合が十分に直っていないもの。
異なる不具合やデグレードが発生したもの。
もう一度調査あるいは対処から始める。
コメント