[회고] QA 중 기억할 것

 

 

이제 정말 iOS 앱 출시가 눈앞에 있다.

한 달 이상의 QA 기간을 거치면서 느꼈던 점을 정리해보려고 한다.

 

QA Table or Board는 필수

QA팀과 개발팀이 실시간으로 이슈를 공유할 수 있는 QA board 또는 table은 필수다.

 

QA table에 필요한 칼럼으로는

- QA 종류(디자인, 기능)

- 이슈 작성일(또는 이슈를 발견한 QA의 회차)

- 작업 상황

- 확인 기기

- 작업 책임자

- 예상 작업 시간

등이 있다.

 

이를 board로 표현해서 볼 때, 주로 작업 상황을 기준으로 본다.

작업 상황은 

- Opened

- Assigned

- Resolved

- Closed

- Afterjob

- 기획 논의 필요

- 재현 불가

등이 있다.

 

 

QA 항목의 중요도 정하기

시간의 제약이 있기 때문에 QA팀은 개발팀에게 QA 리스트를 전달할 때, 각 항목의 중요도를 꼭 표시해야 한다.

중요도는 

- P1 : 수정되지 않으면, 릴리즈 할 수 없는 이슈

- P2 : 릴리즈는 가능하지만 사용자에게 크게 불편한 이슈

- P3 : 크게 불편하진 않지만 수정되어야 할 이슈

- P4 : 수정되어야 할 이슈이긴 하지만 중요도가 높지 않아서 시간이 부족하다면 Afterjob으로 넘길 수 있는 이슈

등으로 나눌 수 있다.

 

 

정확한 QA의 회차, 기간 픽스하기

QA팀과 개발팀이 소통할 때, QA의 회차와 기간이 픽스되지 않으면 의사소통에 큰 어려움이 생긴다.

1st QA에 정확한 기간을 두고 QA를 진행하고, QA팀이 이슈를 개발팀에게 전달하고, 개발팀이 해당 이슈들을 해결하거나 논의하고, 2st QA로 넘어가야 한다. 

이런 구분이 정확히 되지 않으면 버전마다 바뀌는 이슈들을 정확히 찾기 어렵다.

물론, 시간 또는 인력이 부족한 상황에서는 QA의 회차를 정확히 분리하기 어려울 수 있다.

병렬적으로 QA 이슈 발견과 해결이 이루어지고 있는 상황일수록, 정확히 이슈 발견 날짜와 시간과 이슈 해결 날짜와 시간을 명시하여 공유하도록 하자.

 

 

서로에게 감사하기

QA는 QA팀에게도, 개발팀에게도 아주 고통스러운 일이다.

QA팀은 여러 기기에서 여러 가지 상황을 시도하면서 발생할 수 있는 문제를 찾으며 하루 종일 화면을 보면서 지쳐있다.

개발팀은 매 회차마다 새롭게 생겨나는 이슈들을 빠르게 해결하면서 다른 이슈를 만들지 않도록 하기 위해 하루 종일 불타고 있다.

그렇기 때문에 서로에게 까칠해질 수도 있지만, QA팀도 개발팀도 하나의 목표를 위해 각자의 일을 하고 있는 중이라는 것을, 모두가 고통받고 있다는 것을 명심하자.

서로에게 감사하는 마음을 되새기자.

 

 

해결 방법을 서로 제안하며 타협해나가기

시간 또는 인력의 부족으로 이슈를 해결하는데 어려운 상황이 올 수 있다.

그럴 땐 QA팀과 개발팀이 가깝게 소통을 하면서 다양한 시각으로 여러 해결 방법을 제안해보면서 타협하는 것이 좋다.

 

 

 

기획을 다시 보기

QA를 오래 진행하다 보면, 눈에 띄는 이슈를 해결하는 것에 매몰될 수 있다.

그럴 때에는 기획을 다시 되새기자.