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.
도구 소개
버그 트리아지에서 벌어지는 논쟁은 대개 두 질문을 혼동하는 데서 시작됩니다. 심각도는 버그가 제품에 얼마나 나쁜 영향을 미치는지이고, 우선순위는 비즈니스가 얼마나 빨리 수정을 필요로 하는지입니다. 홈페이지의 회사명 오타는 심각도는 낮지만 우선순위는 높고, 지원하지 않는 브라우저에서만 접근할 수 있는 리포트의 크래시는 심각도는 높아도 우선순위는 낮을 수 있습니다. 이 페이지는 5단계 심각도와 4단계 우선순위의 정의를 각각의 예시와 함께 제공하고, 실제 사례가 담긴 고전적인 2×2 매트릭스, 그리고 가장 많은 마찰을 일으키는 실수를 정리합니다. 결정 도우미는 영향, 우회 방법, 영향 범위, 비즈니스 노출도에 대한 네 가지 질문을 던진 뒤 심각도와 우선순위를 제안하고 추론의 각 단계를 설명합니다. 판단을 대신하기보다는 팀의 기준을 맞추는 데 활용하세요.
사용 방법
- 버그에 대한 네 가지 질문(영향, 우회 방법, 영향받는 사용자 수, 비즈니스 노출도)에 답하세요.
- 제안된 심각도와 우선순위, 그리고 그 근거를 확인하세요.
- 2×2 예시와 레벨 정의와 비교한 뒤, 제안 내용을 티켓에 복사하세요.
버그 심각도와 우선순위 가이드 자주 묻는 질문
심각도는 누가 정하고 우선순위는 누가 정하나요?
일반적으로 심각도는 기술적 영향을 설명하므로 테스터가 제안하고, 우선순위는 비즈니스 맥락, 릴리스 일정, 고객과의 약속에 따라 달라지므로 프로덕트 오너나 트리아지 리드가 정합니다.
버그를 보고한 후에 심각도가 바뀔 수 있나요?
네. 조사 결과 데이터 손실, 보안 영향, 또는 처음 생각보다 훨씬 넓은 영향 범위가 드러나면 올리세요. 우회 방법이 발견되면 내릴 수 있습니다. 변경 이유는 코멘트로 기록하세요.
이 레벨은 Jira와 일치하나요?
Jira의 기본 우선순위 필드는 Highest, High, Medium, Low, Lowest를 사용하며, 심각도는 보통 사용자 정의 필드입니다. 여기 쓰인 이름은 흔히 쓰이는 관례입니다. 중요한 것은 팀이 정의를 문서로 정해 두고 일관되게 적용하는 것입니다.