홈 페이지에 철자가 틀린 회사 이름과 거의 사용되지 않는 내보내기 기능의 충돌: 무엇을 먼저 수정하시겠습니까? 이와 같은 주장은 테스트 팀이 심각도와 우선순위를 구분하는 이유입니다. 하나는 기술적 피해를 설명하고 다른 하나는 비즈니스 긴급성을 설명합니다.

이러한 구별이 없으면 모든 버그에는 “중요”라는 레이블이 붙고 레이블은 의미를 잃게 되며 개발자는 해당 버그를 더 이상 신뢰하지 않게 됩니다. 이 가이드는 이러한 결정을 내리는 간단한 프로세스와 함께 명확한 정의와 예를 제공합니다. 예시는 설명을 위한 것이며 정확한 규모는 팀과 도구에 따라 다릅니다.

짧은 대답

심각도 답변: 이 버그가 제품에 얼마나 심각한 영향을 미치나요? 충돌이나 데이터 손실은 심각하지만 외관상의 결함은 그렇지 않습니다.

우선순위 답변: 얼마나 빨리 수정해야 합니까? 이는 영향을 받는 고객, 기한, 수익, 법적 노출 및 브랜드 평판에 따라 달라집니다.

병원을 생각해 보세요. 심각도는 환자의 상태가 얼마나 심각한지를 나타냅니다. 우선순위는 환자를 치료하는 순서이며, 이는 누가 안전하게 기다릴 수 있는지, 어떤 자원이 무료인지 등 다른 요인에 따라 달라집니다.

심각도와 우선순위를 나란히 표시

심각도 수준

대부분의 팀은 약 4~5개의 레벨을 사용합니다. 일반적인 척도는 다음과 같습니다.

우선순위 수준

각 수준이 팀에 무엇을 의미하는지, 이상적으로는 각 수준의 목표 응답 시간을 적어보세요. “P1은 누군가가 한 시간 내에 시작한다는 것을 의미합니다”는 “P1은 매우 중요하다는 것을 의미합니다”보다 훨씬 더 유용합니다.

네 가지 조합과 예시

이를 이해하는 가장 명확한 방법은 각 조합을 살펴보는 것입니다.

높은 심각도, 높은 우선순위

모든 사람이 결제에 실패하고 비즈니스는 시시각각 손실을 입으며 해결 방법이 없습니다. 이것은 명백한 경우입니다. 모든 것을 버리고 고치십시오.

심각도 높음, 우선순위 낮음

레거시 형식으로 내보낼 때 응용프로그램이 충돌합니다. 기술적으로 이는 심각한 실패입니다. 그러나 소수의 사용자만이 이 기능을 사용하고 최신 형식이 제대로 작동한다면 예정된 릴리스를 기다릴 수 있습니다.

낮은 심각도, 높은 우선순위

홈페이지에 회사명이 잘못 기재되어 있습니다. 아무 것도 손상되지 않으며 어떠한 데이터도 위험에 처해 있지 않습니다. 그러나 모든 방문자가 이를 보게 되면 신뢰가 손상되며, 내일 대규모 출시가 예정되어 있다면 오늘 수정해야 합니다.

낮은 심각도, 낮은 우선순위

거의 방문하지 않는 도움말 항목에 작은 오타가 있습니다. 편리할 때 수정하세요. 백로그가 이러한 항목으로 가득 찬 경우 하나의 정리 작업으로 일괄 처리하는 것을 고려하세요.

하나의 버그, 두 개의 다른 우선순위

동일한 결함이라도 상황에 따라 우선순위가 달라질 수 있습니다. 주문 확인 이메일이 잘못된 로고와 함께 발송되었다고 가정해 보세요.

시스템에 미치는 영향이 동일하기 때문에 심각도는 변경되지 않았습니다. 하지만 사업 상황은 그랬다. 시간도 상황을 바꿀 수 있습니다. 오늘은 P3인 버그가 주요 클라이언트가 출시되기 일주일 전에 P1이 될 수도 있습니다.

심각도와 우선순위는 누가 결정합니까?

• 테스터는 일반적으로 동작을 관찰하고 시스템에 미치는 영향을 이해하므로 심각도를 제안합니다.
• 제품 소유자 또는 관리자는 일반적으로 고객, 수익 및 로드맵을 고려하여 우선순위를 결정합니다.
• 개발자는 원인, 수정 위험 및 소요 시간에 대한 정보를 추가합니다.
• 지원팀은 얼마나 많은 고객이 영향을 받았는지, 얼마나 심각한 영향을 받았는지에 대한 증거를 제공합니다.

소스와 팀은 이러한 책임에 따라 다르며 소규모 스타트업에서는 한 사람이 모든 작업을 수행할 수도 있습니다. 중요한 것은 누가 최종 결정을 내리는지 모두가 알고 있으므로 불일치는 결정으로 끝난다는 것입니다.

버그를 평가하는 방법

확실하지 않은 경우 다음 질문을 통해 해결하세요.

심각도:

1. 데이터가 손실되거나 손상되거나 개인 정보가 노출됩니까?
2. 주요 기능이 작동하지 않나요?
3. 해결 방법이 있나요? 일반 사용자가 찾을 수 있나요?
4. 기능이 얼마나 영향을 받나요?

우선순위:

1. 영향을 받는 사용자는 몇 명이며, 어떤 사용자가 영향을 받나요?
2. 비용이 들거나 법적 또는 규정 준수 위험이 발생합니까?
3. 출시, 데모 또는 판매가 예정되어 있나요?
4. 얼마나 눈에 띄고 평판에 해를 끼칠 수 있습니까?
5. 테스트와 같은 다른 작업을 차단합니까?

버그 분류 실행

분류는 팀이 새로운 버그를 검토하고 다음에 일어날 일을 결정하는 정기 회의입니다. 간단한 형식이 잘 작동합니다.

1. 준비. 테스터는 각각의 새로운 버그에 명확한 단계, 증거 및 제안된 심각도가 있는지 확인합니다.
2. 확인합니다. 복제가 가능하고 중복이 아닌지 확인하세요.
3. 결정합니다. 심각도에 동의하고 우선순위를 설정하고 소유자를 할당합니다.
4. 루프를 닫습니다. 각 버그를 거부, 연기 또는 예약하고 이유를 기록합니다.

짧고 자주 유지하십시오. 출시 전 마지막 며칠 동안 매일 15분씩 분류하는 것이 일반적입니다. 심각도와 우선순위도 릴리스 결정에 영향을 미치므로 종료 기준의 일부로 “릴리스 시 공개된 S1 또는 S2 버그 없음”과 같은 규칙에 미리 동의하세요.

버그 신고의 심각도 및 우선순위

짧고 명확한 항목은 모든 사람이 올바른 결정을 내리는 데 도움이 됩니다.

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

해당 수치는 예시입니다. 실제 보고서에서는 로그에서 측정된 숫자를 사용하고 이유를 설명하세요. 버그 보고서 작성 방법에 대한 가이드에서 자세히 알아보세요. 또한 오류 코드가 무엇을 의미하는지 아는 데 도움이 되므로 HTTP 상태 코드 치트 시트를 가까이에 보관하세요.

일반적인 실수

• 동일한 필드로 취급합니다. 두 개가 항상 일치하면 유용한 정보를 잃게 됩니다.
• 주의를 끌기 위해 심각도를 부풀립니다. 모든 것이 중요하면 아무 것도 중요하지 않습니다.
• 테스터가 우선순위를 단독으로 설정하도록 합니다. 그들은 전체 비즈니스 그림을 거의 가지고 있지 않습니다.
• 백로그를 검토하지 마세요. 우선순위는 오래되었으므로 오래된 버그를 정기적으로 다시 확인하세요.
• 글로 된 정의가 없습니다. 그것이 없으면 사람들은 라벨을 다르게 적용하고 결국 단어에 대한 논쟁을 벌이게 됩니다.
• 심각도가 낮은 누적 문제 무시. 50가지의 사소한 문제로 인해 심각한 문제가 없더라도 제품이 손상된 것처럼 느껴질 수 있습니다.

마무리

두 가지 질문을 별도로 유지하십시오. 얼마나 나쁜지, 얼마나 빨리 수정해야 합니까? 각 수준에 대한 서면 정의에 동의하고 누가 결정하는지 명확히 합니다. 다음 단계로, 트래커에서 가장 오래된 버그 10개를 선택하고 위의 질문을 사용하여 다시 평가하세요. 아마도 몇 개는 움직여야 하고 몇 개는 닫혀 있어야 할 것입니다.

자주 묻는 질문

계속 학습하세요