‘테스트 완료’라는 말 앞에서 다시 묻다

『37초』의 프롤로그는 실제로 일어난 세 사건에서 출발한다. 1996년 아리안 5호의 발사 실패, 1986년 방사선 치료기 테라크-25의 과다 피폭 사고, 2022년 판교 데이터센터 화재로 인한 카카오 서비스 장애다. 카카오의 전체 서비스와 기능이 복구되기까지는 약 127시간이 걸렸다.

책은 이 사건들을 통해 이전의 검증과 익숙한 사용 조건만으로 시스템의 안전을 확신할 수 있는지 묻는다. 확인한 사실과 확인했다고 믿는 것 사이에는 어떤 빈틈이 있는가. 그 빈틈을 찾기 위해 무엇을 살펴야 하는가.

“사소한 ‘오류(Error)’가 ‘결함(Defect)’으로 숨어들고, 그 결함이 ‘장애(Failure)’로 터져 나오기까지. 그 아슬아슬한 연쇄 반응을 끊어낼 방어선, 그곳에 테스팅(Testing)이 있다.”

QA 엔지니어는 무슨 일을 하는가

QA를 처음 배우면 용어만큼이나 낯선 질문들을 마주하게 된다. 어디까지 테스트해야 하는가. 무엇을 먼저 확인해야 하는가. 언제 테스트를 끝내도 되는가. 테스팅 이론을 알아도 실제 업무에서 이런 질문에 답하기는 쉽지 않다. 『37초』는 준호가 판단의 근거를 찾아가는 과정을 보여 준다.

할인율 10·20·50%를 확인하고 출시한 쿠폰 기능에서 0원 결제가 발생한다. 준호는 화이트보드에 적힌 세 숫자 양쪽에 0과 100이 더해지고 나서야 자신이 놓친 경계를 알아차린다. 200개 항목을 채운 체크리스트를 앞에 두고도 “이 200개가 전부라는 건 어떻게 알아요?”라는 질문에는 답하지 못한다. 준호는 이런 시행착오를 겪으며 테스트할 대상을 분석하고, 확인할 조건을 설계하고, 실행할 순서를 정하는 법을 배운다.

배움이 쌓일 때마다 준호의 〈QA 엔지니어링 체크리스트〉에도 질문이 한 줄씩 늘어난다. ‘요구사항을 읽었는가’, ‘경계를 확인했는가’, ‘지도 밖을 걸었는가’. 독자는 이 질문들을 따라가며 각 테스트 기법이 왜 필요한지, 어떤 상황에서 쓰이는지 이해하게 된다.

준호의 동료들도 각자의 자리에서 제품을 고민한다. 개발자는 정해진 시간 안에 기능을 완성해야 하고, PM은 출시 일정과 품질, 경쟁사의 움직임을 함께 살펴야 한다. 『37초』는 결함이 미칠 영향을 설명하고, 서로 다른 관점을 조율하며, 팀과 함께 품질을 높여 가는 과정까지 보여 준다. 독자는 테스트 기법과 함께 QA가 동료들과 일하는 방식도 살펴볼 수 있다.

QA의 첫걸음을 준비하는 독자에게

황민은 12년간 소프트웨어 품질 분야에서 일하며 쌓은 현장 경험을 바탕으로 『37초』의 장면들을 구성했다. QA 엔지니어라면 한 번쯤 마주했을 상황들이 준호의 고민 속에서 구체적으로 그려진다.

책 앞머리에는 출간 전 원고를 읽은 현직 QA·테스트 엔지니어 세 사람의 추천사를 실었다. QA 엔지니어 수비는 “이 책을 읽고 나서는 ‘이거 한번 읽어보세요’라고 건넬 수 있게 됐습니다”라고 썼다. 테스트 엔지니어 조성혁은 “길을 잃은 주니어들에게, 이 책은 훌륭한 나침반이 되어 줍니다”라고 평했다. 5년 차 QA 엔지니어 황혜빈은 “QA의 경험이 없는 분들에게는 간접 경험을, QA의 경험이 있는 주니어 분들에게는 내가 처음 QA를 해나가던 감각을 일깨우는 책이라고 말할 수 있겠네요”라고 전했다.

모든 경우를 빠짐없이 테스트할 수는 없다. 그래서 테스터는 무엇을 확인했고 무엇을 아직 확인하지 못했는지, 다음 단계로 넘어가도 되는 근거는 무엇인지 설명할 수 있어야 한다. 『37초』는 QA라는 일을 처음 마주한 독자가 이런 판단의 기초를 쌓도록 돕는다.