判断できるバグトリアージ
優先度と担当決定のためのバグトリアージテンプレート
各トリアージ結果を明確にします。情報依頼、受理して割り当て、重複として統合、レビュー日付きの延期、理由付きの却下。
サインインしてこのサンプルデータ入りビューを確認し、サンプルデータ付きでアプリをインストールして、接続されたレコード、判断、ダッシュボードをテストします。
トリアージが出すべき判断
バグトリアージは、報告を管理された次のアクションへ変換します。判断には、声の大きさではなく、再現性、ユーザー影響、緊急度を使うべきで、担当者、対象リリース、またはレビュー日を残す必要があります。
- 重要度と優先度を分けて保持
- 重複と情報不足の結果でも文脈を保持
- 受理されたバグは担当者と対象リリースを持って次へ進む
トリアージルール
同じ質問を同じ順序で使う
一貫したトリアージは、バックログ判断を説明可能にし、恣意的な優先度のつり上げを減らします。
再現できるか？
手順を確認するか、具体的な情報依頼として差し戻します。
すでに知られているか？
重複を 1 つの正本課題に統合し、報告の文脈を保持します。
影響は何か？
ユーザー、データ、セキュリティ、運用上の影響から重要度を設定します。
いつ対応すべきか？
緊急度、回避策、リリース時期から優先度を設定します。
次のアクションの担当者は誰か？
コンポーネント担当者と、対象リリースまたはレビュー日を割り当てます。
2 つの判断を一つにまとめない
重要度は影響の大きさを示し、優先度は対応順を示します
両者は関連することが多いものの、安全な回避策があれば影響の大きい不具合を延期できる場合があります。一方で、小さな課題でも直近のローンチでは緊急になることがあります。
| 観点 | Question | 例 |
|---|---|---|
| 重要度 | その不具合はユーザーや事業にどれほど悪影響を与えるか？ | 確認なしに決済が確定される場合は重大です。 |
| 優先度 | 他の作業と比べて、チームはどれくらい早く対応すべきか？ | 広く露出する前でも、リリースブロッカーは P0 です。 |
| 回避策 | ユーザーは別の方法で安全にタスクを完了できるか？ | 手動照合は、影響ではなく直近の緊急度を下げます。 |
| 対象リリース | どの候補に修正を含めるべきか？ | 検証に合格するまで Web 4.28.0 は保留されます。 |
すべての行に出口が必要
なぜバグが進んだのか、または進まなかったのかを記録
判断が残り、後から見直せるようになると、バックログは役に立ちます。
情報不足
報告者に具体的な依頼を返します。
受理
担当者、優先度、対象リリースを割り当てます。
重複
正本課題にリンクし、新しい証跡を保持します。
延期
理由と、再検討の日付またはトリガーを記録します。
却下
対象外の範囲、期待される挙動、または未対応ケースを説明します。
質問と境界
バグトリアージに関する質問
影響、緊急度、担当を割り当てるための実践的なガイダンス。
チームはどのくらいの頻度でバグをトリアージすべきですか？
頻度は件数とリスクに合わせます。重大な本番報告は即時ルーティングが必要です。通常の報告は、製品チームが毎日または週に数回レビューできます。
誰がトリアージに参加すべきですか？
ユーザー影響を理解する人、影響を受けるコンポーネントを理解する人、担当またはリリース時期を確定できる人を含めます。
重複はクローズすべきですか？
重複としてマークできますが、報告者、文脈、証跡を保持し、正本課題にリンクします。重複の量は影響の大きさを示すことがあります。
延期されたバグはどうなりますか？
理由とレビューのトリガーを与えます。担当のない「後で」状態は、隠れたバックログ増加にすぎません。
バックログ判断を説明可能にする
サンプルデータ入りのトリアージ結果から始める
ルールを調整する前に、受理、情報不足、重複、延期、再オープンの例を確認します。