기획자가 하는 QA와 개발자가 하는 테스트는 이름만 같고 보는 층이 다릅니다. 개발자는 만든 대로 도는지를 보고, 기획자는 의도한 게 맞는지를 봅니다. 그래서 한쪽이 다른 쪽을 대신할 수 없습니다.
일정이 급할 때 이런 제안이 나옵니다. 테스트는 저희가 할 테니 개발에 집중해 주세요. 아껴주려고 꺼낸 말인데 개발자 표정이 어색해지는 자리가 여기입니다. 기획자가 말한 테스트는 다 만든 걸 놓고 사용자 눈으로 확인하는 최종 검증이고, 개발자가 말한 테스트는 만드는 내내 자기가 짠 코드가 제대로 도는지 확인하는 일입니다. 같은 단어인데 가리키는 게 다릅니다. 뒤쪽을 건너뛰면 속도가 붙는 게 아니라 값이 뒤로 밀립니다. 개발 초기에 잡으면 1이 드는 버그가 QA 단계에서는 10, 출시된 뒤 사용자가 발견하면 100 이상으로 불어난다는 오래된 계산이 있습니다.
그래서 체크 항목도 두 층으로 갈립니다.
개발자 쪽에서 이미 보고 있는 것. 값이 제대로 저장되는지, 잘못된 입력이 들어와도 화면이 깨지지 않는지, 이번에 바꾼 코드가 멀쩡하던 다른 기능을 건드리지 않았는지.
기획자가 봐야 하는 것. 지금 이 화면이 기획서에 그려둔 그 화면이 맞는지, 버튼과 안내 문구가 우리가 정한 그 표현인지, 권한 없는 사람이 이 메뉴를 열었을 때 어떻게 되는지, 그리고 만들다 보니 슬그머니 달라진 데가 없는지.
앞의 것을 기획자가 다시 들여다볼 필요는 없습니다. 뒤의 것을 개발자가 놓치는 건 실력 문제가 아니고요. 남이 보면 대번에 보이던 것도 내 일이 되면 판단이 잘 안 섭니다.
층이 갈린다는 걸 가장 잘 보여주는 건 다 되는데 틀린 경우입니다. 세 단계를 거쳐 신청이 끝나는 화면이라면 각 단계는 눌리는 대로 동작하고 값도 잘 넘어갑니다. 그런데 순서가 기획서와 다릅니다. 확인 화면이 결제 앞이 아니라 뒤에 붙어 있는 식이요. 개발자가 아무리 꼼꼼히 테스트해도 이건 안 걸립니다. 코드는 시킨 대로 돌고 있으니까요. 무엇을 의도했는지 아는 사람만 볼 수 있는 자리입니다. 항목이 그렇게 나뉘는 건 누가 더 성실한가의 문제가 아니라 볼 수 있는 사람이 다르기 때문입니다.
항목표에 없는 것도 걸립니다. 같은 작업이 주간 보고에 세 번째 올라오거나, 아직 작업 중이라는 답이 반복되거나, 설명에 갑자기 기술 용어가 늘어나는 때요. QA 담당자에게서 이 상태로는 못 내겠다는 말이 나오면 그건 의견이 아니라 신호에 가깝습니다. 그런 건 대개 항목보다 먼저 옵니다.
찾은 걸 넘기는 방식도 결과를 바꿉니다. 틀린 것만 모아 목록으로 던지면 검사받는 기분이 되고, 그러면 다음부터는 다 만든 뒤에야 보여줍니다. 가장 비싼 시점에만 문제를 만나게 되는 겁니다.
물론 이렇게 나눠 적어도 현장에서는 섞입니다. 저도 급할 때 그 말을 먼저 꺼내는 쪽입니다.
테스트라는 단어 하나가 이렇게 멀 줄은 몰랐습니다.