개념
결함의 생명주기
모듈 1(레슨 2)에서 오류(error)·결함(defect)·실패(failure)를 구분했다. 결함이 발견되면 그걸로 끝이 아니다 — 팀 안에서 정해진 상태를 거쳐 종결될 때까지 추적된다. 흔히 쓰이는 흐름은 다음과 같다.
New(신규)
→ Assigned(담당자 배정)
→ In Progress(수정 중)
→ Fixed(수정 완료)
→ Retest(재검증)
→ Closed(종결)재검증 단계에서 문제가 남아 있으면 두 갈래로 갈린다.
- Reopened(재오픈): 수정했다고 했지만 재검증 결과 여전히 재현된다 → 다시 In Progress로 되돌아간다
- Rejected(반려): 애초에 결함이 아니다(의도된 동작, 재현 불가, 환경 문제 등) → 별도 상태로 종결
- Duplicate(중복): 이미 등록된 다른 결함과 같은 것 → 원본 결함에 병합하고 종결
재검증은 모듈 1(레슨 4)의 "확인"이다
Retest 단계는 모듈 1(레슨 4)에서 배운 확인(Confirmation Testing) 그 자체다 — 개발자가 "고쳤다"고 보고한 것을 그대로 믿지 않고, 원래 결함을 재현했던 정확한 절차를 다시 밟아 실제로 사라졌는지 QA가 직접 확인한다.
심각도(Severity)와 우선순위(Priority)는 다른 축이다
이 둘을 같은 말로 혼동하는 경우가 많지만, 실무에서는 명확히 다른 두 질문에 대한 답이다.
| 축 | 질문 | 누가 정하는가 |
|---|---|---|
| 심각도 | 이 결함이 시스템에 얼마나 나쁜 영향을 주는가? | QA가 기술적으로 판단 |
| 우선순위 | 이 결함을 얼마나 빨리 고쳐야 하는가? | 비즈니스 관점에서 팀/PM이 판단 |
심각도는 "결함 자체의 무게"이고, 우선순위는 "지금 상황에서 이걸 먼저 고칠지 말지에 대한 줄서기 순서"다. 둘은 대체로 비례하지만, 항상 같이 움직이지는 않는다 — 이게 이 레슨의 핵심이다.
2x2 매트릭스로 보는 네 가지 조합
| 우선순위 높음 | 우선순위 낮음 | |
|---|---|---|
| 심각도 높음 | 결제 실패로 주문 자체가 안 됨 → 즉시 수정 | 연 1회 결산 화면 크래시(다음 결산까지 시간 있음) → 심각하지만 급하지 않음 |
| 심각도 낮음 | 로그인 화면 로고가 회사명과 다른 로고로 표시(내일 투자자 데모) → 사소하지만 지금 당장 급함 | 설정 페이지 오탈자 하나 → 심각하지도 급하지도 않음 |
심각도 높음·우선순위 낮음의 예(연 1회 결산 화면)와 심각도 낮음·우선순위 높음의 예(내일 데모용 로고)를 보면, 왜 이 둘을 하나로 뭉뚱그리면 안 되는지 분명해진다. 결함 리포트를 쓸 때는 이 두 값을 각각 독립적으로 판단해서 채워야 한다.
실무에서 왜 필요한가
이슈 추적 도구(레슨 4에서 다룬다)의 Severity/Priority 필드를 QA가 직접 채우는 경우가 많다. 이 둘을 구분 못 하면, 사소한 버그에 최고 우선순위를 붙여 팀의 신뢰를 잃거나, 반대로 심각한 버그를 낮은 우선순위로 묻어버려 사고로 이어질 수 있다. 심각도·우선순위를 정확히 분리해서 판단하는 능력은 QA가 개발팀·PM과 대화할 때 쓰는 공용 언어다.
실습 과제
과제 1 — 상태 흐름 그려보기 (8분)
"장바구니에 담긴 상품 수량이 마이너스로 표시된다"는 결함을 발견했다고 하자. New부터 Closed까지, 그리고 만약 재검증에서 재현된다면 어떤 상태로 되돌아가는지 전체 흐름을 순서대로 적어본다.
과제 2 — 2x2 매트릭스 채우기 (12분)
아래 4개의 결함을 각각 심각도(높음/낮음)와 우선순위(높음/낮음)로 분류하고, 왜 그렇게 판단했는지 한 줄로 적는다.
- 회원가입 시 비밀번호 확인란이 실제로는 비교를 안 해서 다르게 입력해도 가입된다
- 다크 모드에서 버튼 테두리 색이 살짝 어색하다
- 내일 오전 대규모 마케팅 이메일 발송 예정인데, 이메일 본문의 쿠폰 링크가 깨져 있다
- 관리자 전용 통계 페이지(월 1회만 확인하는 화면)의 그래프 색상 순서가 뒤바뀌어 있다
자가 체크리스트
- 결함의 생명주기 상태를 New부터 Closed까지 순서대로 설명할 수 있다
- Reopened·Rejected·Duplicate가 각각 어떤 상황에서 쓰이는지 구분할 수 있다
- Retest 단계가 모듈 1의 "확인" 개념과 같다는 것을 설명할 수 있다
- 심각도와 우선순위가 왜 서로 다른 축인지, 예시를 들어 설명할 수 있다
- 심각도 높음·우선순위 낮음(또는 그 반대) 조합의 실제 예시를 들 수 있다
흔한 실수
- 심각도와 우선순위를 같은 값으로 취급한다. "버그가 심하니까 당연히 급하다"는 생각은 대부분 맞지만, 항상 그런 것은 아니다 — 매번 두 질문을 따로 던져야 한다.
- 재검증 없이 "개발자가 고쳤다고 했으니 Closed"로 바로 넘긴다. Retest는 QA가 직접 재현 절차를 다시 밟아 확인해야 하는 단계다.
- Rejected와 Duplicate를 구분하지 않고 아무렇게나 종결한다. 이 구분이 정확해야 이슈 추적 도구의 통계(레슨 5의 결함 밀도 등)가 의미를 가진다.
참고 자료
- ISTQB Glossary — Defect Life Cycle — 결함 생명주기의 공식 용어 정의
- Cem Kaner 외, Lessons Learned in Software Testing — 심각도·우선순위 판단 기준을 다룬 장