개념
화면이 없어도 탐험할 게 있다
지금까지의 탐험은 대부분 화면을 클릭하는 방식이었다. 하지만 API나 백엔드 서비스처럼 화면 자체가 없는 대상도 얼마든지 탐험할 수 있다. Postman이나 Insomnia 같은 도구로 API에 직접 요청을 보내며 실시간으로 반응을 관찰하고, 그 관찰을 근거로 다음 요청을 결정하는 것도 똑같은 탐색적 테스팅이다.
API를 탐험한다는 것
문서화된 정상 요청("행복 경로")을 넘어서 다음을 시도해본다.
- 필수 필드를 빼고 요청하면 어떤 에러가 오는가, 에러 메시지가 실제로 무엇이 잘못됐는지 알려주는가
- 잘못된 타입을 넣으면(숫자 필드에 문자열) 어떻게 되는가
- 문서에 없는 추가 필드를 넣으면 무시되는가, 에러가 나는가, 혹시 반영되어 버리는가(보안 문제일 수 있다)
- 같은 요청을 다른 HTTP 메서드로 보내면(GET으로 되어야 할 걸 POST로)
- 인증 토큰 없이, 혹은 만료된 토큰으로 요청하면
- 페이지네이션 파라미터에 음수나 매우 큰 수를 넣으면
- 응답을 상태 코드뿐 아니라 본문(body)과 헤더까지 함께 확인한다
모듈 12와는 무엇이 다른가
모듈 12(API·계약 테스트)는 체계적으로 설계된 API 테스트(계약 검증, 자동화)를 다룬다. 이 레슨은 그 전 단계 — 아직 체계가 안 잡힌 상태에서 실시간으로 API를 찔러보며 감을 잡는 탐색적 활동이다. 둘은 순서상으로도 자연스럽게 이어진다 — 탐험하며 발견한 흥미로운 케이스가, 나중에 모듈 12에서 배울 자동화된 API 테스트의 재료가 된다.
실무에서 왜 필요한가
백엔드 결함은 화면에 간접적으로만 드러나는 경우가 많아서, 화면만 보는 QA는 원인을 못 찾고 "뭔가 이상한데 왜인지 모르겠다"는 상태에 머문다. API를 직접 탐험할 수 있는 QA는 "화면에서 이상하게 보이는 이유가 사실 API가 잘못된 값을 주고 있어서"라는 것까지 스스로 밝혀낼 수 있다. 이건 QA의 역할을 넓히는 실질적인 역량이고, 백엔드/API 테스트 비중이 커지는 채용시장 흐름과도 맞닿아 있다(모듈 9에서 다룰 개발 지식과 직결된다).
실습 과제
과제 1 — 탐험 질문 만들기 (12분)
POST /orders (주문 생성) API가 있다고 하자. 문서화된 정상 요청을
벗어난 탐험 질문(위 목록 참고)을 최소 6개 만든다.
과제 2 — 예상과 확인 항목 정하기 (10분)
과제 1의 질문 중 하나를 골라, "정상적으로 잘 만들어졌다면 어떤 응답이 와야 하는가"를 예상해 적고, 응답의 상태 코드·본문·헤더 중 무엇을 확인할지 정리한다.
자가 체크리스트
- 화면이 없는 API도 탐색적 테스팅의 대상이 될 수 있다는 것을 이해한다
- API 탐험 시 시도해볼 수 있는 최소 5가지 방향을 나열할 수 있다
- 이 레슨과 모듈 12(API·계약 테스트)의 차이(탐색적 vs 체계적 설계)를 설명할 수 있다
- 응답을 상태 코드뿐 아니라 본문·헤더까지 확인해야 하는 이유를 설명할 수 있다
흔한 실수
- 상태 코드만 보고 넘어간다. 200이 와도 본문 안의 데이터가 잘못됐을 수 있다 — 레슨 4에서 배운 "화면은 성공, 실제로는 실패" 패턴이 API 레벨에서도 그대로 일어난다.
- API는 개발자 영역이라 QA가 볼 필요 없다고 생각한다. 화면으로 보이는 결함의 원인이 API에 있는 경우가 흔해서, API를 직접 볼 수 있으면 원인 파악 속도가 크게 빨라진다.
- 문서화된 정상 요청만 몇 번 보내보고 끝낸다. 그건 확인이지 탐험이 아니다 — 문서 밖의 요청을 시도해야 새로운 것을 발견한다.
참고 자료
- Postman Learning Center — API를 직접 탐험할 때 쓰는 대표 도구의 공식 학습 자료
- Elisabeth Hendrickson, Explore It! — API를 포함한 "화면 없는 시스템" 탐험을 다룬 장