본문으로 건너뛰기
중급18

경험 기반 기법 — 오류 추정과 체크리스트

명세가 부실하거나 시간이 부족할 때, 과거에 자주 터졌던 결함 패턴을 근거로 빠르게 테스트 범위를 채우는 법을 익힌다.

  • #경험기반
  • #오류추정
  • #체크리스트
  • #테스트설계

개념

명세 기반 기법은 명세가 명확해야 힘을 발휘하고, 구조 기반 기법은 코드 접근이 필요하다. 둘 다 여의치 않을 때 — 명세가 부실하거나, 시간이 급박하거나 — 경험 기반 기법이 빈틈을 채운다.

오류 추정 (Error Guessing)

"짐작"이라고 하면 즉흥적으로 들리지만, 오류 추정은 과거에 반복적으로 발견됐던 결함 패턴을 체계적으로 적용하는 것이다. 아무 입력창에나 적용할 수 있는 대표적인 패턴들이 있다.

  • 빈 값, 공백만 입력
  • 매우 긴 문자열
  • 특수문자, 이모지, 다국어 문자
  • 0, 음수, 매우 큰 숫자
  • 같은 요청을 짧은 시간에 여러 번 (중복 클릭, 동시 요청)
  • 네트워크가 중간에 끊기는 경우
  • 뒤로가기·새로고침으로 흐름을 이탈하는 경우

이 목록은 어느 특정 기능의 명세에서 나온 게 아니다 — "소프트웨어는 대체로 이런 지점에서 잘 깨진다"는 누적된 경험에서 나왔다. 동등분할이 "이 요구사항 안에서" 파티션을 나눈다면, 오류 추정은 "요구사항 밖에서" 일반적으로 위험한 지점을 가져온다.

체크리스트 기반 테스트

오류 추정을 팀 차원에서 재사용 가능하게 만든 것이 체크리스트다. "폼 검증 체크리스트", "결제 화면 체크리스트"처럼 자주 반복되는 화면 유형별로 미리 만들어둔 확인 목록이다.

폼 검증 체크리스트 (일부)

  • 필수 입력 필드를 비운 채 제출하면 막히는가
  • 최대 길이를 초과하면 어떻게 되는가
  • 제출 버튼을 여러 번 빠르게 클릭하면 중복 제출되는가
  • 제출 중 페이지를 벗어나면 어떻게 되는가

새 기능을 테스트할 때마다 이 체크리스트를 훑어보면, 매번 처음부터 생각해낼 필요 없이 팀이 과거에 겪었던 결함 유형을 빠르게 재적용할 수 있다.

탐색적 테스팅과는 다르다

경험 기반 기법(오류 추정, 체크리스트)은 미리 목록을 만들어두고 그대로 적용한다는 점에서, 실행하면서 동시에 다음에 뭘 볼지 즉흥적으로 판단하는 **탐색적 테스팅(모듈 5)**과 다르다. 오류 추정 체크리스트가 "정해진 질문지를 들고 확인하는 것"이라면, 탐색적 테스팅은 "질문지 없이 직접 돌아다니며 새로운 질문을 그 자리에서 만들어가는 것"에 가깝다. 둘은 상호 보완적이며, 이 커리큘럼의 모듈 5에서 탐색적 테스팅을 훨씬 깊게 다룬다.

실무에서 왜 필요한가

실무에서 명세가 완벽한 경우는 드물다(모듈 2에서 이미 다뤘다). 명세에 없는 부분까지 경험 기반 기법으로 채워두면, 사용자가 실제로 마주칠 흔한 문제(중복 클릭, 특수문자 입력 등)를 사전에 잡을 수 있다. 특히 릴리즈 직전처럼 시간이 없을 때, 체크리스트는 "무엇을 확인했고 무엇을 못 했는지"를 빠르게 파악하게 해주는 실용적인 안전망이다.

실습 과제

과제 1 — 체크리스트 만들기 (12분)

"파일 업로드" 기능에 대해 오류 추정 체크리스트를 5개 이상 작성한다. (힌트: 파일 크기, 형식, 개수, 업로드 중 취소, 동시 업로드 등을 생각해본다.)

과제 2 — 기법 구분하기 (8분)

과제 1에서 만든 체크리스트 항목 중, 동등분할·경계값 분석으로도 만들 수 있었던 항목순수하게 경험에서만 나올 수 있었던 항목을 구분해본다. (힌트: "파일 크기 0바이트"는 경계값에 가깝고, "업로드 중 네트워크 끊김"은 경험에 더 가깝다.)

자가 체크리스트

  • 오류 추정이 "즉흥적 짐작"이 아니라 "누적된 경험의 체계적 적용"임을 설명할 수 있다
  • 체크리스트 기반 테스트가 팀 차원에서 왜 유용한지 설명할 수 있다
  • 경험 기반 기법과 탐색적 테스팅의 차이를 설명할 수 있다
  • 주어진 기능에 대해 오류 추정 체크리스트를 직접 작성할 수 있다

흔한 실수

  • 경험 기반 기법을 "제대로 된 테스트 설계가 아니다"라고 낮게 본다. 명세 기반 기법으로 커버 안 되는 실제 결함 패턴을 잡아주는, 엄연히 독립적인 기법이다.
  • 체크리스트를 한 번 만들고 갱신하지 않는다. 새로운 유형의 결함이 발견되면 체크리스트에 추가해야 계속 쓸모가 있다 — 팀의 결함 이력이 쌓일수록 체크리스트도 함께 자라야 한다.
  • 체크리스트만 믿고 그 기능만의 고유한 리스크를 놓친다. 체크리스트는 "일반적으로" 자주 터지는 패턴이다. 그 기능만의 특수한 리스크는 여전히 다른 기법(리스크 기반 테스트, 모듈 4)으로 별도로 봐야 한다.

참고 자료