에러 추측이란 과거의 경험·버그 패턴·직감을 바탕으로 「버그가 발생하기 쉬운 값이나 조작」을 적극적으로 테스트하는 테스트 설계 기법입니다. 다른 기법으로는 찾기 어려운 버그를 보완하기 때문에 QA 엔지니어의 실무 경험이 품질에 직접 반영되는 기법입니다.
💡 한 마디로 말하면
에러 추측 ＝ 「「여기, 버그가 날 것 같다」는 경험과 직감을 테스트로 변환하는 기법」
에러 추측은 유일하게 「경험·직감·감」에 기반한 테스트 설계 기법입니다. 체계적인 기법이 놓치기 쉬운 「경험적으로 위험한 값」을 보완함으로써 테스트 스위트 전체의 품질을 한 단계 끌어올릴 수 있습니다.
📌 이런 분께 추천합니다
- 에러 추측의 개념과 실천적인 사용법을 배우고 싶은 QA 엔지니어
- 동등 분할·경계값 분석만으로는 부족하다고 느끼는 분
- 테스트 설계 기법 시리즈의 마지막 마무리를 알고 싶은 분
- 자신의 경험·직감을 테스트에 체계적으로 활용하고 싶은 분
✅ 이 글을 읽으면 얻을 수 있는 것
- 에러 추측의 개념과 다른 기법과의 차이를 알 수 있다
- 실무에서 자주 사용되는 「버그가 발생하기 쉬운 값」의 패턴 카탈로그를 알 수 있다
- 에러 추측을 다른 기법과 조합하는 실무 워크플로우를 알 수 있다
👤 이 글을 쓴 사람
QA 엔지니어·테스트 자동화 엔지니어로서 15년 이상의 실무 경험을 가진 Yoshi가 집필. 에러 추측은 매일의 테스트 설계에서 「다른 기법의 보완」으로서 활용하고 있으며 경험이 쌓일수록 정확도가 올라가는 기법입니다. 구현 코드는 GitHub에 공개 중입니다: github.com/YOSHITSUGU728/automated-testing-portfolio
동등 분할·경계값 분석·디시전 테이블·상태 전이 테스트——이 모든 것을 적용해도 아직 발견할 수 없는 버그가 있습니다. 왜일까요？
- 체계적인 기법은 「사양서에 쓰인 조건」에서 테스트 케이스를 도출한다
- 하지만 「사양서에 쓰이지 않은 함정」은 체계적인 기법으로는 찾기 어렵다
- 「NULL을 입력하면 어떻게 될까？」「공백 문자만 입력하면？」이라는 경험적인 질문이 중요
에러 추측은 이런 「경험칙에 기반한 질문」을 테스트 케이스로 변환하는 기법입니다. 이 글에서는 에러 추측의 개념·실천적인 버그 패턴 카탈로그·다른 기법과의 조합 방법까지 해설합니다.
📌 결론
- 「경험·직감·과거의 버그 패턴」을 바탕으로 테스트 케이스를 추가하는 테스트 설계 기법
- 다른 6가지 기법（동등 분할·경계값·디시전 테이블 등）의 마지막 마무리로서 사용한다
- 체크리스트화함으로써 경험이 적은 멤버도 활용할 수 있게 된다
에러 추측이란？
에러 추측（Error Guessing）이란 「과거의 경험·버그 패턴·직감을 바탕으로 버그가 발생할 것 같은 값이나 조작을 예측하여 테스트 케이스를 추가하는 테스트 설계 기법」입니다.
ISTQB에서는 「테스터의 경험·직감·휴리스틱스（경험칙）에 기반한 기법」으로 정의되어 있습니다. 다른 기법이 「사양서의 조건에서 논리적으로 테스트 케이스를 도출한다」는 것에 반해 에러 추측은 「여기가 위험할 것 같다」는 경험적인 감각을 기점으로 합니다.
| 비교 항목 | 체계적인 기법（동등 분할·경계값 등） | 에러 추측 |
|---|---|---|
| 기점 | 사양서의 조건·요건 | 경험·직감·과거의 버그 패턴 |
| 망라성 | 논리적으로 망라할 수 있다 | 망라성 보증 없음（보완적） |
| 재현성 | 누가 해도 같은 결과 | 경험자일수록 정확도가 높다 |
| 잘 찾는 버그 | 사양에 쓰인 조건의 버그 | 사양 외의 함정·구현의 버릇 |
에러 추측의 실천：버그가 발생하기 쉬운 값의 카탈로그
15년 이상의 실무 경험에서 엄선한 「버그가 발생하기 쉬운 값·조작의 패턴」을 카테고리별로 정리합니다. 이것을 체크리스트로 사용함으로써 경험이 적은 멤버도 에러 추측을 활용할 수 있습니다.
① 숫자계 버그 패턴
| 값 | 왜 위험한가 | 자주 있는 버그 예시 |
|---|---|---|
| 0 | 0으로 나누기·조건 분기의 경계 | ZeroDivisionError·할인 계산에서 0원이 된다 |
| -1·음수 | 부호 없는 정수형에서 의도치 않은 큰 수가 된다 | 재고 수에 -1을 입력하면 4294967295가 된다 |
| 최대값+1 | 정수 오버플로우 | int32의 최대값 2147483647의 다음이 -2147483648이 된다 |
| 소수·부동소수점 | 부동소수점의 반올림 오차 | 0.1 + 0.2 = 0.30000000000000004 |
② 문자열계 버그 패턴
| 값 | 왜 위험한가 | 자주 있는 버그 예시 |
|---|---|---|
| 빈 문자열（””） | NULL과의 혼동·길이 체크 누락 | 빈 문자열이 DB에 저장된다·이름 필드가 공백으로 OK가 된다 |
| 공백만（” “） | 빈 문자열과 다른 처리가 된다 | 「입력 있음」으로 판정되어 유효성 검증을 통과한다 |
| 매우 긴 문자열（1000자 이상） | 버퍼 오버플로우·DB 제약 초과 | 500자 제한 필드에 1000자로 에러 없음 |
| 전각·반각 혼재 | 문자 코드·길이 계산의 어긋남 | 「가a」로 2문자인데 바이트 수로 4가 된다 |
| 개행·탭 문자 | CSV 출력 시 파손·표시 깨짐 | 개행 포함 문자열을 CSV에 출력하면 행이 어긋난다 |
③ 보안계 버그 패턴
| 값 | 왜 위험한가 | 체크 포인트 |
|---|---|---|
' OR '1'='1 | SQL 인젝션 | 로그인 폼에서 인증 바이패스가 가능한가 |
<script>alert(1)</script> | XSS（크로스 사이트 스크립팅） | 입력값이 그대로 HTML에 표시되지 않는가 |
../../../etc/passwd | 경로 탐색（Path Traversal） | 파일명 입력으로 디렉토리를 거슬러 올라갈 수 없는가 |
④ NULL·미정의계 버그 패턴
| 값 | 왜 위험한가 | 자주 있는 버그 예시 |
|---|---|---|
| NULL / None | NullPointerException·예기치 않은 동작 | 옵션 항목에 NULL이 들어가 정렬에서 크래시 |
| 미선택 상태 | 기본값 처리가 불완전 | 드롭다운을 선택하지 않고 전송하면 에러 |
| 빈 배열·빈 리스트 | 루프 처리에서 0건 처리가 누락된다 | 검색 결과 0건에서 페이지네이션이 크래시 |
⑤ 날짜·시각계 버그 패턴
| 값 | 왜 위험한가 | 자주 있는 버그 예시 |
|---|---|---|
| 2월 29일（윤년） | 윤년 고려 누락 | 「1년 후」를 계산하면 다음 해 2월 29일이 없어 크래시 |
| 월말일（28·29·30·31일） | 월별로 일수가 다르다 | 「1개월 후」가 다음 달에 존재하지 않는 날짜가 된다 |
| 타임존 경계 | UTC 변환의 어긋남 | 한국 시간 23:00의 예약이 UTC로 전날이 된다 |
| 연말연시（12/31 → 1/1） | 연도를 넘는 계산 누락 | 주간 리포트가 12/31〜1/6이 아니라 12/31만 된다 |
에러 추측 체크리스트：테스트 전에 확인해야 할 10가지 질문
테스트 설계를 마친 후 다음 질문을 체크리스트로 사용합니다. 하나라도 「테스트하지 않았다」고 깨달으면 테스트 케이스에 추가하세요.
✅ 에러 추측 체크리스트
| 1 | 숫자 필드에 0·음수·최대값+1을 입력하면 어떻게 되나？ |
| 2 | 문자열 필드에 빈 문자열·공백만·1000자 이상을 입력하면 어떻게 되나？ |
| 3 | 필수 필드에 NULL·미입력·미선택인 채로 전송하면 어떻게 되나？ |
| 4 | 같은 조작을 연속으로 2번·빠르게 실행하면 어떻게 되나？（이중 전송） |
| 5 | 날짜 필드에 2월 29일·월말·연말연시를 입력하면 어떻게 되나？ |
| 6 | 문자열에 싱글 쿼트·<script> 태그·SQL 코멘트를 입력하면 어떻게 되나？ |
| 7 | 리스트나 검색 결과가 0건일 때 페이지네이션이나 정렬은 어떻게 되나？ |
| 8 | 파일 업로드에 빈 파일·극단적으로 큰 파일·잘못된 확장자를 보내면 어떻게 되나？ |
| 9 | 네트워크 차단·타임아웃·서버 에러가 처리 도중에 발생하면 어떻게 되나？ |
| 10 | 브라우저의 「뒤로 가기」 버튼·URL 직접 입력·북마크에서의 접근은 어떻게 되나？ |
테스트 설계 기법 시리즈의 마무리：에러 추측의 위치づけ
테스트 설계 기법 7선 시리즈를 통해 각 기법의 역할과 조합 방법을 정리합니다.
| 기법 | 역할 | 타이밍 |
|---|---|---|
| 동등 분할 | 입력값 범위를 그룹화 | 가장 먼저 실시 |
| 경계값 분석 | 그룹의 경계를 중점 테스트 | 동등 분할 직후 |
| 디시전 테이블 | 복수 조건의 조합을 정리 | 업무 로직에 |
| 상태 전이 테스트 | 상태와 전이의 올바름을 검증 | 플로우 계열 시스템에 |
| 유스케이스 테스트 | 사용자 조작 플로우 전체를 검증 | E2E 테스트 설계에 |
| 페어와이즈 테스트 | 다수의 조합을 효율화 | 환경 설정·파라미터 조합에 |
| 에러 추측 ←지금 여기 | 경험·직감으로 위험한 값을 보완 | 모든 기법의 마지막에 추가 |
🎯 실무 워크플로우
① 동등 분할·경계값 분석으로 기본 테스트 케이스를 설계
② 업무 로직에 디시전 테이블을 적용
③ 플로우 계열은 유스케이스 테스트·상태 전이 테스트로 보강
④ 파라미터가 많은 경우는 페어와이즈로 최적화
⑤ 마지막으로 에러 추측 체크리스트를 돌려 「경험적으로 위험한 값」을 추가
⚠️ 에러 추측에서 자주 있는 실패 패턴 4선
에러 추측을 실무에서 사용할 때 빠지기 쉬운 실패를 소개합니다.
① 에러 추측만으로 체계적인 기법을 생략한다
「경험이 있으니까 동등 분할 같은 건 안 해도 된다」는 판단은 위험합니다. 에러 추측은 「보완하는 기법」이며 단독으로는 망라성을 보증할 수 없습니다. 체계적인 기법으로 베이스를 만들고 에러 추측으로 마무리하는 순서를 지키세요.
② 팀 멤버의 경험에 너무 의존한다
「저 선배가 하면 찾을 수 있지만 나는 모른다」는 상태는 팀의 리스크입니다. 에러 추측의 버그 패턴을 체크리스트화·문서화함으로써 경험이 적은 멤버도 활용할 수 있게 됩니다. 「개인의 감」을 「팀의 자산」으로 바꾸세요.
③ 보안계 에러 추측을 QA가 생략한다
「보안은 보안 전문가의 일」이라고 생각하여 SQL 인젝션·XSS 테스트를 QA가 생략해버리는 케이스입니다. 전문적인 침투 테스트와 달리 기본 패턴（싱글 쿼트·script 태그 등）은 QA 엔지니어가 평상시 테스트에 포함시켜야 합니다.
④ 「감으로 추가한」테스트 케이스의 근거를 남기지 않는다
테스트 케이스에 「왜 이 값을 테스트하는가」의 근거 코멘트를 쓰지 않으면 나중에 본 멤버가 「왜 이게 필요한가？」라고 삭제해버리는 경우가 있습니다. 「경험상 공백 문자만의 입력으로 유효성 검증을 통과한 적이 있기 때문에」처럼 근거를 1줄 남겨두세요.
FAQ
Q. 에러 추측은 경험이 없는 멤버에게는 사용할 수 없나요？
사용할 수 있습니다. 이 글에서 소개한 버그 패턴 카탈로그·체크리스트를 활용함으로써 경험이 적은 멤버도 「자주 있는 버그가 발생하기 쉬운 값」을 체계적으로 테스트할 수 있습니다. 처음에는 카탈로그를 그대로 사용하고 버그를 발견할 때마다 팀의 카탈로그에 추가해가면 정확도가 올라갑니다.
Q. 에러 추측과 애드혹 테스트의 차이는？
애드혹 테스트는 계획 없이 생각나는 대로 테스트를 수행하는 방법입니다. 에러 추측은 과거의 경험·버그 패턴에 기반하여 테스트 케이스를 설계하는 방법입니다. 애드혹 테스트보다 재현성·목적 의식이 있어 체크리스트화함으로써 팀에서 공유할 수 있는 점이 에러 추측의 우위성입니다.
Q. ISTQB에서 에러 추측은 어느 정도 출제되나요？
ISTQB Foundation Level에서는 「에러 추측의 정의·다른 기법과의 사용 구분·경험·직감·휴리스틱스에 기반한 기법임」이 출제됩니다. 「에러 추측은 보완적인 기법이며 다른 기법과 조합하여 사용한다」는 위치づけ을 이해해 두면 대응할 수 있습니다.
Q. 에러 추측의 버그 패턴 카탈로그는 어떻게 키워나가면 되나요？
「버그가 발견될 때마다 카탈로그에 추가한다」는 운영이 가장 효과적입니다. 버그의 포스트모템（회고）에서 「이 버그는 에러 추측으로 사전에 발견할 수 있었는가？」를 물어 발견할 수 없었던 경우에는 카탈로그에 추가합니다. GitHub 리포지토리나 Confluence 등의 팀 Wiki로 관리하면 지속적으로 키워나갈 수 있습니다.
📖 관련 글（테스트 설계 기법 시리즈）
실무에서는 테스트 설계가 완료된 후 이 글의 체크리스트를 1회 돌리는 워크플로우를 채택하고 있습니다. 15년 이상의 경험에서 「이 체크리스트를 돌린 것으로 매번 1〜2개의 버그가 추가로 발견된다」는 실감이 있습니다. 특히 「공백 문자만」「이중 전송」「월말 계산」은 보편적인 버그 패턴으로 몇 번이나 도움이 되고 있습니다.
📋 이 글의 정리
- 에러 추측은 「경험·직감·과거의 버그 패턴」을 테스트 케이스로 변환하는 테스트 설계 기법
- 다른 6가지 기법의 마지막 마무리로서 사용하여 체계적인 기법으로는 놓치기 쉬운 「경험적으로 위험한 값」을 보완한다
- 버그 패턴 카탈로그·체크리스트화함으로써 경험이 적은 멤버도 활용할 수 있다
- 「개인의 감」을 「팀의 자산」으로 바꾸는 것이 에러 추측의 본질적인 가치
- 테스트 설계 기법 7선은 모두 조합하여 사용하는 것. 에러 추측은 그 마무리
테스트 설계 기법 7선 시리즈를 통해 QA 엔지니어가 실무에서 사용하는 기법의 전체상을 배웠습니다. 동등 분할·경계값에서 시작하여 디시전 테이블·상태 전이 테스트·유스케이스 테스트·페어와이즈 테스트, 그리고 마지막 에러 추측——이것들을 조합함으로써 체계적이면서도 경험적인 「강한 테스트 설계」가 완성됩니다. 이제 실제 프로젝트에서 사용하면서 자신만의 버그 패턴 카탈로그를 키워나가세요.
