brunch

You can make anything
by writing

C.S.Lewis

by 큐에잉 Feb 03. 2024

QA의 네 가지 규칙

팀큐에잉 PO의 QA 철학

안녕하세요 팀큐에잉의 PO 노엘입니다!

큐에잉은 MVP를 출시한 후 매주 꾸준히 업데이트를 하고 있는데요. 

그 말은 곧 QA 또한 매주 진행을 하고 있다고 할 수 있습니다! 


서비스를 처음 기획하기 시작한 뒤부터 지금까지 점점 QA의 빈도와 복잡도가 높아지고 있는데요.

서비스의 기능이 늘어나고 복잡도가 높아질수록 QA의 복잡도도 함께 올라가는 상황을 몸소 경험하고 있습니다. 


규모가 큰 기업의 경우에는 QA 팀을 별도로 두어 서비스 품질과 관련한 업무를 집중적으로 관리하는데요.

서비스의 기획 단계부터 개발 진행과정, 서비스 배포 전 기능 검사와 성능 검사까지, 유저에게 더 안정적이고 좋은 서비스를 제공하기 위해 꼼꼼하게 품질을 관리해요.


하지만 규모가 작거나 MVP로 빠르게 시장 테스트를 하며 PMF를 찾아야 하는 저희 팀큐에잉과 같은 조직은 QA 관리를 따로 관리할 수는 없는 상황이고, QA를 관리할 담당자를 따로 두기 어려운 상황입니다.


그렇다고 언제까지나 QA 관리를 생략하거나 대충 할 수는 없는 노릇이죠. QA는 번거로운 과정이지만 유저가 우리 서비스를 잘 사용할 수 있도록 하는 데 꼭 필수적인 과정이기도 하니까요. 


그러다 보니 어느정도 방향이 정해지고 5명 이상의 팀 구성이 맞춰지면 PO/PM 역할을 하는 분이나 기획팀, 운영팀 등에서 QA 업무를 병행해 관리하기도 해요.


저도 PO로서 책임감을 가지고 늘 QA를 꼼꼼하게 진행하려고 해요!

특히나 QA를 돕는 서비스를 만들고 있는 만큼, 더욱 철저한 QA를 진행하고 있습니다! 

제가 느낀 QA와 관련된 아주 기초적인 철학을 공유해보려 해요!




QA의 네가지 철학


1. 일부 기능만 업데이트되더라도, 전체 서비스 이용 동선의 필수 기능 테스트는 꼭 포함한다.

업데이트되는 기능을 분명히 테스트하고 문제 없이 출시까지 완료했는데, 너무 뜬금 없는 부분에서 오류가 발견되는 경험을 하신 적 있지 않으신가요? 저는 큐에잉을 만들면서 이런 순간이 꽤 있었던 것 같아요.

전혀 관련이 없다고 생각한 기능에서 예상치 못한 오류를 발견하게 되면, 그것도 배포한 이후라면 문제가 되죠. 

그래서 저희 팀큐에잉은 특정 기능만 업데이트 되더라도, 서비스의 핵심 기능들은 모두 필수로 함께 테스트를 진행해요. 그렇게 하면 예상하지 못한 부분에서 오류가 발생할 확률을 낮출 수 있게 됩니다! 


2. Happy Path Testing은 CBT(Closed Beta Test) 때만 적용한다.

CBT 때는 정상 동작을 한다는 전제 하에 서비스의 효용 가치와 UX적인 보완점을 찾는 것이 주 목적이고,

OBT(Open Beta Test)부터는 마케팅을 통한 수요 검증과 실사용에 대한 피드백을 받는 것이 주요한 목적이라고 생각해요.

즉, 베타 서비스는 Happy Path 외에도 자주 발생할 만한 경로의 오류를 검증한 뒤에 출시를 해야 해요.

당연한 말이지만, 모든 유저가 저희가 원하는 Happy Path대로만 서비스를 이용하지는 않죠. 유저가 서비스를 이용할 만한 다양한 상황과 경로를 고려해 그 과정에서 자주 발생할 수 있을 만한 오류를 반드시 체크하는 것도 중요합니다!


3. 고객과 최접점에 있는 담당자는 모두 배포 전 QA에 참여한다!

저희 팀큐에잉의 룰과 같은데요 ㅎㅎ 저희는 특정 기능 개발이 완료되면 배포 전 QA를 디자이너, 개발자분들과 다 함께 진행해요. 여러 환경에서 테스트를 하는 것도 중요하기 때문에 최대한 모든 팀원이 참여할 수 있도록 하고 있어요. 

뿐만 아니라 모두가 QA에 참여하면서 배포될 신규 기능을 더 빠르고 정확하게 익힐 수도 있습니다! 우리가 기획하고 코드로 구현한 그 기능이 정확히 어떤 방식으로 동작하는지, 어떻게 보여지는지 직접 사용해 보아야 더 잘 이해할 수 있어요. 우리 서비스의 기능 하나하나에 대해 파악하는 것은 PO, 디자이너, 개발자 모두의 몫이기도 하니까요! 또 세일즈를 하거나 정확한 CS 응대를 위해서도, 자신의 서비스 업데이트 기능에 대해서 잘 알고 있어야겠죠?


4. QA 관리가 어렵고 번거롭지 않아야 한다.

QA 테스트를 위해 엑셀로 항목을 정리하고, 테스트 케이스를 적고..또 참여자들은 작성된 엑셀 시트를 보면서 '이게 무슨 말인가' 해석하면서 테스트하고.. 이런 식으로 QA 과정이 복잡하면 지속적으로 잘 관리하기가 어려워지는 것 같아요.

고객 최접점 담당자들인 우리 팀원들이 쉽게 QA에 참여하고 테스트할 수 있어야 한다고 생각해요. 팀원들이 꾸준히 양질의 QA를 진행하고, 본업무에도 지장이 가지 않도록 효율적인 QA 프로세스를 구축하는 것이 어려운 일이지만 아주 중요한 것 같아요.

그리고 그 과정에서 이미지, 영상이 큰 도움이 되는데요! 평소라면 이미지와 영상을 캡처하고 녹화하느라 시간을 썼겠지만, 지금은 QAing과 함께 QA를 하다보니 테스터의 시간도 절약하고, 확인담당자의 시간도 절약하는 일석이조의 효과를 보고 있답니다! 




실제로 저희 팀원분들, 회사분들이 QAing을 통해 QA를 하니 너무 편하다라는 말씀을 해주실 때

이 프로덕트를 만드는 행복함이 배가 되는 것 같아요! 


QA는 커뮤니케이션이 차지하는 비용이 너무나 큰 만큼, 

팀별로 이 비용을 어떻게 줄일 수 있을지를 고민하는 것이 필요한 것 같습니다! 


https://bit.ly/3vecrB4


작가의 이전글 QA 툴이 탄생하는 과정 - 2탄
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari