QA 실무 가이드

📌 QA 실무 가이드 7편 — 버그 Severity / Priority 실전 기준

qa-note 2025. 12. 29. 10:45
반응형

QA 일을 하다 보면 꼭 나오는 질문이 있어요.
“이 버그, 심각한 건가요?”
“이건 지금 당장 고쳐야 하나요?”

그리고 회의에서는 이런 말도 자주 나와요.

“Severity는 낮은데 Priority는 높지 않나요?”
“이거 치명적이긴 한데, 지금 릴리즈엔 영향 없지 않아요?”

이번 글에서는
👉 버그 Severity / Priority 개념을 QA 실무 기준으로,
👉 헷갈리지 않게, 바로 써먹을 수 있게 정리해볼게요.


1️⃣ Severity / Priority를 왜 구분해야 할까?

Severity와 Priority를 제대로 구분하지 못하면 생기는 문제가 있어요.

  • 개발자와 기준이 안 맞음
  • 기획자와 판단이 엇갈림
  • QA 리포트 신뢰도 하락

👉 반대로, 이 둘을 명확히 설명할 수 있으면
QA는 단순 테스트 담당자가 아니라 ‘품질 판단자’가 돼요.


2️⃣ 먼저 개념부터 정확히 정리하자

✔ Severity (심각도)

버그 자체가 얼마나 치명적인가

  • 기능이 아예 안 되는가?
  • 핵심 기능인가?
  • 사용자에게 큰 피해가 있는가?

👉 “이 버그가 얼마나 심각한가”


✔ Priority (우선순위)

이 버그를 얼마나 빨리 고쳐야 하는가

  • 이번 릴리즈에 포함되는가?
  • 지금 고치지 않으면 문제가 되는가?
  • 다른 일정에 영향이 있는가?

👉 “이 버그를 언제 고칠 것인가”


3️⃣ QA 실무에서 가장 중요한 한 문장

👉 Severity는 ‘버그의 성질’이고, Priority는 ‘일정과 판단의 문제’다.

이 문장 하나만 기억해도 회의에서 흔들릴 일이 확 줄어요.


4️⃣ 실무에서 자주 쓰는 Severity 기준 예시

Severity 기준 예시
Critical 서비스 이용 불가 결제 불가, 로그인 불가
Major 핵심 기능 오류 주문은 되나 금액 계산 오류
Minor 부분 기능 오류 특정 조건에서만 오류
Trivial 영향 거의 없음 오타, UI 깨짐

👉 회사마다 명칭이나 단계는 달라도, 이 기준 구조는 거의 비슷해요.


5️⃣ Priority는 QA 혼자 결정하지 않는다

이 부분이 실무에서 정말 중요해요.

Priority에 영향을 주는 요소

  • 릴리즈 일정
  • 기획 의도
  • 사용자 영향 범위
  • 대체 수단 존재 여부

👉 그래서 Priority는 보통 QA + 기획 + 개발이 함께 판단해요.


6️⃣ 헷갈리기 쉬운 대표적인 케이스들

🔹 Severity는 높은데 Priority는 낮은 경우

  • 관리자 페이지 오류
  • 특정 내부 사용자만 사용하는 기능
  • 다음 배포에서 같이 수정 가능한 경우

👉 “치명적이지만, 지금은 아니다”


🔹 Severity는 낮은데 Priority는 높은 경우

  • 메인 페이지 UI 깨짐
  • 이벤트 페이지 노출 오류
  • CS 유입이 많은 문제

👉 “가볍지만, 빨리 고쳐야 한다”


7️⃣ QA가 이슈 리포트에 꼭 써줘야 할 문장

Severity / Priority를 잘 전달하는 QA는 단순히 값만 적지 않아요.

✔ 좋은 리포트 예시

Severity: Major
Priority: High
사유: 주문은 가능하나 금액 계산 오류로 사용자 혼란 가능성이 높으며,
현재 릴리즈 범위에 포함된 기능임

👉 이렇게 쓰면 “왜 이 판단을 했는지”가 바로 전달돼요.


8️⃣ 신입 QA가 자주 하는 실수

  • 모든 버그를 High / Critical로 설정
  • 기준 없이 감으로 판단
  • Priority를 혼자 확정해버림

👉 괜찮아요. 중요한 건 기준을 설명하려는 태도예요.


9️⃣ Severity / Priority를 잘 쓰는 QA의 공통점

  • “왜 이게 중요한지” 설명할 수 있음
  • 환경(stage / prod) 기준으로 말함
  • 일정과 사용자 영향을 함께 고려함

👉 이 단계부터 QA는 테스트 담당자 → 품질 관리자로 역할이 바뀌어요.


1️⃣0️⃣ 정리하며

  • Severity = 버그의 심각도
  • Priority = 수정의 시급성
  • 둘은 다를 수 있고, 다르게 판단하는 게 정상

“Severity는 높지만 Priority는 낮습니다.”
이 문장을 자연스럽게 말할 수 있다면, 이미 QA 실무에서는 충분히 인정받을 수 있어요.


🔗 함께 보면 좋은 글

반응형