먼저 입사 당시 초기 상황을 설명드리자면, 점핏은 론칭 시에 QA를 전담하는 담당자가 없는 상태였고, 그렇다 보니 기획자, 디자이너 분들께서 테스트를 진행하고 계셨습니다.
이 과정에서 어느 정도 자리를 잡은 프로세스가 있긴 했으나 전체적으로 QA 관점에서의 안정화된 프로세스가 필요했습니다.
1. 점핏을 선택한 이유
점핏에 대한 설명과 점핏 내 문화에 대해서는 이전에 알렉스가 작성해 주신 글이 있어서 참고 부탁드립니다 :)
QA != Tester 라는 것은 QA라는 직무에 관심이 있는 분이라면 누구나 알고 있는 사실일 것입니다. 그럼에도 아직도 이러한 인식이 남아 있는 것이 현실이고, 저의 전 직장에서도 마찬가지였습니다.
점핏에서는 이 인식을 깨고 업무를 할 수 있을 것 같았는데, 다음과 같은 이유에서였습니다.
- 다양한 직군(기획자, 개발자, 디자이너, 마케터, 운영자)이 모두 한 팀으로 자유롭게 커뮤니케이션하면서 협업 중
- 팀원분들이 QA 전문 인력 확보를 원함(QA의 필요성을 인지하는 조직)
- 원하는, 필요한 툴과 프로세스가 있다면 언제든지 제안 가능한 분위기
- 회사와 내가 함께 발전할 수 있는 가능성
(현재도 제 선택은 틀리지 않았음을 느끼고 있습니다😉)
2. 정착 과정
각 직무별 담당자와의 OJT 가 진행되었는데, 해당 과정은 생략하고 전체 흐름에서 QA로서의 정착 과정만 서술한 점 참고 부탁드립니다.
2–1. 기본 기능 및 플로우 작성
QA 는 기본적으로 제품에 대한 이해도가 높아야 합니다.
따라서 초반에는 기획 기반으로 전체적인 기능을 익히기 위해 기본 기능 TC와 플로우를 작성해 보았습니다.
해당 작업을 진행하면서 숨어있던 버그도 발견되고, 기획서에서 현행화가 필요한 부분도 확인하면서 전체적인 기능과 흐름에 대해서 이해하는 시간을 가질 수 있었습니다.
현재는 이때 작성한 기본 기능 TC를 계속 현행화해가면서, 기본 기능 테스트가 필요할 때마다 사용하고 있습니다.
2–2. 기획리뷰 참석
업무 플로우를 익히기 위해 프로젝트 기획 리뷰에 참석했습니다.
기획자와 개발자의 커뮤니케이션 방식과 기획 리뷰에서 논의되는 주요 포인트들을 알 수 있었습니다.
초반에는 위와 같은 위한 목적으로 참석했으나, 현재 점핏에서 QA는 대부분의 기획 리뷰에 참석하고 있습니다.
기획, 개발 담당자와 함께 추가 기획이 필요한 부분이나 기술적인 부분에 대해서 논의하면서 테스트할 때 고려해야 할 부분과 테스트 환경 세팅이 가능한지에 대해 체크할 수 있어 많은 도움이 됩니다.
2–3. 소규모 프로젝트 투입
제품에 대한 이해도를 확보했고 플로우도 이해했으니, QA를 시작할 준비가 되었다고 판단되어, 개발 기간이 3~4일 정도 소요되는 작은 프로젝트 참여부터 시작했습니다.
기획 리뷰에서 QA 진행 예정인 점을 공유드리고, 해당 리뷰를 바탕으로 기획서 검토, TC 작성, 테스트, 버그 리포팅, 완료 사인까지 조금씩 롤을 확대해갔습니다.
일정의 경우 기획 리뷰가 종료되면, 기획서와 개발 볼륨을 체크해서 기획서 검토와 TC 작성 시간을 포함해서 전달드립니다.
(소규모 프로젝트의 경우 약 2~3일, 대규모 프로젝트의 경우 약 10일)
2–4. 본격적인 업무 시작
프로젝트 투입에 앞서, QA 프로세스 공유회를 진행하였습니다.
(다음 목차에서 대략적인 전체 프로세스를 확인하실 수 있습니다.)
발표 준비 과정에서, 프로세스 중 조정이 필요한 부분은 조정하면서 진행하면 되니 크게 부담 갖지 말라고 해주셨던 점이 기억에 남네요 :)
프로세스 정리와 함께 해당 프로세스를 도입하여 본격적으로 QA 업무를 진행할 준비를 모두 마쳤습니다.
3. 현재 프로세스
3–1. 테스트 환경
현재 점핏의 서버는 Dev-QA-운영으로 구성되어 있는데, QA서버에 배포가 완료되면 테스트를 시작합니다.
온보딩 과정에서 완성된 대략적인 전체 프로세스입니다.
QA 인원의 한계로 모든 프로젝트에 위와 같은 프로세스로 참여하지는 못합니다. 큰 규모의 프로젝트나 주요 기능이 수정되는 프로젝트에 참여하고, 일정 협의 후 TC 작성까지만 투입되기도 합니다.
QA 기간에는 기획자와 디자이너도 테스트에 참여하는데, 기획자 관점, 디자이너 관점의 Bug도 찾아낼 수 있어 서버스 안정화와 퀄리티에 많은 도움이 되고 있습니다.
QA는 등록된 모든 Bug에 참조자로 등록되는데, 동시에 테스트 중인 경우에는 실시간 중복 방지의 목적과 함께 주로 발생하는 이슈 유형들을 파악하고,테스트 안정성을 판단하는데 활용하고 있습니다.
3–2. QA의 역할 및 테스트과정
위 프로세스 중 개발용 체크리스트가 무엇인가 궁금하실 수 있는데요,
- 개발용 체크리스트 : 개발 서버에서 QA서버로 배포하기 전 주요한 기능을 체크할 수 있는 체크리스트
QA가 소수인 팀이다 보니 이러한 개발 QA 과정에서 크리티컬한 이슈가 걸러져서, QA서버에서 보다 적은 인력으로 안정적으로 테스트할 수 있습니다.
1) (QA서버 배포 전) 정적 테스트 선행 : 기획서를 검토하고 TC를 작성하면서 기획 플로우상 필요한 기능이나 오류 체크해서 전달, 기획서 수정되면 담당자 전체 공유
2) (QA 서버 배포 후) 동적 테스트 진행 : TC 기반 테스트를 마치면 탐색 테스트 진행, 테스트 중 발견되는 Bug 등록 > 수정 확인 반복
(점핏에서 QA는 명세 기반의 테스트를 기본으로, 품질 향상 및 유저 사용성 관점에서의 개선 사항도 자유롭게 제안할 수 있습니다.)
마지막으로, 전체적인 기능 변경이 많았던 배포 주에는 배포 당일 수정된 플랫폼 전체 기본 기능을 확인합니다.
4. 앞으로 해야할 일
양질의 서비스를 제공하기 위한 QA의 노력은 계속되어야 합니다.
현재 제가 고민하고 있는 부분은 다음과 같습니다.
- 양질의 산출물(TC, 테스트 결과 공유 등)
- 체크리스트 작성 시점 및 주체 변경
- 무결한 테스트 환경(내부 환경상 QA 서버에서 온전히 금주 배포 건만 체크할 수 없는 상태)
- (언젠가는…) 자동화
현재 점핏에서의 저는 “혼자지만 혼자가 아닌 QA” 라고 생각하고 있는데요,
앞서 언급한 기획자, 개발자, QA를 포함한 팀 내 구성원 모두가 개인이 아닌 점핏을 위한 “TEAM”으로 협업하고 있습니다.
이러한 팀 문화를 기반으로 더욱 성장하는 점핏이 될 수 있도록 노력하겠습니다.
끝으로, QA가 점핏에 잘 자리잡을 수 있도록 도움주신 분들께 이 포스팅을 통해 다시 한번 감사하다는 말씀 드리고 싶습니다 :) !
제가 초반에 말씀드렸던 임무(온보딩 과정과 현재 점핏의 QA 프로세스 전달)를 잘 수행했다면 박수와 코멘트 부탁드립니다.👏
긴 글 읽어주셔서 감사합니다. 👼
