1. 오늘 지운 테스트케이스 하나가, 누군가의 주문 실패 하나를 막는다

1. 오늘 지운 테스트케이스 하나가, 누군가의 주문 실패 하나를 막는다

쇼핑몰 QA의 하루는 숫자로 시작되는 경우가 많습니다.

테스트케이스 327개.
Regression 186개.
남은 Blocker 4건.
Jira에 등록해야 할 버그 7건.

로그인하고, 상품을 검색하고, 상세 페이지에 들어갑니다. 옵션을 바꿔보고 장바구니에 담습니다. 쿠폰을 적용하고, 배송지를 변경하고, 결제 버튼을 누릅니다. 다시 취소하고, 다른 계정으로 들어갑니다. 브라우저를 바꾸고, 모바일 기기를 바꿉니다.

어제도 비슷한 일을 했고 오늘도 비슷한 일을 합니다.

체크박스 하나를 Pass로 바꾸고 다음 케이스로 넘어갑니다.

그러다 어느 순간 이런 생각이 들 수 있습니다.

‘내가 지금 뭘 하고 있는 거지?’

특히 수백 개, 수천 개의 테스트케이스를 하나씩 실행하는 시기가 길어지면 QA의 일은 쉽게 ‘확인 작업’처럼 느껴집니다.

버그를 발견해도 해야 할 일이 더 생길 뿐입니다.

재현합니다.
스크린샷을 찍습니다.
환경을 적습니다.
재현 절차를 정리합니다.
Expected Result와 Actual Result를 씁니다.
Severity와 Priority를 고민하고 Jira에 등록합니다.

며칠 뒤 개발팀이 수정하면 다시 확인합니다.

그리고 Pass.

끝입니다.

그러니 QA라는 일이 때로 소모적으로 느껴지는 것은 이상한 일이 아닙니다.

전자책에서는 사람이 일에 흥미를 잃는 이유 중 하나를 ‘내가 하는 일이 전체 결과에 어떻게 연결되는지 보이지 않는 상태’에서 찾습니다. 주어진 업무를 그대로 반복하면 자신이 창작자가 아니라 단순한 대행자처럼 느껴질 수 있다는 것입니다.

QA에게도 이 관점이 중요합니다.

테스트케이스의 마지막 열에는 단순히 PASS라고 적히지만, 그 한 글자 뒤에는 실제 사용자의 경험이 있습니다.

당신이 결제수단 변경 테스트에서 발견한 오류 하나는 누군가의 결제가 두 번 이루어지는 일을 막을 수 있습니다.

장바구니 수량 변경에서 발견한 버그 하나는 고객이 주문하려던 상품의 수량이 잘못 전달되는 일을 막을 수 있습니다.

쿠폰 적용 조건을 꼼꼼하게 확인한 덕분에 특정 고객에게 엉뚱한 할인이 적용되는 일을 예방할 수 있습니다.

배송지 변경 후 주문정보가 제대로 갱신되는지 확인한 덕분에 다른 주소로 상품이 배송되는 사고를 막을 수도 있습니다.

검색, 장바구니, 주문, 결제, 배송, 취소, 환불.

사용자에게는 하나의 자연스러운 쇼핑 과정이지만 QA에게는 수백 개의 조건과 분기로 나뉩니다.

그리고 누군가는 그 분기를 끝까지 걸어봐야 합니다.

그 사람이 QA입니다.

개발자는 기능을 만듭니다.

기획자는 사용자가 어떤 경험을 해야 하는지 정의합니다.

QA는 그 둘 사이에서 마지막 질문을 던집니다.

“정말 그렇게 동작하는가?”

이 질문은 생각보다 무겁습니다.

수천 개의 테스트케이스를 실행한다는 것은 수천 번 제품에게 같은 질문을 던지는 일입니다.

“정말 괜찮아?”

“이 조건에서도?”

“이 계정에서도?”

“이 브라우저에서도?”

“쿠폰을 두 개 가지고 있어도?”

“재고가 하나만 남았어도?”

“결제 직전에 네트워크가 끊겨도?”

누군가는 이 질문을 집요하게 해야 합니다.

서비스는 보통 정상적인 상황에서는 잘 작동합니다.

문제는 정상적이지 않은 순간에 생깁니다.

사용자는 우리가 작성한 테스트 시나리오대로 움직이지 않습니다. 뒤로 가기를 누르고, 버튼을 두 번 누르고, 결제 중 앱을 종료하고, 배송지를 바꾸고, 이미 품절된 상품을 장바구니에 남겨둡니다.

그리고 QA는 그 상황을 미리 살아보는 사람입니다.

그래서 오늘 테스트케이스 200개를 수행했는데 버그를 하나도 발견하지 못했다고 해서 아무것도 하지 않은 날이 아닙니다.

200개의 조건에서 사용자가 정상적으로 쇼핑할 수 있다는 사실을 확인한 날입니다.

반대로 버그를 발견했다면 실패한 것도 아닙니다.

운영 환경에서 고객이 발견하기 전에 QA 환경에서 먼저 발견한 것입니다.

그것이 QA가 존재하는 이유입니다.

그러니 오늘 마지막 테스트케이스를 Pass 처리하고 퇴근하면서 숫자만 보지 않았으면 좋겠습니다.

오늘 완료한 327개의 TC는 단순히 327개의 체크박스가 아닙니다.

327번의 확인입니다.

327번의 의심입니다.

327번의 방어입니다.

그리고 그 수많은 작은 확인들이 모여 우리가 아무 생각 없이 누르는 ‘결제하기’ 버튼 하나를 믿을 수 있게 만듭니다.

---

 

#QA엔지니어 #소프트웨어QA #품질보증 #테스트케이스 #이커머스 #쇼핑몰개발 #서비스품질 #사용자경험 #직장인에세이 #일의의미 #업무몰입 #IT직군 #테스터 #버그관리 #제품품질