고객 사용 전 최종 검증 "QA"
고객이 불편함을 경험 하기 전에 모든 것을 찾아 낸다!
QA (Quality Assurance : 품질보증) 업무는 사용자가 서비스의 오류나 불편함을 발견하여 부정적 경험을 가지기 전에 회사 내부에서 미리 점검, 개선하는 작업으로서 고객 만족, 신뢰를 얻기 위한 아주 중요한 과정입니다.
최근 자사에서 새롭게 론칭 준비중인 서비스의 QA 업무 리딩과 함께 타사 APP 서비스의 QA 컨설팅을 지원 하면서 QA 업무에 대한 각 부서별 입장 차이와 효과적인 QA 업무 방식에 대한 정리가 필요하다고 생각 했습니다.
제조업과 IT 서비스의 QA
약 2년간 자동차 부품 제조업의 QA 를 담당한 적이 있습니다. 원자재 공장에서 소재가 입고 되면 입고된 소재의 품질에 문제는 없는지 사이즈 측정부터 금속 성분 검사까지 하여, 회사 작업자들에게 입고된 제품에 문제가 없다는 품질 보증 하게 됩니다.
회사에서 가공한 제품을 고객사로 납품 하기 전에도 품질 검사를 합니다. 설계 규정대로 가공이 되었는지, 금속 소재의 부식 현상은 없는지, 과도한 오일 작업을 한 것은 아닌지 모두 점검하여 고객사에게 납품한 제품에 문제가 없다는 품질을 보증 합니다.
마지막으로 완성품 제조업에서는 고객에게 제품을 인수 하면서 품질에 문제가 없으며 보증 기간 내 문제 발견 시 교환, 교체, 환불을 해 주겠다는 품질 보증서를 고객에게 발급 하기도 합니다.
IT 서비스의 경우도 고객이 서비스를 사용 하기 전에 문제가 없는지 꼼꼼하게 체크를 해 보아야 합니다.
그런데 IT 서비스의 품질 보증은 제조업의 품질 보증과 다른점은 변수가 무수히 많다 라는 것 입니다.
제조업은 제품의 물질적 특성에 대한 품질이 보증 되지만 IT 서비스는 각 기능을 수행한 행동과 환경에 변수가 있습니다. 어떠한 네트워크 환경에서 어떤 단말로 작업을 수행 하였는지, 특정 버튼을 클릭하기 위한 동선은 어떻게 되는지에 따라 오류가 발견 될 수도 있고 발견 되지 않을 수도 있습니다. 똑같은 행동을 취해도 간헐적 문제가 발생하는 경우도 있습니다.
제조품의 품질 불량이 발견 될 경우 교환으로 대처 할 수 있지만, IT 서비스의 오류는 오류 수정을 해야만 서비스 이용이 가능 하기 때문에 사용자가 서비스의 오류 발견으로 문제 해결을 요청 하였을 때, 침착하고 신속한 대응을 하기 위해서라도 오류 발생 이유를 인지 하고 있어야 합니다. IT 서비스의 QA 는 가능한 많은 경우의 수를 예상하여 테스트케이스를 작성하고, 정상적이지 않은 루트의 행동까지 생각하여 변칙 테스트를 해 보아야 하며 CS 를 담당하는 팀원 일 수록 더욱 꼼꼼한 오류 스터디가 필요합니다.
개발자의 테스트는
정말 미스테리한 현상입니다. 고장난 전자제품도 AS 센터로 방문하면 멀쩡하게 동작 합니다. AS 기사님이 출동하시면 민망할 정도로 제품이 잘 동작합니다. 우리의 서비스도 개발팀 자체 테스트 결과는 문제 없어 본격적인 QA 를 시작 하려면 무수한 오류들이 어렵지 않게 발견 됩니다.
왜 이런식으로 만들어 졌지??
개발, 기획 입장에서 기껏 기획하고 만들었는데 "왜 이런식으로 만들어 졌지?" 소리 들으면 복장 터집니다.
하지만 서비스를 처음 접해보는 다른 팀원 "왜 이런식으로 만들어 졌지?" 라는 의문점이 충분히 들 수 있습니다. 더 중요한 포인트는 고객에게 출시 이후에는 고객으로 부터 "왜 이런식으로 만들어 졌지?" 라는 반응이 들어 온다는 것입니다. 물론 직접 면전에다 "왜 이런식으로 만들었어?" 라고 비 신사적인 언행을 하는 팀원은 없겠지만 고객은 순수하게 궁금한 마음에 직접적으로 물어보기도 합니다.
수많은 논의와 협의를 통해 기능이 정의 되고 서비스가 나왔지만, 과정에 참여 하지 않은 사람은 전혀 알 수가 없습니다. 따라서 QA 과정에서 생긴 의문점은 추후 고객이 질문할 상황의 모의고사라고 생각 할 수 있습니다. 물론 그 과정에서 심각한 문제를 발견하거나 논의, 협의중 인지하지 못한 상황을 발견할 수도 있습니다.
왜 이런 식으로 만들어 졌지? 라는 의문은 열린 마음으로 건의 사항 접수를 받고 재 논의할 준비가 필요합니다. 단 건의 사항은 예의를 갖춰 의견 제시 하는 것이 좋습니다.
효과 적인 QA 운영
그럼 QA 업무는 어떻게 진행해야 품질 보증이라는 목적에 맞게 운영 할 수 있을까요?
무엇보다 기획대로 구현이 되었고 오류 없이 동작 하는가? 에 초점을 맞춰서 진행 하는 것이 좋습니다.
사람마다 경험치가 다르기 때문에 똑같은 기능을 오류 또는 문제 없음으로 다르게 판단 하기도 합니다.
예를 들어 APP 서비스의 프로필 이미지를 설정 할 때 카메라 실행과 갤러리에서 선택 옵션을 제공하는 것과
프로필 이미지 선택은 당연히 갤러리만 제공하면 된다는 사용자 경험이 다를 수 있습니다.
이 와 같은 이슈들의 통과 여부의 기준점이 되어 주는 것이 "기획서" 입니다.
회사 마다 다르지만 QA 부서가 있는 곳도 있고, 기획자가 QA 까지 관리하거나, 단발성으로 QA 업무를 맡아서 관리하는 팀원이 있거나, QA 를 외주로 진행하는 경우도 많습니다. 어떠한 경우든 QA 를 총괄 하는 쪽에서 어떤 방식으로 테스트를 진행 할 것인지 "기획서 & 최종디자인" 을 기반으로 테스트 케이스를 작성하게 됩니다.
테스트 단계의 서비스가 만들어지기 까지 관련 부서의 수많은 티키타카가 있었을 것입니다.
고객의 요구사항을 대변하는 부서에서의 기능 요구사항과 기술팀의 개발 가능성과 개발 기간, 전략팀의 론칭 목표 일정, 기획팀과 디자인팀의 기능 정의와 UX/UI 설계 과정에서 수많은 의문점과 협의점이 발생되고 조율하게 됩니다.
수많은 논의 끝에 정리된 기획서라 할지라도, 기획 과정에 불참한 사람에게는 의문 투성이 입니다.
