[원티드 강의] 지그재그의 QA 팀을 만들기까지의 경험

Test 엔지니어 vs QA 엔지니어

Test 엔지니어 : 결함을 발견할 수 있는 효율적인 접근법과 개발법을 만듦

QA 엔지니어 : 결함을 예방할 수 있는 프로세스를 만들고 개선함

 

 

팀빌딩 시작 단계

QA의 역할을 출시 전 테스트에 가두지 않고 이 조직에 QA가 왜 필요한지를 파악하기

 

지그재그에서 QA는 감시하는 역할이 아니라, 뒤에서 도와주는 역할!

제품개발로 정신없는 프로덕트 팀들이 혹시나 놓치는 것들이 있는지 파악하고 챙겨줌으로써 프로덕트팀이 빠른 속도를 유지하면서 좋은 제품을 만드는데 집중하도록 돕는 팀이라고 강조했음

 

지그재그 CEO : 내 뒤에 동료가 있으니 실수를 하더라도 다시 기회가 올 것이라 믿으며 개발자들이 자신있게 개발을 할 수 있도록 해달라고 말하심! (축구경기의 공격수에 비유, QA는 공격수 앞이 아닌 뒤에서!)

 

 

프로세스 도입, 실행

프로세스 : 업무도구, 소통규칙, 업무 수행구조 등

프로세스 도입도 제품개발처럼 하자!

제품개발팀(=고객)의 의견을 들어 그들에 맞게 만들고, 프로세스를 이해시키고(=마케팅) 실행하게 만들었음

목표 달성의 기준은 프로세스 도입이 아닌 실행으로!

 

프로세스 도입하며 나온 문제점과 해결책

릴리지 트레인 : 개발주기와 릴리즈(출시)를 독립적으로 분리하는 전략

릴리즈 트레인은 개발일정이나 상황에 의존하지 않고 정해진 시간에 출발함! => 열차에 비유

 

릴리지 트레인 도입 후 문제점

1. 가장 긴 개발주기에 릴리즈 주기가 맞춰짐  ex. 우리 작업도 거의 완성됐으니 이것까지 하고 릴리즈 해주세요

2. 릴리즈 연기 시 부담 증가  ex.  배포하기로 한 작업은 릴리지를 하루이틀 늦춰서라도 배포

3. 계획되지 않은 추가 릴리즈 진행  ex. 프로덕트팀에 릴리즈 주기에 맞게 개발주기를 바꿈

 

문제점의 원인 

: 지그재그는 다양한 릴리즈 전략들중 릴리즈와 개발주기가 의존적인 배포방법을 사용했었음

- 개발이 완료되는 대로 배포  (의존)

- 완성된 과제들이 쌓이면 묶어서 배포  (의존)

- 프로젝트 팀 스프린트 주기와 동기화된 배포  (의존)

- 릴리즈 트레인  (분리)