기획자와 QA
QA는 Quality Assurance의 약자로서 개발 후 운영서버에 배포하기 전 기획에 맞게 개발되었는지 검증하는 행위를 말합니다. 규모가 큰 업체나 프로젝트의 중요성이 높은 경우 전문 QA를 두어 위와 같은 작업을 수행하는 경우도 있으나, 일반적으로 스타트업에서는 개발 단계에서 개발자가 1차 QA를 진행한 후, 배포 전 단계에서 기획자가 최종 QA를 진행하곤 합니다. 만약 사이트 리뉴얼 등 규모가 큰 프로젝트를 진행할 경우 사업부서 각 담당자가 테스트에 참여하는 3차 QA까지 진행을 하는 경우도 있습니다.
그렇다면 QA는 왜 중요한 걸까요?
1. 서비스 신뢰도 이슈: QA를 통해 문제를 걸러내지 못한 상태에서 배포가 완료된 후 서비스 이용자가 사이트나 앱을 이용하며 문제를 발견하게 되면 그 자체로 서비스의 신뢰도가 낮아지는 문제가 생깁니다. 쉽게 예를 들어 네이버라는 포털 사이트를 이용하는데 페이지마다 오타가 존재한다면 이 사이트에 대한 믿음을 갖기가 어렵겠죠. 서비스 신뢰도를 유지하는 것은 무척 중요한데, 이는 사이트 추가 유입 (지인 추천: referral)과도 관련이 있기 때문입니다. 자신이 사용하기 망설여지는 서비스를 친한 지인에게 추천하지는 않겠죠.
2. 서비스 이탈 방지: 기능을 올바르게 구현하여 사용자 전환 프로세스에서의 이탈을 막아야 합니다. 어떻게 보면 1번과 유사한 내용이라고도 볼 수 있습니다. 특히 결제 등 돈과 관련된 부분의 QA는 매우 신중하고 반복적으로 수행되어야 합니다. 더군다나 그 결제가 오프라인 디바이스 (예를 들어 스와이프형 단말기)와 연결되어 있다면 더욱 신경을 많이 써야 합니다. 결제 부분에서 문제가 발생하면 이용자가 느끼는 문제는 단순 기능 오류보다 훨씬 더 심각할 수 있습니다.
예를 들어 이런 경우가 있었습니다. 배달 서비스를 운영하던 시절인데, 배달 기사가 고객의 집에 방문하여 음식을 전달하고 카드 결제를 위해 앱을 실행한 후 스마트폰 이어폰 단자에 스와이프 단말기를 꼽아 카드 결제를 해야 하는데 계속 카드 인식 오류가 발생하는 겁니다. 그래서 결국 카드 결제를 포기하고 고객에게 양해를 구해 현금결제를 했던 적이 있었습니다. 문제는 이런 경우가 10번당 1~2번 꼴로 지속적으로 나타났다는 점이죠. 우리와 함께하는 배달업체 사장님 입장에서는 굉장히 황당한 일이었을 겁니다.
실제로 스타트업에서는 이런 기본적인 부분에서 문제가 생기는 경우가 종종 있습니다. 대기업이나 규모가 있는 회사에서 근무를 하다 처음 스타트업으로 합류하게 되면 이런 부분에서 굉장히 당황할 수 있습니다. 하지만 이런 부분은 스타트업에서 종종 일어날 수 있는 부분이기에 침착하게 잘 대응하시는 것이 중요합니다. 이 문제를 근본적으로 어떻게 바꾸어 나가야 할지 팀원들과 잘 상의하여 대비책을 마련해두셔야겠죠.
그럼 이제 본격적으로 QA 방법에 대해서 이야기해보도록 하겠습니다. 먼저 말씀드릴 부분은 QA 체크 포인트입니다. 어떤 부분에 초점을 맞추어 QA를 진행해야 되는지 알아보겠습니다.
1. 기능성: 너무나 당연하게도 기획자가 의도한 기능들이 올바르게 작동하는지 검증해야 합니다. A를 클릭했을 때 올바르게 출력되는지, A에서 B로 올바르게 이동하고 있는지 각 사용 시나리오에 맞게 기능적인 측면에서 잘 작동되는지 모든 부분을 확인해야 합니다.
2. 심미성: 오탈자가 있는지, 이미지에 문제가 있지는 않은지 검증해야 합니다. 저는 오탈자 문제를 매우 중요하게 생각합니다. 이런 사소한 부분이 이용자의 무의식에 영향을 미친다고 보고 있습니다. 하다못해 신문기사를 볼 때 오탈자가 계속 발견되거나 썸남썸녀끼리 문자를 주고받을 때 상대방이 계속 맞춤법을 틀리거나 하면 어떤 생각이 드시나요? 그때 받으셨던 느낌과 사이트를 이용할 때 받으시는 느낌이 결코 차이가 나지는 않을 겁니다.
3. 호환성: 기능성, 심미성에서 서술한 부분은 호환성을 전제로 합니다.
- 디바이스별(스마트폰이라면 기종별로)
- OS별(스마트폰이라면 IOS, 안드로이드)
- 버전별 (안드로이드 버전, IE 버전 등)
- 브라우저별 (구글 크롬, 마이크로소프트 IE)
- 회원 유형별(비회원, 정회원 1, 정회원 2)
등 다양한 형태에서 동일한 모습의 산출물을 기대할 수 있어야 합니다. 특히 사이트 리뉴얼 등의 규모가 큰 프로젝트에서는 그 중요성이 더 커집니다.
QA를 실행하는 방법에는 여러 가지가 있을 수 있는데요. 저는 두 가지만 소개하도록 하겠습니다.
1. Formal 한 방법: 에이젼시 등에서 주로 활용하는 방법으로 단위 테스트, 통합 테스트를 실행하여 QA를 진행하는 방법이 있습니다. 여러 명이서 협업하여 체계적으로 QA를 진행할 때 이용하는 방법입니다. 단위 테스트, 통합 테스트 각 엑셀 시트를 만들어서 여러 명이 구간을 나누어 QA를 진행합니다. 단위 테스트는 각 페이지별 개별 요소 기능이 올바르게 작동되는지에 대해 초점이 맞추어져 있으며, (출력 여부, 링크 이동 여부, 기타 기능 검증) 통합 테스트는 task 수행 시나리오를 기준으로 전체적으로 사이트 UX를 검증하는데 초점이 맞추어져 있습니다. 아니면 단순히 단위 테스트를 합친 것을 통합 테스트로 이해하셔도 무방합니다.
2. Informal 한 방법(제가 주로 사용하는 방법): 저는 스타트업에서 일하면서 단위 테스트, 통합 테스트 등으로 QA작업을 진행하진 않습니다. 좀 더 빠르고 간편하게 할 수 있는 방법을 찾아 일을 하고 있습니다. 일단 모니터 2대가 준비물입니다. 한 모니터에는 개발자가 개발서버에서 구축한 결과물을 표시해두고, 다른 모니터에는 제가 작성한 기획서와 QA 문서를 올려둡니다. 먼저 기획서는 첫 장부터 읽어가면서 제가 작성한 디스크립션 대로 개발 산출물을 모두 실행해가면서 검증합니다. 문제가 생기는 부분이 있으면 QA 문서를 열어서 간단하게 어떤 부분이 문제가 있는지 적어둡니다.
이때 단순한 이슈를 제외하고는 가급적 ‘재연 시나리오’를 명시해 두는 것이 좋습니다. 예를 들면 이런 식이죠. “abcd ID로 접속해서 이런저런 행위를 했을 때 이런 결과물이 출력되고 있다. 이런 에러 창이 출력되고 있다”라는 식으로 QA문서에 적어두면, 개발자도 원인을 빠르게 찾아낼 수 있고 정확한 QA 진행이 가능하여 모두의 시간을 단축시켜줄 수 있습니다.
이런 식으로 문서를 여러 번 주고받은 후 최종 배포 전 자유롭게(랜덤하게) 이 기능 저 기능을 시행해봅니다. 혹시 모를 의외의 포인트에서 문제가 발생할 수 있는지 검증하기 위함입니다. 이렇게 하면 모든 QA가 종료됩니다. 물론, 1번에서 서술한 단위 테스트, 통합 테스트의 경우처럼 모든 가능한 경우를 예시로 쭉 풀고 하나하나 꼼꼼히 검증하는 것보다는 문제가 생길 여지가 있지만, 대체로 이런 식으로 QA를 진행해도 현재까지는 큰 문제점을 발견하지 못했습니다.
QA도 기획, 개발 못지않게 매우 중요한 업무 프로세스 중 하나입니다. 잘못된 QA는 서비스 신뢰도에 바로 악영향을 주기 때문이죠. QA에서 못 걸러낸 문제 하나가 사용자가 이탈하고 전환율이 떨어지며 부정적인 바이럴이 발생하게 되는 원인이 됩니다. 하지만 일반적으로 작은 스타트업에서 기획자가 혼자 QA를 진행할 때 모든 경우의 수를 고려해가며 매번 QA를 진행하게 되면 아마 쉽게 지치게 될 것입니다. 최소 요구 사항을 만족하면서 효율적으로 QA를 진행할 수 있는 방법을 조직 내에서 각자 고민해보시는 것이 좋겠습니다.
다음 시간에는 배포 후 사후관리에 대해서 이야기해보도록 하겠습니다.
읽어주셔서 감사합니다.
