【けっかんらいふさいくる】
欠陥ライフサイクル とは?
最終更新:
💡 欠陥報告の状態と、次にすることを追う
欠陥の報告を、発見・登録から対応方針の判断、修正の確認、クローズなどへ進める状態の流れ。状態名や遷移はチームごとに定め、重複や却下など、修正せずに終える場合も理由を記録する。
📌 このページのポイント
- 新規、修正待ち、確認待ち、クローズなどで報告の状態を管理する
- 状態名・遷移・担当・完了条件はチームの運用に合わせて定める
- 再確認で直っていなければ、修正へ戻すことがある
- クローズは必ずしも修正済みを意味せず、却下や重複なども区別する
バグにもライフサイクルがあるの?
発見した問題を報告し、その後どう扱うかを追う流れだよ。例えば登録、修正、再確認、クローズという状態を使う。ただし名前や順番は共通の決まりではなく、チームの運用で定めるんだ
報告したものは全部バグ?
調べると、重複した報告や、期待の誤り、変更の要望だと分かることもあるよ。再現手順、環境、期待した結果と実際の結果、証拠などを残して判断する。最初の報告だけで欠陥と確定するとは限らないんだ
ずっと一方向に進むの?
修正を再確認しても直っていなければ、再オープンして修正へ戻ることがある。今は直さないと判断して保留する場合もあるよ。どの状態へ戻すかや、いつ見直すかは運用に合わせて決めるんだ
クローズしたら完治?
修正を確認して閉じる場合も、重複や却下などの理由で閉じる場合もある。だから状態だけで修正済みと決めつけず、終了理由と確認結果を見る。保留中の報告も、修正済みとは違うんだ
どうすれば対応漏れを減らせる?
追跡ツールなどで担当と次の行動、判断の理由を記録し、状態を更新するよ。「確認待ち」を誰が確認し、何をもって閉じるかを合意しておくと役立つ。状態を付けるだけで放置がなくなるわけではないので、残る報告を見直すことも大切なんだ
まとめ:ざっくりこれだけ覚えればOK!
「欠陥ライフサイクル」って出てきたら「欠陥報告の状態と対応を追う流れ」と思えばだいたいOK!
📖 おまけ:英語の意味
「Defect Lifecycle」 = 欠陥のライフサイクル
💬 Defectは欠陥、Lifecycleは一連の段階を表すよ。ここでは欠陥報告の扱いを追うので、クローズしたら必ず不具合が消えるという意味ではないんだ