버그 우선순위

버그 우선순위(Bug priority)는 결함을 어떤 순서로 수정할지를 나타냅니다. 사용자 영향, 마감일, 고객과의 약속, 평판, 수정 비용을 저울질하는 비즈니스 결정입니다. 테스터가 우선순위를 제안할 수는 있지만, 최종 결정은 보통 프로덕트 오너가 내리며, 개발과 QA가 함께하는 트리아지(triage) 회의에서 정하는 경우가 많습니다.

일반적인 척도

우선순위	의미
P1 / 긴급	즉시 수정. 정규 릴리스와 별도로 핫픽스가 필요할 수 있음
P2 / 높음	현재 스프린트 또는 다음 릴리스 전에 수정
P3 / 보통	이후 스프린트에 일정 배정
P4 / 낮음	여유가 있을 때 수정하거나, 수용하고 종료

우선순위와 심각도의 차이

**심각도(Severity)**는 영향, 즉 제품이 얼마나 심하게 망가졌는지를 측정합니다. **우선순위(Priority)**는 긴급성, 즉 얼마나 빨리 고쳐야 하는지를 측정합니다. 둘은 서로 어긋나는 경우가 많기 때문에 따로 평가합니다.

• 낮은 심각도, 높은 우선순위: 내일 시작하는 캠페인 배너에 가격이 잘못 표시된 경우. 아무것도 크래시되지 않지만 출시 전에 반드시 바로잡아야 합니다.
• 높은 심각도, 낮은 우선순위: 11개월 뒤인 연말에만 실행되는 관리자 리포트의 크래시.

또한 심각도는 대개 그대로지만 우선순위는 시간에 따라 바뀝니다. 같은 연말 크래시도 12월이 되면 P1이 됩니다.

우선순위를 정하는 방법

트리아지에서 유용한 질문:

• 영향을 받는 사용자는 몇 명이고, 누구인가(유료 고객, 내부 직원, 특정 테넌트 하나)?
• 우회 방법이 있고, 고객 지원팀이 그것을 안내할 수 있는가?
• 릴리스, 데모, 법적 또는 계약상 마감일이 있는가?
• 수정 자체의 비용과 위험은 어떤가? 릴리스 막바지의 위험한 수정은 의도적으로 연기할 수도 있습니다.

흔한 실수

• 하나의 필드로 둘 다 관리하기. “우선순위”만 관리하는 팀은 영향에 대한 정보를 잃게 되는데, 이는 릴리스 위험과 지표에 중요합니다.
• 모든 버그가 P1. 대부분의 버그가 긴급하다면 사실상 긴급한 버그는 없는 것입니다. 최상위 레벨은 드물게, 명확하게 정의해 두세요.
• 우선순위를 다시 검토하지 않기. 릴리스 계획이나 고객 상황이 바뀌면 열려 있는 버그를 재평가하세요.