스타트업의 QA 프로세스 개선 (1) : 우리 모두가 QA입니다😉

이번 글에는 스타트업에서 2년 가까이 QA 전반을 담당하면서, 작은 규모의 IT 프로덕트 팀에서 QA는 누가, 어떻게 해야 하는가에 대해 고민하고 프로세스를 개선했던 경험을 담았다.

 

이 글을 추천드리는 분들

다음과 같은 특성의 조직에서 QA·테스트의 R&R을 어떻게 가져가야 할지 고민이신 분
- 작은 규모의 프로덕트 팀
    - 팀 전체 인원이 20명 미만
    - QA에 명시적으로 할당된 인원이 2명 이하
- QA 직무가 개발보다 기획 및 UX의 범주로 정의되어 있는 경우

 

 

QA 세상에 어서옵쇼😈

 

 

이거 나 혼자 다 못한다!

내 커리어의 시작은 QA 인턴이었다. 열한 달 동안 인턴으로 일한 뒤 기획 및 QA(라는 어정쩡한) 직무로 정규직 전환이 되었고, 또 1년 정도 뒤에 PM으로 직무를 확정했으니 거의 2년 가까이 QA 담당자로 일했던 것이다.

일반적인 QA 직무는 개발의 영역에 정의되기도 하는데, 당시 우리 프로덕트팀의 QA는 기획 및 사용성의 관점에서 테스트하는 일로 정의되었고, 소속도 기획팀이었다.

당시 공고의 자격 요건 - 기획 및 UX에 대한 감각을 강조한다.

 

 

당시 모든 개발 티켓에 대한 QA의 R&R은 기본적으로 QA 담당자에게 있었다. 스테이지 개발 완료 후 'QA 가능(Ready for QA)' 상태의 모든 티켓들의 Next Step에 대한 최소한의 처리 및 결정의 책임이 내게 있었던 것이다. 

QA 가능 상태의 티켓들에 대해, 최소한 셋 중 하나의 처리를 한다.
1) 티켓을 테스트한다.
2) 어떤 이유로 내가 테스트하기 어렵다고 판단되는 티켓이라면, 다른 동료에게 도움이나 할당을 요청한다. 
3) 기능 및 기본적인 사용성 점검이 마무리된 티켓이라면, 디자인 QA를 위해 티켓을 넘긴다.
     이 때 중심적으로 봐야 하는 측면이 있다면 디자이너와 소통한다.

 

입사한 뒤 약 1년 반이 되어갈 때 즈음, 이렇게 '모든 QA의 R&R이 QA 담당자에게 있다'는 방식이 뭔가 잘못되었다는 생각이 들었다.

 

 

첫번째로, '와 이거 나 혼자 절대 다 못한다'하는 원초적인 감정이 시작이었다. 

 

감사하게도 인턴 시절부터, QA 외의 기획·PM으로서의 일과 기회도 주어졌다. 동료들도 내 직무명과 관계 없이 '내가 어떤 일을 하고 있는지'에 집중하며 함께 일했고, 나 역시 그랬기에 PM의 역할을 당시의 나와 분리해서 보지 않고 만족하며 일했다.

한 편으로는, 그래서 업무가 매우 과중했다. 나도 기획과 PM의 롤을 담당하는 기능이 점점 많아지고, 프로덕트도 방대해지는 와중에 모든 개발 작업의 QA를 관리하려니 절대적인 업무량이 너무 많았다. 더군다나 QA 담당자는 새로운 기능에 대한 테스트뿐 아니라, 고객 및 내부의 버그리포트의 관리와 그에 따른 버그 티켓의 테스트에도 책임이 있었다. 

 

물론 QA해야 하는 티켓들이 너무 많으면 각 기능의 기획자들이 해당 기능은 본인이 테스트하겠다고 먼저 할당해가주시곤 했다.

하지만 '1) 기본적으로 내가 하되, 업무가 과중하면 다른 사람들이 가져갈 수 있다'는 것과 '2) 기본적으로 나눠서 한다'는 것은 R&R에 대한 정의로서 완전히 다르다.

1번의 정의에서는, 개별 티켓의 테스트를 다른 동료들이 하더라도 최종 R&R은 여전히 내게 있다. 내가 전체 QA의 책임자라는 인식 아래 진행상황 및 완료 여부를 최종적으로 확인하고 관리해야 한다. 반면, 2번의 정의에서는 처음부터 책임 소재와 관리 부담이 구조적으로 분산된다. 

무엇보다, 나뿐 아니라 모두가 바쁘게 일하는데 "나의 일을 나눠서 해줄 수 있겠니?"라고 묻는 것은 결코 쉽지 않다. 특히 기획하는 일이 테스트하는 것에 비해 '더 중요한' 일로 여겨지기에 더 그러했다.

 

 

두번째로, 모든 작업의 QA를'QA 담당자'가 다 하는 방식이 근본적으로 우리 조직에 부적합하다고 느꼈다. 첫번째로 언급한 리소스의 한계와는 별개로 말이다. 

 

QA를 잘하려면 기획 전반을 이해하고, 각 의사결정의 맥락과 히스토리를 알고 있어야 한다.

특히 '사용성에 문제는 없는지' 등에 대한 UX 관련 검수와 피드백까지도 QA 업무의 범주 안에 있었기 때문에, 단순히 '기획서의 요구사항을 반영했는가'로 끝나서는 안 되었다. 내가 느끼기에 뭔가 어색하다면 피드백할 수 있어야 했고, 그게 '어색하다'는 걸 판단하려면 기획·디자인 단의 의도를 꽤 깊게 체화하고 있어야 했다.

높은 확률로, 프로젝트에 깊게 인볼브되지 않은 QA 담당자는 해당 프로젝트의 기획자·디자이너만큼의 이해도를 갖기 힘들기 때문에, 놓치는 케이스가 있거나, 담당 기획자도 불안한 마음에 더블첵을 하는 경우가 많았다.

 

뿐만 아니라, QA 담당자가 기능을 파악하는 데에 있어 가장 많이 의존하는, 기획 문서가 늘 최신화되어 있지 않았다.

여느 스타트업들이 그렇듯 제품을 만들 때에 의사결정이 빠르고 기민하게 이루어졌다. 프로젝트에 깊게 인볼브되지 않은 QA 담당자가 이 맥락을 다 따라다니며 미리 트래킹할 수 없다. 특히 한창 개발에 집중하는 시기에는, 기획자-디자이너-개발자 간의 구두 논의를 통한 빠른 핑퐁으로 실시간적인 의사결정이 이루어지는 경우가 많았기 때문에, 작업 당시에는 기획서를 비롯한 여러 문서가 최신화되지 않을 때가 많았다.

그렇다고 해서 'QA를 잘하기 위해 문서화에 더 공을 들이자'고 하는 것은 우선순위에 맞지 않았다. 작업 당시에는 문서 업데이트보다는 기민한 의사결정과 빠른 적용이 훨씬 중요한 것이 분명했다. 그렇다면, 이렇게 일하는 방식에 맞는 QA 전략을 세워야 했다.

 

이 문제의식은, 기획자로서의 경험이 많아지면서 명확해졌다. 남이 기획한 기능과 내가 기획한 기능을 QA하는 것은 완전히 다른 경험이었기 때문이다.

 

다른 PM이 기획한 기능을 내가 QA할 때의 프로세스는 대략 다음과 같았다.

1. 기능 기획서를 읽고 이해한다.
     +ɑ: 이해가 안 가거나 누락된 것이 있으면 기획자에게 질문한다. 방대한 기획이라면 싱크를 맞추기 위한 별도 미팅을 진행한다.
2. 'QA 가능' 상태의 티켓을 테스트한다. 문제가 없을 때까지 Reject-Deliver를 반복하며 개발자와 QA 핑퐁을 한다. 
     +ɑ:  종종, Reject 사항에 대해서 개발자가 '저번에 00님(해당 피처 기획자)이랑 그렇게 하기로 바꿨어요'라고 한다. 기획자에게 확인 후 다시 테스트한다.
3. 기능 및 기본적인 사용성 테스트 완료 후, '디자인 QA 가능' 상태로 넘긴다. 
     +ɑ: 종종, 디자이너가 '이 부분 기능적으로도 제대로 동작하지 않는 것 같은데요?'라고 한다. 기획서를 재확인하거나 기획자에게 확인 후 다시 테스트한다.
4. 디자인 QA도 완료되어 티켓이 '배포 대기' 상태가 된다. 
      +ɑ : 종종, 배포 전 기획자가 마지막으로 확인하는 과정에서, 의도와 다르게 동작하거나 검수되지 않은 케이스가 발견된다. 전달 받고 내가 다시 테스트하거나, 기획자 본인이 추가 테스트를 한다. 

 

반면 내가 기획한 기능을 직접 QA할 때에는, 각 단계의 +ɑ가 필요 없었다. 

기획 내용과 디자인 가이드, 그리고 문서화되지 않은 여러 의사결정들이 내 머릿속에 있었기 때문에 테스트의 시간도 짧고 개발자와의 핑퐁의 횟수도 적었으며, 놓쳐지는 케이스도 적었다. 또 만약 개발된 내용이 UX적으로 어색하다면 QA한 주체인 내가 직접 고민하고, 또 직접 디자이너·개발자에게 논의를 요청하고 함께 의사결정하면 되었다.

---

이렇게 두 가지 문제의식을 가지고, '무언가 바꿔야 한다'고 생각하기 시작했다. 

 

제품을 만들 때에는 우선 목표를 세우고, 그 목표에 도달하기 위해 해결할 문제를 정의하고, 그 문제 해결에 적합한 솔루션을 도출한다.

QA 프로세스를 개선하는 것도 마찬가지일 것이다. 

그래서 뭔가를 바꾸기에 앞서 질문을 던졌다. QA란 무엇이고, 왜 하는가? 

 

 

QA란 무엇이고, 왜 하는가?

1) QA란 무엇인가?

QA는 Quality Assurance, 즉 '품질 보증'을 의미한다.

 

2) 그렇다면 우리는 '품질 보증'을 왜 하는가?

사용자에게 최대의 서비스 가치를 제공하여 비즈니스 리스크를 감소시키기 위함이다.

애초에 의도한 제품의 가치가 구현 및 사용자에게 전달되는 과정에서 의도치 않게 왜곡되거나 반감되지 않도록 하는 것이다. 

 

3) 그렇다면 '품질 보증'은 어떻게 가능한가?

제품의 품질의 기준을 달성함으로써 가능하다. 무언가를 보증한다는 것은, 어떤 기준이 있고 그것을 달성하겠다고 약속한다는 의미이다.

따라서 품질을 달성하기 위해서는 품질의 기준이 먼저 정의되어야 하고, 그것을 달성하기 위해 움직여야 한다. 

 

이 기준은 사용자에게 제품의 가치가 전달되는 다양한 접점을 포괄한다. 따라서 기능 자체의 품질 뿐 아니라 사용자와 우리 제품이 만나는 지점인 배포 과정의 품질 또한 포함된다. 기능이 언제 배포되어 사용자가 언제부터 쓸 수 있는지, 배포와 업데이트 과정에서 사용자 경험이 어떠한지에 따라 제품의 가치가 달라질 수 있다.

 

4) 그렇다면 품질 기준은 어떻게 세울 수 있는가? 

제품의 목적과 기능에 대한 이해를 바탕으로 해야 한다. 즉, 제품 품질의 기준을 세우는 것은 그 기능을 가장 잘 이해할 때에 잘할 수 있다.

 

위와 같이 우리 조직에서의 QA의 의미와 목적에 대해서 고민과 리서치를 하면서, 우리 팀이 'QA를 어떻게 바라보아야 하는가'에 대한 문장을 정리했다.

QA is not charge of Testing & Finding Bug
QA is in charge releasing Quality-Achieved product.
 
QA는 테스트하고 버그를 발견하는 일이 아니다.
QA는, 품질의 기준을 달성한 제품을 사용자에게 전달하는 데에 책임이 있는일이다.

 

 (사실 이게 내가 어딘가에서 따온 문장인지, 직접 생각을 정리해낸 문장인지 잘 기억이 나지 않는다..ㅠㅠ

혹시 비슷한 문장을 사용한 출처를 알고 계신다면 지적 부탁드립니다🙇‍♂️)

 

 

그렇다면, QA는 어떤 일들을 포함하며 누가 해야 하는가?

1) '품질보증'으로서의 QA는 어떤 일들을 포함하는가? 

QA를 단순 테스트가 아닌 품질 보증의 관점으로 확장했으니, 새롭게 정의한 QA라는 업무가 어떤 일들을 포함하는지 돌아봐야 했다. 

 

• 구현 전

  - 제품 품질의 기준을 세운다.

  - 해당 제품 품질에 맞게 구현이 가능할지 사전 확인한다. 

 

• 구현 중

  - 제품 품질의 기준에 맞게 구현한다.

  - 구현 중에 추가되는 기준이 있으면, 품질의 기준에 추가한다.

 

• 구현 후

   - 구현된 제품이 품질을 달성했는지 확인한다. 

   - 달성하지 못했다면, 달성을 위해 팀원들과 소통한다. 

   - 달성할 수 없는 것으로 판단된다면, 원인을 파악하고 품질의 기준을 점검·조정하고 동료와 소통한다.

 

• 배포 전후

   - 기능의 배포 일정을 관리한다.

   - 배포 후 문제가 없는지, 즉 기대한 품질의 수준으로 작동하는지 확인한다. 

   - 품질에 문제가 있다면 해당 문제를 해결할 수 있도록 팀원들과 소통한다. 

       -> 상황에 따라, 해당 문제를 새로 정의해 1~4번의 과정을 거친다. 

 

 

2) 그렇다면, '품질보증'으로서의 QA는 누가 해야 하는가?

위 내용 중 파란색과 보라색으로 표시한 부분은 무엇을 의미할까?

파란색은 기존에도 별도의 QA 담당자가 아닌 기획자·개발자·디자이너가 하던 영역이고, 보라색은 QA 담당자와 기획자·개발자·디자이너들이 함께 하는 일을 표시한 것이다.

 

QA를 품질 보증의 관점으로 확장해서 보면, 각 작업을 하고 있는 모든 인원들이 이미 QA의 주체로 일해온 것이다. 딱 테스트를 하는 영역만 빼고 말이다.

테스트는 곧 제품이 품질 기준을 달성했는지 확인하는 것이고, 그 앞뒤의 과정인 품질의 기준을 세우고, 점검하고, 조정하는 일은 QA 담당자가 아닌 각 작업의 당사자들이 한다. 이 모든 과정이 무자르듯 나눠지지 않고 연속적인데, 그렇다면 왜 '테스트하는 일'만 별도의 담당자가 해야 할까? 이는 리소스를 분배하는 관점에서 단순하고 간편한 방식이었을 뿐, '품질 보증'을 잘하는 것과는 거리가 먼 방식이라는 생각이 들었다.

 

이렇게 정리하고 나니 명확해졌다. 

QA는 품질 보증이고, 품질 보증은 품질의 기준을 달성함으로써 가능하고, 품질의 기준은 해당 제품을 가장 잘 아는 사람이 잘 세울 수 있다. 그렇다면 품질 보증으로서의 QA는, 해당 제품의 목적 및 기능에 대해 가장 잘 이해하고 있는 사람이 하는 것이 맞다.

QA에 적합한 주체는 해당 제품을 만드는 당사자들일 것이다.

 

이렇게 정리하고 나니 '너무 속보이는 결론인가..?' 싶으면서도, 당장은 각자가 힘들지라도 우리 조직에 분명 맞는 방향성이라는 생각이 강해졌다.

 

동료들에게 공유하기 : 우리 모두가 QA입니다😉

이렇게 고민한 과정을 가장 먼저 기획팀에게 공유했다.

결론적으로 자신이 기획한 기능의 테스트는 본인이 하는 것으로 명확히 하자는 이야기를 하는 것이니 걱정했는데, 다행히 다들 공감하며 동의해주었다. '안그래도 그동안 채은님의 업무가 과중해서 걱정이 되었다'고 말해주기도 했다.

다만 이렇게 R&R을 나누었을 때 걱정되는 문제들(PM들의 업무 과중, 새로운 기능 외에 버그 및 유지보수성 작업에 대한 QA는 어떻게 나눌 것인지 등)이 제기되었는데, 이 문제를 함께 잘 해결해보는 것으로 이야기했다. 길게 보았을 때 이 방향의 효율적이라는 데에 동의했기 때문이다.

 

다음 순서는 프로덕트팀 전체에 공유하는 것이었다. 이 때에는 기획팀에 공유할 때와는 주안점을 좀 달리 했다.

프로덕트팀에 공유를 예고(?)한 슬랙 메시지. 사실 정말정말 떨렸다^^...

첫번째는, QA를 단순히 테스트가 아닌 '품질 보증'으로서 바라보도록 팀 전체의 이해를 맞추는 것이었다.

공유를 위해 작성한 문서의 서두 - QA를 단순 테스트로 보지 않도록 유의했다.

내가 제안하는 개선으로 R&R이 가장 크게 바뀌는 것은 기획팀이었지만, QA를 품질 보증으로서 이해하게 된다면 앞으로 다른 직무의 멤버들도 새롭게 기여할 수 있는 영역이 많아질 거라 생각했다. 

 

두번째는, 그 관점에서 지라 티켓에 테스트 케이스를 작성 및 활용하는 방식에 관한 것이었다. 

이전부터 팀 내에서 티켓의 체크리스트에 테스트 케이스를 작성하자는 목소리와 노력이 있어왔는데 잘 지켜지지 않았다. 프로세스 개선을 고민하면서, 이 문제 또한 QA라는 일을 자신과 분리해서 보는 것에서 비롯되었다는 생각이 들었다.

테스트 케이스는 결국 제품이 달성하고자 하는 품질에 대한 기준이다. 직무 상관 없이 '나 또한 QA에 역할과 책임이 있다'는 철학이 공유된다면, 품질 명세로서의 테스트 케이스를 더 잘 활용할 수 있을 것 같다고 판단했다. 그래서 이 관점 아래에서 테스트 케이스를 활용하는 규칙을 재정의하고 팀에 공유했다. 이 테스트 케이스 활용 개선에 대한 이야기는 2탄의 다음 글에서 자세히 다룰 예정이다. 

 

 

다행히, 그리고 고맙게도 팀원들 모두 방향성에 공감했다. 특히 테스트 케이스에 대한 고민이 많던 개발자분들이 그 부분에 대해 여러 아이디어를 내면서 적극적인 개선에 대한 의지를 보였다. 

이 날 공유를 하면서 내가 무심코 했던 "그니까.. 우리 모두가 QA라는 거죠^^"라는 말이, 얼마간 팀 내에서 밈처럼 사용되기도 했다😋

 

 

효과는 굉장했다!

이렇게 팀에 공유한 이후, 한 순간에 된 건 아니지만 모든 팀원들의 노력으로 프로세스가 점진적으로 개선되었다. 그 효과를 정량적으로 측정하지는 못했지만, 개선의 효용이 분명히 느껴졌다.

일단 내 개인적으로 테스트 업무에 대한 부담이 줄어든 것은 당연했다. 그 덕에 기획 영역에 힘을 실어 PM으로의 본격적인 직무 전환을 준비할 수 있었다.

 

팀적으로는, 우선 애초의 문제의식이었던 테스트 과정에서 불필요하게 커뮤니케이션하고 확인하던 과정들이 분명하게 줄었고, QA 완료 후에 추가적인 이슈가 발생하는 정도도 줄었다. 만들고 있는 기능을 가장 잘 아는 사람들이 테스트하기에 당연했다.

 

기획팀에서 걱정했던, R&R을 바꾸었을 때 각 PM의 업무 과중 문제도 해결할 수 있었다. 테스트 R&R을 '각 기능의 기획자가 하되, 필요 시 QA 담당자가 할당해갈 수 있다'로 정의해, QA 담당자에게 테스트 업무의 부담이 줄어들되 PM들도 바쁜 경우에는 담당자에게 도움을 받을 수 있도록 했다. 이 때 각 티켓의 최종적인 R&R은 테스트를 할당받은 QA 담당자가 아닌 PM에게 있다. 대신 기능 단위로 묶이지 않는 버그나 유지보수성 이슈들에 대한 테스트의 R&R은 계속해서 QA 담당자에게 있도록 했다. 

 

특히 반가웠던 것은, '이렇게 하자'고 명시적으로 이야기하지 않았는데도 팀원들이 주체적으로 적극성을 높인 부분들이었다. 

우선 테스트를 요청하기 전 개발 단에서 검수의 적극성이 높아졌다. 'QA 가능' 상태에 넘어오기 전 개발자들이 선제적으로 문제를 확인하고 고치니, 기획·디자인단 테스트 시 발견되는 버그들이 줄었다. 

또 개발 과정에서 개발자들이 체크리스트에 검수가 필요한 요소들을 직접 추가하거나, 직무와 관계 없이 '이런 부분을 특히 확인하면 좋을 것 같다'고 제안하는 빈도도 높아졌다. 

서로 농담으로 주고 받던 '우리 모두가 QA다'라는 말이, 어느 정도는 팀에 진짜 공유되고 있다는 것이 느껴졌다. 

 

 

그해 말 동료들로부터 받은 360도 피드백 중

그해 말 동료들이 내게 해준 익명 360도 피드백에서도, 이 개선을 긍정적으로 평한 것이 많았다. 팀에 개선을 제안한지는 반년이 넘게 지난 데에다 계약상 직무가 PM으로 전환되면서 QA 프로세스 개선을 담당하지 않은지 수달이 된 시점인데도 언급이 많았다는 사실이 반가웠다. 동료들도 함께 효용을 체감하는 것이 느껴져 기뻤다. 

 

이후에도 팀 모두가 QA 관련 개선을 위한 노력들을 계속했다. 

이 때의 개선도 팀 전체가 QA에 대한 철학을 공유했기에 가능했다고 생각해서, 위에서 정리한 문서를 단순 '제안서'에서 우리 프로덕트팀의 QA에 대한 철학을 정의한 문서로 발전시켰다. 그리고 새로운 멤버들이 합류할 때 직무 상관 없이 이 문서를 가지고 QA 온보딩을 진행했다. 

또 내 뒤로 합류하는 QA 담당자분들은, 업무의 영역을 '기획과 QA'가 아닌 QA로 분명히 하고, 대신 단순 테스트가 아닌 QA 프로세스를 개선하고 관리하는 것에도 역할이 있는 것을 분명히 했다. 그렇게 새로 함께한 QA 인턴분들 덕에 훨씬 많은 부분들이 좋은 방향으로 바뀌었다.

 

 

마무리하며

사실 개인적으로는, 이전에 QA의 역할과 책임 전부가 내게 있었기 때문에 배운 것도 많다.

내가 기획하지 않은 기능을 더 잘 이해하고 테스트하기 위해 작업 담당자들과 긴밀하게 소통하고, 방대한 제품의 곳곳을 깊게 만져보면서 프로덕트에 대한 이해를 높일 수 있었다. 그랬기 때문에 비교적 초반부터 기획과 PM으로서의 기회가 주어졌던 것이라고도 생각한다. 당시에도 그렇게 생각해서 반갑게 일했고, 이후 PM이 되었을 때도 그 때 경험의 힘을 많이 느꼈다.

 

무언가를 바꾸려면 동료들을 설득해야 하고, 그 목소리에 힘이 있으려면 문제에 대한 확신을 뒷받침할 근거가 있어야 한다.

QA에 대한 정의를 새로 하고 촘촘히 논리를 전개한 것이 가장 주요했겠지만, 동료들이 내가 느꼈던 문제에 공감한 건 내가 기존의 구조에서 최선을 다한 것을 보았기 때문이라고 느낀다. 최선을 다했기 때문에 '무언가 잘못되었다'는 막연한 불편함도 문제라고 확신할 수 있었고, 쉽지 않았지만 용기내어 개선하자는 목소리를 낼 수 있었으며, 그 목소리에 힘이 실렸다고 생각한다.

벌써 2년이 지난 일이지만, 신입으로서 처음으로 용기내어 개선을 제안하고, 동료들의 끄덕임을 받으며 함께 노력했던 활력 있는 기억으로 남아 있다. 

 

당연하게도 우리가 했던 방식이 정답은 아니지만, 비슷한 상황에서 비슷한 고민을 하고 있을 세상 어딘가의 QA 담당자에게 도움이 되었으면 하는 마음으로 글을 마친다.