우선순위에 대한 고찰

AngryQA | 2014-10-20 월요일 오후 5:36 | QA/QA 프로세스 | 원본

QA 전문도가 떨어지는 조직의 특징중에는 이슈에 대한 우선순위를 설정하지 못하는 문제가 있다.

BTS 구축되어 있고 프로세스도 정립되어 있지만, 

TM에게 이슈에 대한 우선순위를 설정하라고 요구하면 아무 생각이 없는 경우가 대다수이다.

"개발자랑 이슈 리뷰 미팅을 통해 결정하죠?" 실제 현장에서 많이 나오는 말일것으로 생각한다.

그래서  

QA 전문도를 높이려면 이슈 우선순위에 대한 가이드를 제시할 수 있어야 하며, 

유능한 TM이라면 이를 통해 이슈의 수정을 이끌어내야 할 것이다.

여기에서는 이슈의 우선순위에 대한 가이드만 간단히 제시하고자 한다.

아래 표를 참조하기 바란다.

우선순위 등급은 A > B > C > D 구분

| |

Always

|

Sometimes

|

Once

| |

 Critical

|

A

|

A

|

A

| |

 Major

|

A

|

A

|

B

| |

 Minor

|

B

|

C

|

C

| |

Trival

|

D

|

D

|

D

|

A : 배포 전 꼭 수정

• 기능 동작 안함
• 치명적인 기능 오동작
• 해당 이슈로 전반적인 테스트가 불가능한 경우 ※ 최우선적으로 처리되어야 할 결함

B : 배포 전 꼭 수정

• 오류로 인해 다음 동작 확인 불가
• 해당 이슈로 일부 기능의 테스트가 불가능한 경우
• 도움말 대로 동작하지 않음

C : 배포 전 수정

(미해결 이슈는 협의 후 진행)

• 오류 발생 하지만 기능 수행 가능
• User에게 발견된 확률이 낮은 문제
• 발생 빈도가 낮고 잘 재현되지 않는 이슈

D : 배포 후 수정 되어도 상관 없음

• 사용자에게 피해를 주지 않는 사소한 Bug

QA 조직이라면 적어도 이정도 객관적인 기준을 가지고 프로젝트을 진행해야 한다고 생각한다.

추가 의견이나 다른 의견은 리플로 제시해주기 바란다 :)

Comments

Once는 크리티컬빼고는 C로 내리는게 좋지않을까요? 매우안정화된 서비스라면 몰라도 수정소요가 오래걸리리라생각합니다

Beenbyoon | 2014-10-20 월요일 오후 5:42

--

표에서는 기준만 제시한거니 프로젝트 성향에 맞게 변경되어 운영해야합니다 :)

일원동 너구리 | 2014-10-20 월요일 오후 5:45

--

이런기준을 어떤 조직에서 사용한다고 해도 결국 TM이 객관적인 자세를 유지해야 하네요

그렇지않으면 "개발자랑 이슈 리뷰 미팅을 통해 결정하죠?" 로 돌아갈 테니까요

맞나요?

Beenbyoon | 2014-10-20 월요일 오후 5:50

--

빙고!

일원동 너구리 | 2014-10-20 월요일 오후 6:0

--

표에 관한 설명은 깔끔하고 나누는 이유가 명확해보입니다 좋은 분류네요

Beenbyoon | 2014-10-20 월요일 오후 5:51

--