정말 이렇게 QA하는 게 최선인 건가?
Last updated
Last updated
첫 출근 날, 호기롭게 사무실에 도착했지만, 같은 팀으로 배정된 우리는 사실 무엇을 해야할지 감을 잡을 수 없었다. '3개월 안에 새로운 프로덕트의 시장성을 검증해야한다' 그리고 '그것은 QA에 대한 것이다'라는 두 가지 전달사항 외에는 아무 가이드가 없었기 때문이었다. 그리고 가장 큰 문제는 우리 모두가 QA를 잘 모른다는 것이었다. 작게나마 QA를 해봤던 나는 QA는 정말 불편하다, 정말 귀찮다, 정말 번거롭다 정도의 생각만 가진 상태였다. 그야말로 무기를 제대로 쥘 줄도 모르는 오합지졸들이 싸움에 나가겠다고 모인 느낌이었다.
우리한테는 북극성이 필요했다. 이러나 저러나 이건 문제가 맞다라는 확실한 북극성 말이다. 그렇게 우리는 QA에 대한 조사를 시작했다. 국내와 해외에 나와있는 QA툴들을 조사하고, QA 엔지니어분들이 작성한 아티클들을 살펴봤다. 또 한편으로는 내가 QA를 하면서 겪었던 과정을 떠올려봤다.
처음엔 나름의 규칙에 맞게 작성하던 QA시트는 결국은 설명을 이해할 수 없어 무용지물이 되었고, 이미지와 영상으로 보여줘야 이해가 되곤 했기 때문에 카톡이나 슬랙, 나아가서는 화면 공유로 실시간으로 버그를 보여주곤 했다. '제 컴퓨터에서는 문제가 없는데요'라는 말이 빈번하게 나올만큼, 버그는 그야말로 백문이 불여일견인 친구였다. 이렇게 고객분들이 느낄 문제 상황을 리스트업하다보니 테스트 전 / 중 / 후 단계별로 문제를 꼽을 수 있었다. 하지만 여기까지는 완전히 우리의 추측들이었고, 이제부터는 검증이 필요했다.
지금까지의 문제는 모두 가설이었기 때문에, 테스트가 필요했다. 그리고 그 중심에는 린스타트업이 있었다. 부트캠프를 통해 많이 배웠다고 생각했지만, 막상 새로운 프로덕트를 만드는 일에 적용하려니 너무 거추장스럽게 복잡한 문서들뿐이었다. 가장 간단하게, 가장 작게 모든 내용을 확인할 수 있는 기획안이 필요했고, 가장 적합한 게 린캔버스였다.
린캔버스는 문제부터 고객, 제품, BM까지 한 눈에 볼 수 있는 가장 업데이트가 쉬운 기획안이라고 생각한다. 문서를 작성하고 업데이트하고 정리하는 것도 일이기 때문에, 리소스가 매우 부족한 초기 팀에게 가장 적합한 방법이다. 그렇게 제품과 시장과 고객에 대한 가설을 세운 우리는, 제품부터 테스트를 해나가기로 했다. 그렇게 우리는 우리의 문제 가설을 정리하고, 가설을 테스트하기 위한 인터뷰를 준비했다. 출근 첫날의 일이었다.
이튿날, 우리는 사내 PM, 디자이너, 개발자 직군을 통틀어 총 9분을 인터뷰했다. 아침 10시 반부터 오후 5시 반까지 정신 없이 인터뷰를 진행하고, 짧게 배운 점을 정리했는데 놀라운 점은 인터뷰를 한분 한분 해나갈 때마다, 점점 교집합이 생기고 자연스럽게 정리가 된다는 점이었다. 그리고 다행스럽게도 모든 분들이 QA에서의 불편함을 토로하시며, 현재의 번거로운 QA 과정을 직접 설명해주셨다. (물론, 고객이 '불편하다', '있으면 무조건 쓸 것 같다'는 말을 절대 다 믿어서는 안된다는 것은 나중에 제대로 알게되었다.)
인터뷰 결과 요약도 린스타트업의 예시를 참고해 작성했다. QAing이 서비스를 종료하고 회고를 작성하는 지금 이 문서를 보면서 놀라운 점은, 이후 작성한 복잡한 기획안들보다 이 글이 더 핵심만 잘 짚어내고 있다는 것이다. 그만큼 인터뷰를 막 끝냈을 때 고객분들이 공통적으로 이야기하는 지점을 짚어내는 것이 중요하다는 생각이 든다. 그렇게 문제 인터뷰로 문제를 짚어낸 우리는 우리가 고객들에게 제공하고 싶은 UVP로 넘어가게 된다.
우리의 고객분들은 QA를 하시면서 '정말 이렇게 QA하는 게 최선인 건가?', '에이 설마, 뭔가 더 좋은 방법이 있겠지!'라는 생각을 하고 계셨고, 우리는 이 불편함을 해결해 고객에게 완전히 다른 QA 경험을 주고자 했다. UVP(고유 가치 제안)는 결국 현재 고객의 문제를 가장 극적으로 해결해 제공할 수 있는 가치가 무엇인가 하는 것이었다.
우리는 QA 과정 중 버그를 재연하기 어렵다는 점에 집중했다. 일단 버그가 정말 버그인가를 확인하기 위해서는 재연이 필요했는데, 이때 문제는 재연하기 어려운 버그가 많다는 것이었다. 그렇다면, 버그를 재연하지 않고서도 영상으로 버그 리포팅을 할 수 있다면? 재연없는 QA를 제공할 수 있지 않을까?라는 아이디어에서 UVP는 재연없는 QA으로 구체화하고 린캔버스를 업데이트했다.
이제 우리가 생각하는 솔루션을 프로토타입으로 만들어 솔루션 검증을 진행할 차례였다. QA라는 업무 특성상 여러 브라우저를 지원해야 하지만, 기술적 한계로 인해 우선 크롬 브라우저에 대해 크롬 익스텐션 형태로 제공하는 것을 전제로 했다. 그래서 솔루션 프로토타입으로 크롬 브라우저에서 구동할 수 있는 크롬 익스텐션으로 내용을 구성했다. 피그마로 만든 프로토타입은 최대한 실제와 비슷하게 동작할 수 있도록 구성하려고 했다. 그렇게 솔루션 프로토타입과 함께 10명 가량의 고객과 인터뷰를 진행했다.
처음 뾰족하게 구체화한 문제를 가지고 프로토타입을 만들었고, 이를 토대로 또다시 솔루션 인터뷰를 진행했다. 하지만 우리의 예상과는 달리, 두 가지의 공통적인 피드백이 나왔는데 하나는 '버그를 저장하면 QA시트 툴에 자동으로 연동이 되었으면 좋겠다'는 것이었고, 다른 하나는 'QAing 내에서 QA 시트까지 한번에 작성할 수 있으면 좋겠다'는 것이었다.
솔루션을 구체화해나가던 우리는 고민에 빠지게 되었다. 우리 서비스가 가치를 가지려면 둘 중 하나가 같이 제공이 되어야하는 것일까? 그전에는 가치가 없는 것일까? 그럼 우리의 최소 기능 제품 MVP의 스펙의 범위가 넓어져야 하는 것일까?
그리고 이것을 고민하던 시점에서 대표님께 간단한 진행상황 공유를 위한 미팅을 진행하게 된다.
