개념
화면이 멀쩡해도 실패했을 수 있다
탐색적 테스팅의 성패는 관찰력에 달려 있다 — 아무리 잘 탐험해도, 이상한 걸 알아채지 못하면 아무 소용이 없다. 그런데 UI는 종종 실패를 숨긴다.
사용자가 "저장" 버튼을 누른다. 화면에 "저장되었습니다" 메시지가 뜬다. 하지만 실제로는 서버가 500 에러를 반환했고, 프론트엔드 코드가 그 에러를 제대로 처리하지 못해 무조건 "성공" 메시지를 띄우게 되어 있었다.
화면만 보면 이 결함은 절대 안 보인다. 화면 뒤에서 실제로 무슨 일이 일어났는지까지 봐야 한다.
열어두고 탐험해야 할 것들
- 브라우저 개발자 도구 콘솔: JavaScript 에러, 경고 메시지가 화면에는 안 나타나도 여기엔 찍힌다.
- 네트워크 탭: 실제 API 요청과 응답을 확인한다. 화면에 표시된 값과 실제 응답 데이터가 다르다면(예: 화면엔 10% 할인, 응답엔 0% 할인이 왔는데 프론트가 잘못 계산해 표시) 이것도 결함이다.
- 서버·애플리케이션 로그 (접근 가능하다면): 예외, 스택 트레이스가 여기 남는다. 화면엔 아무 문제 없어 보여도 서버 로그엔 에러가 쌓이고 있을 수 있다.
이걸 탐험 내내 습관적으로 곁눈질하는 것이 이 레슨의 핵심 기술이다. 탐험이 끝난 뒤에 확인하는 게 아니라, 액션을 취하는 동시에 계속 확인한다.
왜 이게 어려운가
화면에 집중하다 보면 콘솔이나 네트워크 탭을 잊기 쉽다. 그래서 의식적으로 **"이 액션을 하기 전에 개발자 도구를 열어둔다"**를 탐험 세션 시작 루틴으로 만드는 게 효과적이다. 화면과 콘솔을 나란히 두고 보는 것만으로도 발견하는 결함의 종류가 완전히 달라진다.
실무에서 왜 필요한가
"화면은 성공했다고 표시하지만 실제로는 실패한" 패턴은 실무에서 놀랍도록 흔하다 — 프론트엔드가 에러 처리를 제대로 안 했거나, 성공/실패를 판단하는 로직 자체에 결함이 있는 경우다. 이런 결함은 사용자에게 "잘 됐다고 나왔는데 나중에 보니 안 됐더라"는 최악의 경험을 준다. 화면만 보는 QA는 이걸 절대 못 잡는다. 이 습관은 모듈 9(HTTP·DOM 기초)와 모듈 14(관측성)에서 다룰 내용의 실전 버전이기도 하다.
실습 과제
과제 1 — 무엇을 확인할지 정하기 (8분)
탐험 세션을 시작하기 전, 화면 외에 열어둘 세 가지(콘솔, 네트워크 탭, 로그 등)를 정하고 각각에서 무엇을 확인할지 한 줄씩 적는다.
과제 2 — 시나리오 분석하기 (12분)
다음 상황을 읽고, 무엇을 확인해야 하는지, 그리고 이걸 어떻게 결함으로 보고할지 적는다.
회원가입 폼에서 "가입 완료" 버튼을 눌렀더니 화면에 "환영합니다!"라는 메시지와 함께 로그인 화면으로 이동했다. 그런데 다시 로그인을 시도하니 "가입되지 않은 이메일입니다"라는 오류가 뜬다.
자가 체크리스트
- 화면이 성공을 표시해도 실제로는 실패했을 수 있는 이유를 설명할 수 있다
- 탐험 중 화면 외에 확인해야 할 세 가지(콘솔, 네트워크, 로그)를 안다
- 화면 값과 실제 API 응답 값의 불일치를 어떻게 발견하는지 설명할 수 있다
- "화면은 성공, 실제로는 실패" 패턴이 왜 사용자 경험상 특히 나쁜지 설명할 수 있다
흔한 실수
- 탐험이 끝난 뒤에야 콘솔을 확인한다. 그 시점엔 이미 어떤 액션이 그 에러를 유발했는지 기억하기 어렵다. 실시간으로 함께 봐야 한다.
- 콘솔에 뜬 경고(warning)를 전부 무시한다. 에러가 아니라 경고라도, 반복적으로 뜨는 경고는 잠재적 문제의 신호일 수 있다.
- 네트워크 탭의 상태 코드만 보고 응답 본문(body)은 안 본다. 상태 코드가 200이어도 응답 본문 안의 데이터가 잘못됐을 수 있다.
참고 자료
- MDN — Chrome DevTools 콘솔 사용법 — 브라우저 개발자 도구 기본 사용법
- Elisabeth Hendrickson, Explore It! — "관찰의 기술"을 탐색적 테스팅의 핵심 역량으로 다루는 장