SDET / QA 직군에 대한 경험담 & 소견 #1
직접 협업자 & 실무자 관점에서 쓴 1부
회사의 규모나 상황에 따라 어느정도는 다르겠지만,
내 경우는 코어 비즈니스 밸류 체인 (핵심 돈벌이 사업이라고 적는다) 쪽 도메인에서
개발자/PM을 했었다보니, 상대적으로 QA와 함께 협업했던 기억이 많다.
첫 회사인 네이버/NBP에서도 내가 있던 마플본부/검색광고 개발랩 조직에는 예외적으로
QA부서가 남아있었고, 거의 내 전담에 가까운 조선족... 테스터분들이 1~2분에
QA팀의 시니어 QA분이 중요 프로젝트에 내 카운터 파트로 배정되시곤 했다.
대략 2011년 말? ~ 2012년 중에 기존 CTO님이 Next 학장으로 떠나신 후,
새 CTO님이 부임해서 '생산성 혁신' 조직을 운영해서 전사 애자일 + TDD & Self QA 문화 도입을 위해
노력하셨는데, 내 사수분들 전부 그리고 QA팀의 지원에 이미 길들여진(?) 나는 매우 부정적이었으나
어찌됬든 시키니까(?) 했다. 단위 테스트, 테스트 커버리지 올리기, 통합 테스트 Fitness 자동화 등등
다만 이걸로는 코어 비즈니스 레벨의 '논-코드' 이슈는 절대 못잡아서, 결국은 QA가 달라붙었다.
당시 결론적으로 이 시도는 실패했었고, 지금도 네이버 개발 문화에 애자일이 100% 도입되었는지는 모른다. 일부 조직은 적용 되었을 지언정 전사적으로는 아마도 아닐꺼다. (라인+쪽 재직하는 지인들 얘기를 들어봄)
그런데, 어쩌다보니 다음 회사에서는 내가 TECH SDET & QA리드가 되었고, 시키니까 억지로 했던 이것들을
내가 주도해서 해야만 했던 상황이 되었다. (사실 여전히 일이니까 했지만, 자발적인 의욕은 없었다...)
초창기엔 서비스 품질이 너무 안좋아서, 이 버그 언제 다 잡힐까 수준이었는데
그래도 약 1년 지나니까 꽤나 안정적인 버젼까지 올라왔고 슬슬 시나리오 테스트 자동화를 생각할때가 되어서
1. 로보티움이라는 안드로이드 자동화 툴을 연단위 구독 결제했고
2. Sahi Pro라는 웹 베이스의 스크립트 자동화 솔루션을 구입해서 적용했다.
3. API쪽은 PHPUNIT 기반의 (당시 PHP 백엔드) TDD와 API 테스트를 위한 POSTMAN SET 구축 등
(참고로 비용은, 정부과제 지원금에 SW개발 보조지원금 통장에서 꺼내쓴거라 딱히 부담은 없었음)
이를 적용해서 약 3~4달 기간의 개발 후에는 아래와 같은 자동화가 가능했다.
- iOS는 처음부터 잘 설계된 좋은 모듈화가 되어서 간단한 TDD 후로는 여간해선 버그가 없는 수준이었음.
- PC 웹은 거의 A-Z의 90%를 자동화 테스트가 가능해졌음, 새로운 기능에 맞춰서 스크립트 고치는 부분이 수기 공수
- 백엔드의 API는 TDD로 개발해서 거의 버그 없음 & 배포 자동화도 붙여서 테스트 실행/통과도 자동화함
- '로보티움'을 통해서, 안드로이드도 특정 레퍼런스 버젼별 기본 시나리오 테스트는 자동화가 되었다.
다만, 이건 액션 단위로 정확하게 정의 (스크래치 코딩을 생각하면 된다) 가 필요해서, 반응 속도까지 고려한
정밀한 노가다 디자인이 들어갔고, 나중에는 좀 귀찮아져서 메이저 업데이트 앞두고서나 로보티움을 업데이트 하고, 그냥 산학협력 등의 인턴 2~3분들을 매뉴얼 테스터로 썼다....
테스트 자동화를 통해 약간 노가다 업무의 일손이 덜어지니까 - 여유가 생겼는데
이 여유를 이용해서 / 서비스 정책, 기술 정책을 사용자 역할 별로 상세 정리하고 / IA, 와이어 프레임을 그리고
/ 지라 칸반을 통한 '애자일' 개발을 도입하고 / 티켓을 만들고 배정하고, 처리 상태를 트랙킹하고 피드백을 남김 / 최종적으로 릴리즈(배포)를 결정함 / 푸시,메일,sms 발송 서버를 node.js로 개발하고, 다국어 지원 템플릿화를 시킴 / 그리고 아에 상위 기획 레벨 - 상세화 과정에서 개발자의 입장을 대변하는 1차 검토자가 되서
디자이너 출신의 CDO가 주도하는 서비스 기획에 대한 피드백을 해주는 자문 역할도 2014년부터 쭉 했음
자동화라도 당연히 변경이 필요한 업무인 테스트 시나리오 보강 (pc, 앱x2) / 테스트 스크립트 수정은 했고
약간 노가다 작업인 부하테스트나, 배포전 수기 풀 테스트 등은 중간 중간 회사를 거쳐간 서너명의 인턴 개발자 분들이 주로 담당했었다.
여전히 내 생각은 QA라는 업무 자체는, 그냥 개발자의 뒤처리를 해주는 보조적 역할에 지나지 않는다고 보긴 했다. 그리고 시장에서도 이에 대한 평가를 반영하듯 이 직군에 대한 처우는 거의 다가 형편 없었기도 하고
덕분에 Next 이직때 개발 / 기획쪽으로 알아봤었지, QA로 전문가가 되어보자는 생각은 1도 없었다.
> 개발 프로세스상 꼭 필요는 한데, 처우 측면이나 성과 차별화가 잘 안되는 (...) 계륵 같은 존재랄까
다만 이 세상에 쓸모 없는 경험은 없더라, 나름 쓸모있었단걸 - PM이 되고서 & 만 5년 뒤에 달라진 관점으로 업무를 바라보며 다시 한번 느꼈다.
그리고 커리어의 다음 단계였던 pm 시절의 QA 경험이나, 이후에 만난 QA들의 역할에 대해선 이어서 계속.
