Severity HighPriority High
- Checkout fails with a 500 error for all card payments
- Users can see other customers' order history
- App crashes on launch on the most-used Android version
QA ドキュメント
バグの重大度と優先度ガイド
定義、実例、4 つの質問で重大度・優先度を判定するヘルパー。
すべてブラウザ内で動作 登録不要
Decision helper
Suggestion
- Severity
- Major
- Priority
- P2 High
Why
- A partially broken feature starts at Major.
- Customer-visible problems are scheduled for the current release.
These rules give a consistent starting point. Your team’s definitions and the triage owner have the final say; priority in particular depends on business context this helper cannot see.
Severity vs priority: the 2 × 2
Severity is the technical impact on the system. Priority is how soon the business needs it fixed. They are set independently, often by different people (QA proposes severity; the product owner decides priority).
Severity HighPriority Low
- Report export crashes the app, but only on a legacy browser used by 0.1% of users
- Data corruption in a feature behind a disabled feature flag
- Crash when importing a 2 GB file when the documented limit is 50 MB
Severity LowPriority High
- Company name misspelled in the homepage header
- Wrong price shown in a launch-day marketing banner (checkout charges correctly)
- Partner logo missing on a page required by a contract
Severity LowPriority Low
- Tooltip text misaligned by a few pixels in an admin settings page
- Inconsistent capitalisation in a rarely used dialog
- Footer link hover colour differs from the design
Severity levels
| Level | Definition and example |
|---|---|
| Blocker | Stops testing or use of the product entirely: crash on start, cannot sign in, build not deployable. No workaround.e.g. App crashes on launch; sign-in returns HTTP 500 for every user. |
| Critical | A core function fails, data is lost or corrupted, or there is a security/privacy breach. No acceptable workaround.e.g. Customers are charged twice; one user can read another user’s invoices. |
| Major | A significant function does not work as specified, but there is a workaround or the impact is limited to part of the feature.e.g. Search ignores the date filter; export fails over 10 MB but smaller exports work. |
| Minor | Behaviour is wrong but the function is usable: unclear error message, wrong default, layout problem that does not hide content.e.g. Error says “Invalid input” without naming the field; wrong default sort order. |
| Trivial | Cosmetic issue with no functional impact: spacing, alignment, minor wording in rarely seen places.e.g. A settings dialog button is 2px out of alignment. |
Priority levels
| Level | Meaning |
|---|---|
| P1 Highest | Fix now. Hotfix or blocks the release; someone starts on it today. |
| P2 High | Fix in the current sprint/release before shipping. |
| P3 Medium | Fix in a planned upcoming release. |
| P4 Low | Fix when convenient; may be batched or deferred to the backlog. |
Jira’s default priorities (Highest, High, Medium, Low, Lowest) map naturally onto P1–P4 with Lowest as a backlog bucket. Names vary between teams; agree on definitions, not just labels.
Common mistakes
- Setting priority equal to severity by default. Severity describes impact on the system; priority is a business scheduling decision. They are often different.
- Inflating severity to get a bug fixed sooner. It erodes trust in triage; argue for priority instead, with the business reason.
- Rating a crash as Critical without checking reach. A crash in an unreachable code path is still high severity, but rarely high priority.
- Treating all cosmetic issues as Trivial. A broken layout that hides the Buy button is a functional problem.
- Never revisiting priority. A Low-priority bug can become urgent when a customer escalates or a launch date approaches.
- Leaving security and data-loss bugs at default severity. These are at least Critical until someone with context downgrades them.
このツールについて
バグトリアージでの議論は、たいてい 2 つの問いを混同することから生まれます。重大度はバグがプロダクトにどれだけ悪影響を与えるか、優先度はビジネスとしてどれだけ早く修正する必要があるかです。トップページの社名の誤字は重大度は低いが優先度は高く、サポート対象外のブラウザからしか到達できないレポートでのクラッシュは、重大度は高くても優先度は低いことがあります。このページでは、5 段階の重大度と 4 段階の優先度をそれぞれ例付きで定義し、実際のケースを使った定番の 2×2 マトリクスと、最も摩擦を生む間違いを紹介します。判定ヘルパーは、影響、回避策、影響範囲、ビジネス上の可視性について 4 つの質問をし、重大度と優先度を提案して、推論の各ステップを説明します。判断を置き換えるためではなく、チームの基準をそろえるために使ってください。
使い方
- バグについて 4 つの質問に答えます：影響、回避策、影響を受けるユーザー数、ビジネス上の可視性。
- 提案された重大度と優先度、およびその理由を確認します。
- 2×2 の例やレベルの定義と比較し、提案をチケットにコピーします。
バグの重大度と優先度ガイド のよくある質問
重大度と優先度はそれぞれ誰が決めるのですか？
一般的に、重大度は技術的な影響を表すためテスターが提案し、優先度はビジネスの状況、リリース日、顧客との約束に左右されるため、プロダクトオーナーやトリアージの責任者が決めます。
バグを報告した後で重大度を変えてもよいですか？
はい。調査の結果、データ損失、セキュリティへの影響、当初の想定よりはるかに広い影響範囲が判明した場合は引き上げます。回避策が見つかれば引き下げることもできます。理由はコメントに記録してください。
これらのレベルは Jira と一致していますか？
Jira のデフォルトの優先度フィールドは Highest、High、Medium、Low、Lowest を使い、重大度は通常カスタムフィールドです。ここでの名称は一般的な慣習です。重要なのは、チームが定義を文書化し、一貫して適用することです。