18 QA(Quality Assurance)
체크 리스트와 디버깅
화면설계서 작성이 끝나면 WBS 일정에 따라 디자인, 퍼블리싱 그리고 개발이 진행됩니다. PM은 이 일정대로 잘 진행되고 있는지 보통 일주일 단위로 체크합니다. 그 과정 가운데 수많은 이슈들이 발생하기 마련이고 그래서 정책과 기획서 수정 작업은 기본이며, 개발 단계까지 갔을 경우 디자인 수정을 해야 할 때도 비일비재합니다. 이런 일이 반복적으로 일어나면 기획, 디자인, 퍼블리싱, 개발 파트 모두 지치기 쉬운데 이때 진정한 협업이란 무엇인지 절실히 깨닫게 되고, 때론 누군가의 인성도 다시 보게 되는 시기입니다.
온갖 언쟁과 후회를 하기보다는 두 번 다시 이런 시행착오를 겪지 않기 위해 프로젝트 완료 후 Lesson learned 시간을 갖도록 하고 이를 대비해 미리 정리해 두는 것도 방법입니다.
개발 막바지 무렵 또는 대형 프로젝트인 경우 부분적으로 기능 개발이 완료되었을 때 부분적인 단위 테스트를 통해 디버깅을 시작하고, 개발 완료 시점에 전체적인 통합 테스트에 들어가는데 이를 보통 QA라 지칭합니다.
QA를 하기 위하여 체크 리스트를 작성합니다. 위에서 언급한 대로 수많은 이슈들을 끊임없이 대응해 나가며 체크 리스트도 작성해야 하는데 화면 설계서 우측에 작성한 설명(주로 기능에 대한 정책)에 입각해 최대한 세분화하여 꼼꼼하게 작성하며, 주로 엑셀이나 구글 스프레드 시트를 이용합니다. 이 시점에서 샘플 링크를 하긴 하는데 한국판 QA 체크 리스트가 없고, 제가 원하는 포맷도 잘 안 보이네요;
IA처럼 depth 구분을 먼저 해주고 해당 페이지에서 정책상 정상적으로 어떻게 작동해야 하는지를 기능 위주의 질문형 문장으로 작성하는데 예를 들면 아래와 같습니다.
- 폰번호 형식으로 미입력시 잘 못 입력했다는 alert이 뜹니까?
- 인증번호 전송 클릭 시 인증번호를 발송했다는 alert이 뜹니까?
- 인증번호 입력 후 확인 클릭 시 맞는 경우 인증이 완료되었다는 alert이 뜹니까?
- 인증이 완료된 경우 다음 버튼 클릭 시 해당 페이지로 이동합니까?
- 인증번호 입력 시 오류인 경우 틀렸다는 alert이 뜹니까?
- 10번 이상 오류 시 더 이상 입력이 불가하며, 다시 인증하라는 alert이 뜹니까?
- 인증번호 전송 100번 이상 클릭 시 더 이상 인증이 불가하며 고객센터로 연락하라는 alert이 뜹니까?
위 내용은 모두 폰번호 인증 시 발생할 수 있는 경우의 수에 대해 상세 기획서 설명란에 명시한 정책들이며 이에 의거해 개발된 사항들이기 때문에 QA를 통해 전부 테스트를 해봐야 합니다. 여기서 인증번호 전송 100번 이상 클릭 시 발생하는 alert은 101번 전송을 하진 않고, 특정 테스트 ID를 100번 클릭한 상태 값으로 개발자에게 미리 요청하여 진행합니다. 참고로 저도 인증번호 전송을 100번 이상 직접 해본 적은 없지만 위와 같이 제한을 두는 이유는 건당 비용이 발생하기 때문이며, 누가 100번 이상 발송하나 싶지만 실제 그런 사람들이 이 세상에 존재하고 있습니다.
이 외, 로그인 전 상태와 로그인 후 상태에서 User가 진행하는 플로우에 따라, 구매자와 판매자에 따라, 정회원과 준회원에 따라, 장바구니에만 넣은 User와 구매하기까지 클릭한 User에 따라, 닉네임을 입력한 User와 그렇지 않은 User에 따라 경우의 수가 다 나뉘기 때문에 각각 그에 맞는 체크 리스트를 작성해야 합니다.
위 항목들 우측 셀에 각 중요도를 보통 critical, normal, low로 표기하고, 비중에 따른 차등 점수를 두어 QA 결과 점수는 보통 %로 나오게 됩니다. 100%는 모두 pass한 경우로 오픈에 완벽한 경우겠지요. 그래서 오픈 예상일이 코 앞인데 low 항목이 몇 개 나온 경우 우선 오픈 후 처리하기도 하고, critical이 한 개라도 나오면 주요 기능에 영향을 주는 요소인 만큼 오픈일을 미뤄서라도 수정 후 오픈해야 합니다.
중요도 옆엔 원하는 결과를 적습니다. '인증번호 전송 클릭 시 인증번호를 발송했다는 alert이 뜹니까?'인 경우 '인증번호가 전송되었습니다. 전송된 인증번호를 입력해 주세요.'라는 alert이 떠야 한다.를 결과로 작성합니다.
여기서 QA 테스터인 경우 QA를 시작하기 전에 작성해야 할 부분이 있습니다.디바이스(PC, 태블릿, 폰 등), OA(Windows 10, Mac10.14.13, Android 오레오, iOS 12.1.2 등), 브라우저(IE, 크롬, 사파리, 파이어폭스 등 그리고 ver.)를 먼저 기입해서 어떤 환경에서 테스트했는지를 명시해야 추후 오류 수정 시간을 단축시킬 수 있습니다. 크롬에서는 잘 되는데 IE(Internet Explorer)에서만 안 된다던지, IE11에서는 잘 되는데 IE9에서는 안 된다던지 하는 경우가 매우 많이 발생합니다. 다양한 디바이스와 환경이 도래해 사용성은 편리해졌지만 테스트 시간은 그만큼 몇 배로 늘어났다고 봐야 하지요.
여기서 중요한 사전 결정 사항을 알려 드리자면 요즘엔 주로 App.으로 서비스 출시를 많이 하는데 App.도 OS가 다양하며 그에 따른 버전이 천차만별입니다. iOS 환경을 예로 들면 App. 다운로드 시 'iOS 9.0 버전 이상 필요. iPhone, iPad, iWatch와 호환' 이런 글을 보셨을 것입니다. Android 역시 마시멜로, 롤리팝, 오레오 등 재밌게(?) 이름을 붙여 버전 업그레이드를 하고 있지요. 즉, 어떤 디바이스부터(까지) 지원할 것인지, 어떤 OS부터 지원할 것인지, 버전을 어디부터지 지원할 것인지 그리고 해상도를 어느 기준에 맞출 것인지에 따라 기획, 디자인, 개발 요소 모든 범위가 달라집니다. 그래서 기획 작성 전에 이 부분은 각 파트 협의하에 명확히 정의해 두고 시작하는 것이 필요합니다.
다시 QA 체크리스트 작성 시점으로 돌아와 원하는 결과 입력 우측 셀에 pass 그리고 fail 칸을 만든 후 테스터 의견 란을 만들어 fail인 경우 그 증상을 적을 수 있도록 하고, 필요시 그곳에 캡처한 오류 현상 이미지를 업로드할 수 있도록 합니다. 그리고 그 우측에 개발자 피드백 란을 만들어 fail인 케이스 디버깅 후 또는 이견이 있을 경우 피드백할 수 있도록 하고, 그 피드백을 보고 테스터가 테스트 후에도 오류가 날 경우 계속해서 우측에 다시 의견을 입력하여 커뮤니케이션을 하게 됩니다.
또는 이전에 언급한 협업 도구들 가운데 레드마인, 위키, 구글 스프레드 시트를 통해 그곳에서 오류 사항을 등록하고, 중요도(critial, normal, low)와 상태 값 변경(요청, 해결, 완료) 그리고 작업 또는 확인해야 할 담당자 지정(기획자, 테스터, 디자이너, 개발자 등)을 위한 알림 Email을 통해 커뮤니케이션하기도 합니다.
예전엔 QA를 진행하면서 많이 짜증 날 때가 있었는데 이미지 업로드해야 하는 곳에 온갖 특수문자 내지 스크립트를 입력하여 즉, 일반적이지 않는 케이스로 오류를 만들어 fail로 처리하는 경우가 엄청 많았습니다. 요즘엔 '보안 취약점 진단'이라는 별도 전문가들의 작업이 병행되어 해킹에 대비한 취약점 진단으로 사전 대응하기도 합니다.
QA는 1차에서 큰 프로젝트인 경우 3차까지 가기도 합니다. 횟수가 중요한 게 아니라 얼마만큼 디버깅해서 오픈에 이슈가 없는지 체크하는 데 목적이 있습니다. 1차에서 99%라면 굳이 2차까지 갈 필요는 없겠지요.(개발자님 만세!) 개인적으로 QA와 오픈 작업을 할 때 가장 많은 야근, 주말, 밤샘 작업을 해서 참 고되었습니다.(이 역시 저 혼자 발만 동동 구르는 상황일 때가 힘겹지, 다 같이 함께 협업할 땐 힘이 나고 생각해 보면 그랬던 서비스들이 다 성공했습니다. 다시 말하면 안 그럴 때도 많았다는 이야기입니다.)
이 시점까지 왔다면 오픈하기까지의 과정이 결코 녹록지 않다는 것을 잘 아실 것입니다.
성공 여부를 떠나 이 시점까지 왔다는 그 자체만으로 큰 보람이고, 본인의 자랑스러운 커리어가 될 것입니다.
드디어 해냈다고 본인 스스로에게 큰 칭찬을 해주셔도 됩니다.
프로젝트의 모든 것을 잘 견디고 잘 버티셨습니다.
서비스 기획자가 걷는 길입니다.
