주니어 PM의 좌충우돌 TC 도입 실패 연대기
전 회사에서 서비스기획/PM 업무와 함께 QA 테스트까지 도맡아 진행했었다. 여기서 조금 부끄럽지만 솔직한 고백을 하나 하자면, 놀랍게도 당시 우리 팀에는 규격화된 TC(Test Case) 문서가 존재하지 않았다. (사실 지금도…)
그렇다면 그동안 테스트는 어떻게 진행해 왔을까? 오로지 담당자의 감과 기억력, 그리고 개발 요청사항이 적혀 있는 Jira 티켓에 의존한 파편화된 테스트가 전부였다. 서비스 규모가 작은 초기에는 이 방식이 통했을지도 모른다. 하지만 내가 담당했을 무렵, 서비스들은 이미 런칭한 지 각각 10년, 5년 가까이 되어 방대한 스케일을 자랑하고 있었다. 담당자들의 머릿속에서 구전 설화처럼 전해져 내려오는 테스트 시나리오만으로는 한계에 부딪힐 수밖에 없었다.
서비스의 덩치가 커지면서 QA 과정은 매번 살얼음판을 걷는 기분이었다.
여기에 규모가 조금이라도 큰 기능이 추가될 때면 고통은 배가 됐다. 버그 수정 후 테스트를 여러 번 진행해야 하는데, 시나리오가 없으니 “아까 이거 눌렀었고, 저 조건 확인했었고…” 하며 마치 내 지능을 시험하듯 오직 기억에만 의존해 똑같은 과정을 무한 반복해야 했다.
결국 규격화된 TC는 단순히 QA를 꼼꼼하게 하기 위한 목적을 넘어, 프로덕트의 품질을 보증하고 기획자와 개발자의 피로도를 보호하는 최소한의 안전망이라는 것을 깨달았다.
‘다국어 지원’이라는 대규모 프로젝트를 진행하며, 더 이상 과거의 방식으로는 버틸 수 없다는 위기감에 직접 팔을 걷어붙였다. 다른 기업들은 어떤 툴을 쓰고 어떤 포맷으로 TC를 작성하는지 닥치는 대로 레퍼런스를 뒤졌다. 엑셀부터 Jira 연동 툴까지 짧은 시간 내 다양한 방식을 검토한 끝에, 우리 팀 규모에 맞는 적절한 템플릿을 세팅했다.
* Column
- ID, 대분류, 중분류, 테스트 항목 (Test Case), 사전 조건, 테스트 절차, 예상 결과, 플랫폼, 언어, 결과,
실제 결과 (실패 시), 테스터, 테스트 일자, 비고
* 작성 예시
- ID: COM-UX-001_WEB-KO (카테고리-기능orUI-플랫폼-언어)
- 대분류 > 중분류: 공통 > UX 정책
- 테스트 항목: [이탈 방지] 회원가입 폼 작성 중 화면 이탈 시도
- 사전 조건: 1. 회원가입 폼 진입 상태 2. 폼에 글자가 한 번이라도 입력된 상태 (썼다 지운 상태도 포함)
- 테스트 절차: 1. '뒤로 가기' 버튼 선택 2. 다른 메뉴 선택 3. 창 닫기 시도 4. 브라우저 새로고침
- 예상 결과: 1~3. "사이트에서 나가시겠습니까? 변경사항이 저장되지 않을 수 있습니다." 시스템 얼럿 표시
4. "사이트를 새로고침하시겠습니까? 변경사항이 저장되지 않을 수 있습니다." 시스템 얼럿 표시
- 플랫폼: WEB/MWEB/iOS/AOS
- 언어: 한글/영어
- 결과: Fail/나름대로 플랫폼과 다국어 환경까지 꼼꼼하게 고려해 체계적인 ID 식별자 규칙까지 세워둔, 꽤나 야심찬 템플릿이었다. 하지만 대망의 첫 TC 작성은 곧바로 거대한 현실의 벽에 부딪히고 말았다. 이미 수년간 겹겹이 쌓여온 서비스의 방대한 기능들을, 애초에 존재하지도 않던 시나리오로 처음부터 역산해서 만들어내려니 엄청난 막막함이 밀려왔다. 쏟아지는 업무 속에서 틈틈이 기존 화면들을 일일이 눌러가며 엑셀 칸을 채워나가는 과정은, 끝이 보이지 않는 데다 누구도 알아주지 않아 참으로 외로운 싸움이었다.
어느 정도 초안이 잡혀가고 있을 무렵, 매일 하는 업무 보고에 이 TC 문서화 작업에 대한 내용을 적었다. 하지만 돌아온 답변은 차가웠다.
“지금 당장 쳐내야 할 우선순위가 얼마나 많은데, 그걸 왜 지금 하고 있어요?”
당장의 비즈니스 임팩트와 신규 기능 배포가 중요한 상황. 눈에 보이는 성과가 없는 문서화 작업은 경영진 입장에서 리소스 낭비로밖에 보이지 않았던 것이다. 결국 나 역시 산더미처럼 쌓인 당장의 기획 업무와 CS에 치여, 야심차게 시작했던 TC 도입은 흐지부지 멈추고 말았다.
결과적으로 전 회사에서의 TC 전면 도입은 실패로 끝났다. 사실 돌이켜보면 당연한 수순이었을지도 모른다. 당시 회사는 TC만 없는 게 아니라, 기능정의서도 정책서도 존재하지 않는 말 그대로 문서화 ZERO의 척박한 맨바닥이었으니까. 기능은 이미 고도화될 대로 고도화된 상태인데, 기준점이 될 문서가 단 하나도 없었다. (이 답 없는 문서화 불모지에서 서비스별, 기능별로 무려 25건의 정책서를 연성해 낸 눈물겨운 사투는 다음 포스트에서 따로 풀어볼 예정이다.)
비록 이 프로젝트는 씁쓸한 결말을 맞았지만, 이 거대한 레거시와의 싸움은 주니어 PM이었던 나에게 아주 중요한 세 가지 교훈을 남겼다.
기능을 만들 때 기획서와 TC를 함께 작성해두지 않으면, 나중에 이를 소급해서 문서화할 때 몇 배의 시간과 고통이 따른다. ‘시간 날 때 정리하지 뭐’라는 안일한 생각은 결국 레거시의 늪이 되어 돌아온다 ^^…
개발이 다 끝난 뒤에 화면의 버튼을 눌러가며 테스트 시나리오를 짜는 것은 너무 늦다. 애초에 기획 단계에서 엣지 케이스와 예외 처리를 꼼꼼히 정의해 두어야 자연스럽게 훌륭한 TC로 이어진다.
아무리 실무 진영에서 꼭 필요한 시스템 개선이라 할지라도, 모든 프로젝트에는 타이밍과 우선순위가 있다. 당장 눈앞의 매출과 배포, 성과가 시급한 상황에서 과거 개발된 기능의 문서화 작업은 경영진에게 절대 매력적인 카드가 아니었다. 설득의 문제가 아니라 애초에 타이밍이 어긋났던 것이다. 억울하기도 했지만, 회사의 리소스는 한정되어 있고 PM은 철저하게 비즈니스의 우선순위를 고려해 움직여야 한다는 현실을 배웠다.
이때의 지독했던 경험은 이후 내가 새로운 프로젝트를 기획할 때마다 처음부터 테스트 가능한 기획, 테스트가 쉬운 기획을 최우선으로 두게 만든 아주 소중한 자양분이 되었다. 앞으로도 모든 것이 완벽하게 갖춰진 환경에서 일할 수 있는 날은 드물겠지만, 적어도 내가 만드는 프로덕트만큼은 누군가의 기억력 테스트에 의존하지 않도록 꼼꼼하고 치밀하게 문서화해 나가고 싶다. ☺️