안녕하세요, 라포랩스 QA Engineer 변유진입니다. 지난 아티클 [E2E 자동화 리팩토링으로 만든 QA 시스템]에 이어, 이번에는 테스트 데이터 생성 자동화를 구현한 사례를 공유합니다.
QA를 하다보면 테스트 자체보다, 테스트를 시작하기 위한 준비에 더 많은 시간을 쓰는 경우가 많습니다. 특히 주문 상태별 테스트 데이터를 만드는 과정이 그렇습니다. 이 아티클에서는 여러 번의 시행착오 끝에, 버튼 하나로 원하는 주문 상태를 만들 수 있게 되기까지의 과정을 공유합니다.
반품 검수 상태 하나를 만들기까지
이커머스 서비스를 테스트하려면 다양한 상태의 주문 데이터가 필요합니다. 배송 준비중, 배송 완료, 반품 요청, 교환 진행 중…
문제는 이 모든 상태를 실제 흐름 그대로 만들기 위해서 꽤 많은 단계를 거쳐야 한다는 점입니다. 앱에서 상품을 구매하고, 어드민 페이지에서 배송 처리를 하고, 다시 앱으로 돌아가 반품 요청을 하기까지의 과정을 직접 거쳐야 하죠.
QA팀에서 취소/교환/반품 테스트를 수행할 때마다 이 과정을 반복해야 했고, 이는 Release QA에서도 마찬가지였습니다. QA 엔지니어뿐 아니라 개발자, PO까지 모두 같은 번거로움을 감수하고 있었죠.
도구는 있었다. 그런데 안 쓰였다.
처음에는 Postman을 사용했습니다. 쿠폰 발급, 주문 생성 등 자주 사용하는 API를 환경별로 정리해두고, 필요할 때 호출하는 방식이었죠.
하지만 시간이 지나면서 문제가 생겼습니다. 자주 쓰지 않다 보니 오랜만에 열면 API가 deprecated되어 있거나, 스펙이 바뀌어 있는 경우가 많았어요. 그러다 보니 Postman을 수정하기보다 그냥 직접 테스트 데이터를 만들어 쓰게 되었고요. Google Drive에 올려둔 JSON 파일을 각자 로컬에 다운받아 사용하는 구조라 유지보수도 어려웠습니다.
그래서 Python 스크립트로 옮겼습니다. E2E 자동화 테스트는 꾸준히 관리하고 있었기 때문에, Postman에 있던 기능들을 E2E 레포지토리로 옮기면 더 잘 관리할 수 있을 거라 기대했죠.
하지만 여전히 문제는 남아 있었습니다. 테스트 데이터를 만들기 위해서는 레포지토리를 클론해야 하고, 로컬에서 스크립트를 직접 실행해야 했어요. 특히 개발자가 아닌 구성원에게는 여전히 진입 장벽이 높았죠. 결국 만들어둔 도구는 다시 쓰이지 않게 되었습니다.
이미 있던 대시보드를 활용하면?
전환점은 의외로 이미 사용 중이던 도구에서 나왔습니다. E2E 자동화 테스트를 쉽게 실행하기 위해 만들어둔 웹 대시보드였는데요. 원하는 환경과 시나리오를 선택하면 테스트가 실행되고, 결과 리포트를 바로 확인할 수 있는 구조였죠.
이 대시보드를 쓰다보니 새로운 요구사항이 보이기 시작했습니다. E2E 시나리오는 "주문 생성 → 배송 완료 → 반품 완료"처럼 전체 플로우를 검증하는 데 초점이 맞춰져 있었는데, 실제로 사람들이 원하는 건 조금 달랐거든요.
"배송 준비중 상태만 바로 만들고 싶어요", "특정 상품을 주문하고 싶어요"
여기서 아이디어가 떠올랐습니다. 이미 E2E 자동화에서 호출하고 있는 API를 조합하면, 원하는 상태의 테스트 데이터를 쉽게 만들 수 있지 않을까?
버튼 하나로 주문 상태 만들기
기존 E2E에서 사용하던 주문 API들을 조합해, 대시보드에 원하는 상태의 주문을 구현하는 버튼을 대시보드에 추가했습니다.
배송, 취소, 교환, 반품 각 단계를 클릭 한 번으로 생성할 수 있고, 커스터마이징 옵션도 제공했어요. 원하는 상품 ID, 수량, 적립금 사용 여부, 배송지도 선택할 수 있고요. 그리고 주문 내 특정 order line에 대해서만 반품이나 교환 요청을 걸 수도 있어요.
예를 들어 이런 테스트 시나리오가 있다고 가정해 볼게요.
여러 브랜드의 상품을 구매한 뒤,
하나는 반품하고 하나는 교환하고,
마지막 반품 시 반품비가 어떻게 달라지는지 확인하고 싶다.
이전에는 실제 구매부터 반품/교환 요청까지 모든 단계를 직접 거쳐야 했지만, 이제는 원하는 상태의 주문을 바로 만들어 검증할 수 있습니다.
주문 케이스 10개, 1분이면 된다.
돌이켜보면 Postman도 Python 스크립트도 기술적으로는 나쁘지 않았습니다. 하지만 QA팀 내에서조차 잘 쓰이지 않았죠.
대시보드는 달랐습니다. 링크 하나로 접근할 수 있거든요. 개발자와 PO도 사용하기 시작했고, 지금은 다른 팀에서 먼저 기능 추가 요청이 들어옵니다.
이 경험을 통해 확실하게 느낀 게 하나 있습니다. 가장 중요한 건 기술적 완성도가 아니었어요. 진입 장벽을 낮추는 것, 얼마나 쉽게 쓰이느냐가 관건이라는 것입니다. 도구는 쓰여야 의미가 있으니까요.
테스트 데이터를 만드는 일이 더이상 테스트의 출발점이 아니게 되었습니다. 이제 QA 엔지니어는 테스트 데이터를 만드는 데에 쓰던 시간을, 테스트 설계와 리스크 판단에 씁니다. “어떻게 데이터를 만들지”보다 “무엇을, 왜 검증할지”에 집중할 수 있게 되었습니다.