IT 스타트업은 어떻게 QA를 할까? - 1탄
내 조직에 적합한 QA 하기
안녕하세요, 더 나은 QA를 위해 고민하는 큐에잉입니다!
저희는 QAing이라는 서비스를 구축해 나가면서 많은 현업자 분들의 QA 경험에 대해 들어 왔어요.
인터뷰를 하면서도 많은 분들이 여쭤보신 질문이 "그래서 다른 분들은 어떻게 QA를 하나요?"였어요.
많은 분들이 이 점을 궁금해 하시는구나를 느껴, 이번 글에서는 다른 스타트업팀에서는 어떻게 QA를 진행하는지 공유해보려고 해요!
(팀마다 QA를 하는 방식은 아주 다양해요. 아래의 내용은 저희가 인터뷰를 했던 분들의 이야기를 바탕으로 하고 있어요)
다른 팀은 QA를 이렇게 진행해요
사진: Unsplash의Marvin MeyerQA 방식
많은 분들을 인터뷰해 본 결과, QA를 진행하는 방식은 다양했어요. 그 중 크게 분류를 해보자면 디테일을 챙기며 QA를 하는 경우와 조금 더 빠르게 QA를 진행하는 경우가 있었어요.
먼저 디테일을 챙기는 경우에는 정리된 TC에 따라 모든 케이스의 QA를 진행해요. 스프레드 시트에 모든 TC를 미리 정리해두어 이를 바탕으로 QA를 하거나, 기획자의 화면 설계서를 기반으로 모든 플로우를 직접 테스트를 하세요. 반면 속도를 더 중요시하는 경우에는 모든 플로우를 따라가기 보다 엣지 케이스를 찾아내기 위해 여러 방식으로 랜덤하게 이용해보는 경우도 있었어요. 아무래도 미처 예상하지 못한 유저 케이스에서의 오류를 발견할 수 있는 방법이기도 하죠!
QA 빈도
QA를 하는 빈도 또한 팀마다 매우 다양했어요. 인터뷰를 하면서 알게된 점은 QA를 일정을 잡아 정기적으로 하기보다는 필요할 때마다 하는 경우가 많았던 것 같아요. 버전업과 같이 개발 또는 기획적으로 큰 업데이트가 있을 때 QA를 진행하기도 하고, 비정기적으로 수시로 진행하기도 하더라구요. 또는 스프린트식으로 운영되는 팀이라면 일주일에 한 두번씩은 매주 진행하게 되는 경우도 있었어요.
팀큐에잉의 경우에도 1주일의 스프린트 방식으로 운영되고 있어 매주 크고 작은 업데이트를 진행하고 있어요. 그러다 보니 QA를 매주 수시로 하게 되는 것 같아요. 또 전체적으로 큰 플로우의 유저 케이스를 QA 시트에 정리한 후 진행하고, 그 외의 케이스들은 수시로 저희 서비스를 다양한 방식으로 만져보며 QA를 하고 있어요.
QA 결과는 이렇게 공유해요 - 규모별
사진: freepikQA를 진행한 후, 결과를 공유하는 과정에서는 팀 규모별로 뚜렷한 차이가 있었어요.
먼저 QA를 공유할 때 많이 사용하시는 툴을 소개해보자면, 바로 노션, 스프레드 시트, 그리고 슬랙이었어요.
테스트플라이트, 지라 등 다른 툴을 사용하시는 팀도 있었지만, 규모가 많이 크지 않은 팀을 보았을 때는 이렇게 세가지를 가장 많이 이용하시는 걸 발견할 수 있었어요.
소규모
10명 이하의 작은 팀에서는 노션을 쓰기도 하지만, 대체적으로 구두로 전달하거나 슬랙을 이용해요.
규모가 작다 보니 일을 할 때도 긴밀하게 소통이 가능하기 때문에 바로 옆자리에 있는 팀원에게 말로 설명하거나 직접 보여주는 경우가 많았어요. 또는 슬랙을 이용하기도 하는데, 오류가 있는 화면을 캡쳐해 관련 설명을 덧붙여 함께 보내기도 해요. 아무래도 바로바로 전달과 확인이 가능하기 때문에 많은 소규모 팀이 슬랙을 이용하는 것 같았습니다!
규모가 아직 작은 초기 스타트업은 시간이 매우 중요하죠. 최소한의 리소스를 들여 빠르게 프로덕트를 만들어 가는 것이 중요하기 때문에 '효율성' 위주로 래피드한 QA를 진행하는 것이 특징이었어요.
중소규모
: 중소규모의 경우 노션이나 스프레드 시트를 사용하는 경우가 많았어요. 직접 QA 시트를 만들어서 꼼꼼하게 진행을 해요. 몇몇의 QA 시트 사례들을 보았는데, 형태도 아주 다양했어요. 주로 노션에 table을 만들어 우선순위, 이슈 내용, 보고자, 담당자, 확인 여부 등의 속성값을 추가해, 이를 통해 팀원과 교류해요. 각 이슈별로 페이지를 만들어 캡쳐 이미지 또는 녹화영상을 첨부하고, AS-IS와 TO-BE로 구분해 어떻게 수정이 되어야 하는지 정확하게 전달하는 경우가 많았죠.
이렇게 시트로 QA 사항을 정리하면 우선순위별로 어떤 문제를 먼저 처리해야 하는지, 담당 개발자가 확인후 진행중인지 혹은 완료된 상황인지 등을 바로 확인할 수 있어 더 체계적으로 진행이 가능해요!
대규모
대규모 회사의 경우에는 따로 QA 전담 팀이 구성되어 있는 경우가 많았어요. QA 엔지니어 분들이 QA를 맡아 진행하고, 전달 사항이 있으면 개발자, 기획자, 디자이너와 공유하며 주고받는 식으로 진행되었어요. 흥미로운 점은 대기업은 프로덕트의 규모도 크다 보니 '자동화'가 되어 있는 경우도 있었어요. 자동화는 기기별, 운영체제별로 QA가 자동으로 실행되고, 오류 발견시 담당자에게 알림이 가는 식으로 진행돼요.
하지만 이런 자동화 시스템을 갖추고 있다고 해도 거의 수동 QA를 함께 진행하기도 해요. 기존의 기능들은 자동화로 돌려두고, 새로운 기능이 출시되거나 업데이트 사항이 있을 때는 수동으로 QA를 진행하며 바로바로 오류를 체크한다고 해요. 또는 복잡한 QA는 자동화로, 간단한 QA는 수동으로 진행하는 곳도 있었어요. 이렇게 수동으로 할 때는 다른 팀과 같이 노션 시트나 스프레드 시트로 QA 시트를 만들어 관리해요.
팀큐에잉의 노션 QA 시트팀큐에잉의 경우에는 구두로 전달 + 노션 시트 관리로 진행하고 있어요. QAing으로 QA를 진행하면서 이슈를 발견하고, 해당 부분의 이미지나 영상을 노션 QA 시트에 임베드해 공유해요. 사실 MVP 개발 단계에서는 QA 시트를 만들어 일일이 관리할 시간이 부족해 주로 구두로 전달했었어요. 기능 혹은 디자인적 오류 사항을 개발자분께 전달하면 개발자분이 개발 노션 페이지에 따로 적어두는 식이었는데, 이렇게 하다 보니 오류 사항을 전달하는 사람도, 전달 받는 사람도 깜빡하는 경우가 많았어요.
또 공유 문서에 정리되지 않다보니 오류가 해결된 상황인지 계속 구두로 여쭤봐야 하는 상황이 생기더라구요. 그래서 이후부터는 노션에 QA 시트를 만들어 정리하기 시작했어요. 우선순위, QA 버전, 이슈 종류, 작업상황 등의 속성을 만들어 꾸준히 체크하고 관리하고 있어요. 시트로 정리를 하니 확실히 전에 공유했던 이슈를 깜빡할 일도 없고, 체계적으로 관리가 가능해 소통하는 데 드는 리소스를 줄일 수 있었던 것 같아요!
이렇게 조직별로 QA를 진행하는 다양한 방식에 대해서 이야기해보았는데요, QA를 하는 방법에 정답은 없는 것 같아요. 앞서 소개한 여러 방식들 중에서도 각 팀의 규모와 운영 방식, 프로덕트의 특성에 맞게 적합한 방식을 적용하는 것이 가장 효과적이지 않을까 생각합니다.
혹시 어떻게 하면 우리팀의 QA를 체계적으로 관리할 수 있을까 고민중이시라면, QAing에 가입해보세요!
체계적인 QA를 도와줄 노션 QA 시트 템플릿을 무료로 드리고 있습니다 :)
