[QA : 업무 프로세스 관리] "결함 우선 순위"와 "심각도" 활용 : 품질 지표 정량화 하기

Defect와 Bug와 Error, Failure는 모두 같은 말인가요?

Defect와 Bug와 Error, Failure는 모두 같은 말인가요?

 

주요 차이점

✔ 결함 우선순위는 개발자가 결함을 해결해야 하는 순서이고, 심각도는 결함이 제품 작동에 미치는 영향의 정도입니다.
✔ 결함 우선순위는 3가지 유형으로 분류되고, 심각도는 중요의 4가지 유형으로 분류됩니다.
✔ 결함 우선순위는 스케줄링과 연관되고, 심각도는 기능 또는 표준과 연관됩니다.
✔ 결함 우선순위는 버그를 수정해야 하는 시기를 나타내고, 심각도는 제품 기능에 대한 결함의 심각성을 나타냅니다.
✔ 결함 우선 순위는 관리자 / 클라이언트와 협의하여 결정되며 결함의 심각도 수준은 QA 혹은 테스터가 결정합니다.
✔ 결함 우선 순위는 비즈니스 가치에 따라 결정되는 반면 심각도는 기능에 따라 결정됩니다.
✔ 결함 우선순위 값은 주관적이며 프로젝트 상황의 변화에 따라 일정 기간 동안 변경될 수 있는 반면 심각도 값은 객관적이고, 변경 가능성이 적습니다.
✔ 높은 결함 우선순위 및 낮은 심각도 상태는 결함을 즉각적으로 수정해야 하지만 애플리케이션에 영향을 미치지 않는 반면 높은 심각도와 낮은 우선순위 상태는 결함을 수정해야 하지만 즉각적인 기반이 아님을 나타냅니다.
✔ 결함 우선 순위 상태는 고객 요구 사항을 기반으로 하는 반면 심각도 상태는 제품의 기술적 측면을 기반으로 합니다.

 

결함의 심각도를 결정하기 위한 팁

✔ 발생 빈도 결정 : 경우에 따라 코드에서 사소한 결함이 자주 발생하면 더 심각할 수 있습니다. 따라서 사용자 입장에서는 사소한 결함이지만 심각하게 받아들일 수 있습니다.

✔ 결함 분리 : 결함을 분리하면 심각도의 영향을 파악하는 데 도움이 될 수 있습니다.

 

개발 우선 순위와 심각도 사분면

 

실무 적용 팁 우선순위 대 심각도 : 주요 차이점

우선 순위	심각성
결함 우선 순위는 개발자가 결함을 해결해야하는 순서를 정의했습니다.	결함 심각도는 결함이 제품 작동에 미치는 영향의 정도로 정의됩니다.
우선 순위는 세 가지 유형으로 분류됩니다. - Low - Medium - High	심각도는 4가지 유형으로 분류됩니다. - Critical - Major - Minor - Trivial
우선 순위는 일정과 관련이 있습니다.	심각도는 기능 또는 표준과 관련이 있습니다.
우선 순위는 버그를 수정해야하는시기를 나타냅니다.	심각도는 제품 기능에 대한 결함의 심각성을 나타냅니다.
하자 우선 순위는 관리자 / 고객과 협의하여 결정	QA 혹은 테스터가 결함의 심각도 수준을 결정합니다.
우선 순위는 비즈니스 가치에 의해 결정됩니다.	심각도는 기능에 의해 결정됩니다.
그 가치는 주관적이며 프로젝트 상황의 변화에 ​​따라 일정 기간 동안 변경 될 수 있습니다.	그 가치는 객관적이고 변경 가능성이 적습니다.
우선 순위가 높고 심각도가 낮은 상태는 즉시 결함을 수정해야하지만 애플리케이션에 영향을 미치지 않음을 나타냅니다.	심각도가 높고 우선 순위가 낮은 상태는 결함을 수정해야하지만 즉각적인 기반이 아님을 나타냅니다.
우선 순위 상태는 고객 요구 사항을 기반으로합니다.	심각도 상태는 제품의 기술적 측면을 기반으로합니다.
UAT 동안 개발 팀은 우선 순위에 따라 결함을 수정합니다.	SIT 중에 개발 팀은 심각도 및 우선 순위에 따라 결함을 수정합니다.

 

결함 우선순위와 심각도에 대한 실무 적용 : 품질 지표의 정량화

현실 업계에서는 대부분 결함 우선순위만 사용하거나 심각도만 사용하거나 둘 다 사용하는 경우는 극히 드뭅니다.

 

✔ 현재 저희 회사에서도 결함 우선순위를 심각도로 가장하여 사용하고 있습니다.

 

개선이 꼭 필요한 부분이기 때문에 시스템 도입과 함께 아래 내용을 적용해 보려 합니다.

저희는 결함 심각도에 대해서 가중치를 부여하고 있습니다.

• Critical(1.6)
• Major(1.2)
• Minor(0.8)
• Trivial(0.4)

유형을 4가지로 사용하고 있고, 각각에 해당하는 가중치를 부여하고 있습니다.

품질 지표를 정량적으로 뽑기 위해서인데요.

 

예를 들면, 100개의 테스트 케이스를 수행했는데 결함이 Critical : 2개, Major : 3개가 발견되었다면

보통의 품질률은 1-(결함 개수 / 전체 테스트 케이스)로 계산을 하는데요. 계산을 하게 되면 아래와 같습니다.

1-(5/100)*100 = 95.00%

저희는 가중치를 부여해서 같은 결함이라도 심각도에 따라 품질률을 다르게 적용하고 있는 겁니다.

저희 기준으로 가중치를 부여해서 계산을 하게 되면

1-((2*1.6+3*1.2)/100) = 93.20%

위와 같이 차이가 나게 됩니다.

하지만 위의 계산법으로만은 품질이 좋은지 나쁜지 알 수 없기에 정책을 적용하고 있습니다. 딱 한 줄인데요.

Major 이상 이슈가 없고, 최종 성공율이 95% 이상인 경우 배포한다.

이 정책에 뒷받침이 되는 데이터가 하나 더 있습니다.

그것은 바로 테스트 커버리지 = 100%입니다.

사실 테스트 커버리지는 무한대이기 때문에 기준을 명확히 해야 합니다. 저희가 잡은 기준은 아래와 같습니다.

요구명세서 = 스토리보드(화면 설계서) = 테스트 케이스 + 발견한 결함 수(모수)

해당 테스트 케이스를 수행하고, 완료율이 100%이 일 때가 베이스 출시 조건입니다.

✔ 이때 발견한 결함도 하나의 테스트 케이스로 계산됩니다.

 

ex) 10개의 테스트 케이스 수행 중 1개의 결함이 발견되었으면, 다음 차수의 테스트 케이스는 11개(모수)

[ -1 카운트의 조건]

• Reopen은 중복으로 제외
• 테스트 케이스를 Fail로만 두지 않고, 결함을 따로 등록했다면 중복으로 제외

그리고 앞으로 적용해 보려 하는 부분은 결함 우선순위를 적용하려 합니다.

저희 비즈니스적으로 크게 문제가 되는 부분이 바로 "오타"입니다.

 

예를 들면, 교육업계이다 보니 "아버지 가방에 들어가신다."의 의미로 이슈가 발생하면, 개발 난이도는 낮지만 우선순위가 아주 높기 때문입니다.

 

그래서 생각한 아이디어는 결함 우선순위에도 가중치를 설정하는 것입니다.

• High(1.5)
• Medium(1.0) : Default
• Low(0.5)

만약에 심각도가 Minor(0.8)한 결함. 보통의 오타는 Minor 하게 설정을 하는데요. 이게 교육적으로 문제가 되는 부분이라 판단되면, 결함 우선순위를 High(1.5)로 설정하고, 최종 결함의 심각도를 Minor(0.8) * High(1.5) = Major(1.2)로 결함의 무게를 늘리는 방법입니다.

 

결론

1. 정책을 명확히 해야 합니다.

✔ 정책은 공신력이 있어야 하면 의무 사항으로 모두가 지켜야 합니다.

 

2. 테스트 커버리지의 모수를 명확히 합니다.

✔ 코드 커버리지는 코드의 줄 수의 따라 100% 달성이 가능하지만 테스트 커버리지는 테스트 케이스를 명확하게 하지 않으면 알 수 없는 부분이기 때문에 최대한 기준을 명확히 해야 합니다.

✔ 10년 이상 수행해봤을 때 스토리보드 기준 (테스트 케이스 + 발견한 결함)의 모수가 가장 명확하다고 생각됩니다.

✔ 추가적으로 자동화 테스트를 수행하고 있다면 자동화 테스트 시나리오도 추가적으로 모수에 포함할 수 있습니다.

 

3. 결함 우선순위와 심각도의 정의를 명확히 해야 합니다.

✔ 매뉴얼은 있지만 회사마다 심각도의 차이가 다르기 때문에 '로마에 가면 로마법을 따라야겠죠?'

 

4. 품질 지표를 정량화하기 위해서는 가중치를 적용해야 합니다.

✔ 가중치도 회사의 기준에 맞게 설정하시면 됩니다.

✔ 위에 언급한 가중치의 값은 제 경험에 의한 값이니 참고만 하시길 바랍니다.

 

가끔 받는 질문은 품질을 왜 숫자로 표시해야 하지? 그 숫자가 정말 믿을만한 숫자인가?라는 질문을 받습니다.

 

품질 지표를 정량화하는 이유는 숫자만큼 객관적인 정보가 그 세상 어디에도 없기 때문입니다.

또 다른 이유는 윗분들. 위에 계신 분들은 숫자를 봐야 이해를 할 수 있기 때문입니다.

 

✔ 숫자에 대한 명확한 증거(Evidence)도 존재해야 합니다.

✔ 그게 바로 (테스트 케이스 + 발견한 결함)이 증거가 될 것입니다.

 

사실 품질 지표가 99%이고, Major 한 이슈가 없다고 하더라도 품질이 좋다고는 할 수 없습니다.

"오류 부재의 궤변"에서도 얘기하고 있듯이 사용자가 느끼는 정도가 다르기 때문입니다.

결함이 없다고 해서 품질이 좋다는 것은 아니기 때문인데요.

 

QA가 얘기할 수 있는 "품질이 좋다"는

"고객이 요구한 대로 만들어졌고, Major 한 결함이 없다." 정도로 받아들여지면 해피한 것 같습니다.

 

PS : 꼭 출시하고, 결함이 발생하면 "너네 이것도 안 보고 뭐했어!"라고 말하는 상사 밑에서는 하루빨리 빠져나오시길 바랍니다. 품질의 이해도가 낮다고 생각하시고 배울께 없다고 생각하시고 하루 빨리 탈출하시기 바랍니다.

"그러는 넌 안보고 뭐했냐?"라고 한마디 하시고, 퇴근하세요.

 

혹여나 상사가 테스트 케이스 리뷰도하고, 테스트 케이스에 있는 부분에서 결함이 발생한 거라면 얘기가 다르겠지만요. 마지막 버전에 전체 테스트 케이스를 리그레이션할 수는 없으니까요. 사실 이 부분도 잘 아는 상사라면 저렇게 말하진 않을 거예요.

 

개인적으로 생각하는 진정한 QA의 리더는 소프트웨어 결함은 어디서나 발생할 수 있기 때문에, 완벽한 개발과 테스트는 할 수 없기 때문에, 테스트했냐 안했냐를 따지기보다는 빠르게 원인을 찾고 개발팀을 움직이게 하는 것이라 생각합니다.

 

"다음부터는 더 꼼꼼히 테스트하자."라고 하고,

Lessons & Learned 하는 것이 가장 멋진 상사 아닐까 생각합니다.

 

이 글을 여기까지 읽으셨다면 진정한 QA 리더의 길을 걷고 계시다고 믿겠습니다.

 

---

 

Related References

Severity & Priority in Testing: Differences & Example

요약 : 애자일 프로세스, 프로세스, 프로세스 마이닝, 소프트웨어 qa, 웹 qa, 앱 qa