전사 QA 프로세스와 회고
시행착오 속에서 발견한 성장의 여정
이전글: 100일 챌린지 도전기
다음글: 고객 여정 지도를 통해 살펴보는 서비스의 이해
Intro
어느 날 서비스 배포 전에는, 전사 QA를 진행하기로 결정되었습니다. 기존에는 내부에서 1차로 개발 QA를 거친 후 UI/UX 디자이너 또는 PM이 2차로 QA를 진행했었습니다.
진행하게 된 배경을 살펴보니, 전사적으로 개발한 서비스에 대한 이해가 부족했었고, 자사에 QA담당자가 없는 점에서 QA프로세스를 수립해 문제를 해결하기 위한 목표로 진행하게 되었습니다.
결과적으로 현재까지 총 3회의 다른 기획에 대한 QA를 진행하였습니다. 아직도 프로세스를 정립해 나가는 중이지만, 이 3회 동안 생각보다 많은 어려움을 겪었습니다....
단순히 QA를 진행한다는 측면보다는, 전사적으로 타 부서와 협력해서 무언갈 진행해야 하는 프로세스에서 어떤 점이 허들로 다가왔고 어떤 과정을 경험하였는지 공유드리도록 하겠습니다.
QA란
QA(Quality Assurance, 품질 보증)는 제품과 서비스의 품질을 보장하고 오류를 예방하는 역할을 하는 프로세스입니다. 쉽게 말해, 제품이나 서비스가 처음 기획한 의도대로 개발되었는지 검증하는 절차라고 할 수 있습니다.
QA는 일반적으로 TC를 작성하고 검증하는 절차로 진행합니다. TC는 '테스트 케이스(Test Case)'의 약어로 서비스의 특정 기능이 정상적으로 동작하는지 확인하기 위해 실행하는 확인 절차라고 이해하면 좋을 것 같습니다.
QA의 목표는 서비스의 오류를 사전에 찾아내고 보완하며 사용자에게 긍정적인 경험을 제공하는 것입니다.
QA 프로세스
우선 QA는 초기에 다음과 같은 절차로 진행하려 하였습니다. 하나씩 말씀드리겠습니다.
Test Case 작성 → 제비 뽑기를 통한 QA 인원 선정 → QA 설명 및 진행 → 오류 및 Fail Case 이슈화 → Fail Case 수정 후 QA 재 진행
1. Test Case 작성
TestCase는 구글 스프레드 시트를 활용하여 서비스의 Flow와 일치하게 작성하려 했습니다. 처음 TC를 작성해 보았는데, 생각보다 시간이 많이 걸리는 작업이었습니다. 왜 QA가 인내심이 필요한지 이해가 되는 순간이었습니다..
2회 차 때 작성한 TC2. 제비 뽑기를 통한 QA 인원 선정
전사 QA는 다양한 직무의 동료들이 참여할 수 있도록 각 팀에서 최소 1명에서 2명을 뽑는 제비 뽑기 방식으로 진행되었습니다.
3.QA 설명 및 진행
전사 QA를 '왜' 진행하는지에 대한 설명이 주였고, 어떤 방식으로 진행하는지에 대해 설명하며 진행했습니다.
4. 오류 및 Fail Case 이슈화
TC 작성 후 Fail 처리되는 Case들은 Jira에 이슈화하는 방식으로 진행하였습니다. QA의 진행 속도를 위해 키워드 및 요건들만 수집한 후 진행이 끝난 후 PM이 남아서 별도로 Jira에 등록하여 이슈화를 진행하였습니다.
5.Fail Case 수정 후 QA 재 진행
Fail Case는 개발자들이 Jira를 확인하고 수정 후 이슈를 처리하였고 수정이 완료된 후에는 QA를 진행한 인원들에게 각자 자리에서 QA 재진행을 요청드리려 하였습니다.
프로세스를 실무에 적용하면서 아쉬운 점들이 발견될 경우 이를 보완해 나가려는 계획을 세웠습니다. 그렇지만 3차례의 QA 과정을 거쳤음에도 불구하고 긍정적인 결과를 얻지 못했습니다.
1차 QA
1차 QA는 신청 프로세스에 대한 QA였으며 운영 체계를 만드는 데 초점을 맞추어 진행하였습니다. 개발 팀장님의 주도하에 함께 학습하고, 가볍게 참여하는 취지로 진행하였습니다.
하지만 1차 QA가 종료되었을 때, 미흡했던 부분들로 인해 많은 아쉬움이 있었습니다.
첫째는, 'Test Case'의 미흡이었습니다.
처음에는 가볍게 QA를 하자는 목적으로 간단하게 TC를 작성하고 세부적인 것들은 각자가 체크하는 방식으로 진행하였습니다. 그러나, 세부적인 테스트 진행이 동료들에게 있어서는 너무나도 모호하게 느껴졌고, 이로 인해 QA의 원활한 진행이 힘들었습니다.
둘째는, 충분하지 못한 내부 QA입니다.
전사 QA를 진행하며 여러 이해관계자들이 얽히게 되었습니다. 따라서 전사 QA를 위한 일정이 만들어지고 이를 위해 급급하게 진행되었습니다. 일정을 맞추다 보니, 내부 QA가 제대로 이루어지지 않았고 QA진행이 계속해서 막히면서 정체되는 시간이 많았습니다.
위와 같은 두 가지 문제를 발견하였고 이를 보완하며 다음 기획에 대한 QA를 준비하였습니다.
2차 QA
2차는 사용자 강의실 관련 QA였습니다. 1차보다 준비할 시간이 많았기 때문에 매우 자신이 있었습니다. 또한, TC를 꼼꼼하게 작성하며 준비를 했고, 미리 내부 QA를 진행해 보며 프로세스 가이드라인을 세웠습니다.
QA 프로세스 가이드라인(요약)하지만... 준비를 열심히 했음에도 불구하고 2차 QA는 저에게 공포로 다가왔습니다.. 우선, 개발 팀장님께서 병가로 인해 갑작스럽게 책임을 지고 진행하게 되었습니다.
이와 더불어,
첫째로, QA를 위한 개발 환경 세팅이 부족했습니다.
QA 진행을 위해서는 Case 별 상황을 봐야 하기 때문에 일정 조건을 충족하는 계정이 필요했지만 준비를 하지 못했었습니다. 또한, 스테이징 서버에서 QA를 진행함으로 발생하는 Fail Case가 발생해 혼란을 겪었습니다.
둘째로, Test Case가 과다했습니다.
TC를 많이 작성하면 팀원들이 그대로 따라 하면 되기 때문에 진행이 원활할 것이라 생각했습니다. 그러나 생각과는 달리, 하나의 TC를 처리하는 데 많은 시간이 소요되어 QA 진행이 원활하지 않았습니다. 이전 QA의 문제였던 간단한 TC를 보완하려 했지만 오히려 부작용을 일으키는 것 같아 매우 당황스러웠습니다.
가장 힘들었던 부분은 각자 본 업무가 있고 양해를 드려 QA를 진행하는 것임에도 계속해서 문제가 발생하는 것에 대해 엄청난 죄송함과.. 무력감이 느껴졌습니다.
다시는 위와 같은 경험을 하지 않도록 저 자신 스스로 회고를 진행하며 조금 더 체계적으로 QA를 준비하기로 다짐했습니다.
2차 QA 개인 회고3차 QA
3차는 강사 스케줄 관련 QA였습니다. QA 환경을 미리 점검하였고 계정 또한 확보하였습니다. 또한, TC의 경우 핵심 기능을 위주로 정리하고 이를 먼저 설명하고 빠르게 진행하려 했습니다.
3차 QA는 무사히 마칠 수 있었습니다. 그러나.. 만족스럽지는 않았습니다..
원활한 진행을 위해 제가 서비스와 QA 프로세스를 설명하며 진행하였습니다. 하지만 생각보다 많은 설명이 필요했고 설명하며 진행하다 보니.. 참여형 QA가 아닌 강의형 QA.. 같은 느낌으로 끝이 났습니다.
"문제의 원인을 고민해 본 결과, 내부 어드민의 복잡한 기능 구조 때문에 기능에 대한 상세한 설명이 필요하다는 것을 알게 되었습니다." 또한, 전사 QA로 진행하기보다는, 보편적으로 고객이 이용하는 서비스에 추진하는 것이 바람직하다는 생각이 들었습니다.
다시 말해, 전사 QA의 목적을 효과적으로 달성하려면 진행될 서비스의 적합성도 함께 고려해야 한다는 것을 깨달았습니다
마무리
프로젝트를 진행하다 보면 수많은 시행착오와 실패가 당연히 있다고 생각합니다. 하지만 이번에는 타 부서의 동료들과 함께 진행되었기 때문에 어느 때보다 크게 다가왔습니다. 또한, 동료의 시간을 빌려 진행하는 프로세스다 보니 책임감과 부담감이 배로 느껴졌었습니다.
그럼에도 불구하고, 실패라는 것은 경험으로부터 배울 수 있는 가장 소중한 교훈인 것 같습니다. 실패는 항상 잘못된 점을 깨닫게 해 주고, 더 나은 미래를 위한 방향을 제시해 줍니다.
그런 의미에서 이번 QA 과정에서 겪은 시행착오들은 건강하고 성장 가능한 프로젝트를 만들어가기 위한 발판이었다고 생각합니다.
글을 보시는 분들도 파이팅 할 수 있기를 바라겠습니다.
감사합니다. :)
정리
1. QA 담당자 부재와 서비스 이해도 증진을 위해, 전사 QA를 진행함
2. 타 부서와 협력하여 진행하는 프로세스에 어려움을 겪었고 이에 대한 경험을 공유하고자 함
3. QA란, 제품과 서비스의 품질을 보장하고 오류를 예방하기 위해 진행하는 프로세스
4. [TC작성 → 제비 뽑기 → QA 설명 및 진행 → Fail Case 확인 → 수정 후 재 진행] 순으로 진행
5. 1차 QA는 TC가 미흡했고, 내부 QA가 충분하지 못해 진행이 어려웠음
6. 2차 QA는 QA 환경 세팅이 부족했고 TC가 너무 많았음
7. 3차 QA는 무사히 종료되었으나 강의형 QA 같은 느낌으로 진행되어 만족스럽지 못했음
8. 내부 어드민의 복잡한 기능 구조로 인해 3차 QA는 많은 설명이 필요했음
9. 전사 QA의 목적을 효과적으로 달성하기 위해서는 서비스의 적합성도 함께 고려해야 한다는 것을 깨달았음
10. 시행착오를 통해 건강하고 성장 가능한 프로젝트를 만들어 갈 수 있도록 하겠음.
