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

개념

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

레슨 2의 기법 지도를 떠올려보자. 거기서 기법을 고르는 축은 "무엇을 근거로 테스트 케이스를 뽑는가"였다. 명세 기반은 문서 에서, 구조 기반은 코드 에서 케이스를 뽑는다. 경험 기반은 세 번째 근거를 쓴다 — 과거에 실제로 깨졌던 이력 이다.

오류 추정은 "감"이 아니다 — 세 가지 근거

오류 추정(Error Guessing)은 이름 때문에 오해를 산다. "추정"이나 "짐작"이라는 말이 즉흥적으로 들리기 때문이다. 하지만 잘 하는 사람의 오류 추정을 뜯어보면 근거가 셋으로 정리된다.

세 근거 중 첫 번째가 가장 강력하고 가장 자주 버려진다. 팀의 결함 이력은 이미 데이터베이스에 쌓여 있는데, 그걸 열어보고 테스트 설계에 쓰는 사람은 드물다. "감으로 찍는 사람"과 "오류 추정을 잘 하는 사람"의 차이는 재능이 아니라 이 데이터를 봤느냐 다.

결함 데이터를 유형별로 세어보면

한 팀이 6개월치 결함을 유형별로 분류해 세면 대체로 이런 모양이 나온다. 숫자는 팀마다 다르지만, 순위의 모양은 놀랄 만큼 비슷하다.

여기서 얻는 게 두 가지다. 첫째, 어디에 시간을 먼저 쓸지 가 정해진다. 입력값 검증과 경계 조건만 합쳐도 절반 가까이다. 둘째, 우리 팀만의 편향이 드러난다 — 어떤 팀은 "표시·번역"이 30%를 넘기도 하는데, 그건 그 팀의 다국어 처리에 구조적 문제가 있다는 뜻이고, 그 팀의 체크리스트는 그 항목을 맨 위에 둬야 한다.

흔한 프로그래밍 실수 패턴

두 번째 근거는 개발자가 코드를 짤 때 반복적으로 빠지는 함정 이다. 코드를 직접 못 봐도, "여기쯤에 이런 실수가 있을 법하다"고 짚어낼 수 있다.

이 표의 진짜 쓸모는 왼쪽 열이 아니라 세 번째 열 이다. QA는 대개 코드를 보기 전에 화면부터 본다. "목록 마지막 항목이 안 보인다"는 제보를 받으면 곧바로 off-by-one을 의심하고, 재현 조건을 개수 기준으로 좁혀 들어갈 수 있다. 코드 레벨에서 이 패턴들이 실제로 어떻게 생겼는지는 스테이지 3의 코드 읽기 모듈에서 다시 만난다.

오류 추정을 실제로 하는 4단계

"경험에서 뽑아내라"는 말은 경험이 없는 사람에게는 막막하다. 절차로 바꾸면 경력과 무관하게 오늘부터 쓸 수 있다.

1. 이 기능이 무엇을 다루는지 한 줄로 적는다. "사용자가 파일을 올려 서버에 저장한다." 다루는 대상(파일, 금액, 개인정보)이 뒤 단계의 힌트가 된다.
2. 비슷한 기능에서 과거에 난 결함을 찾아본다. 결함 관리 시스템에서 "업로드"로 검색한다. 이 한 번의 검색이 30분 브레인스토밍보다 낫다.
3. 카테고리별 체크리스트를 훑는다. 다음 절의 목록을 위에서 아래로 읽으며 "이 기능에 해당되는가"만 판단한다. 생각해내는 게 아니라 고르는 일이다.
4. "이게 깨지면 얼마나 아픈가"로 정렬한다. 돈·데이터·계정에 닿는 항목을 위로 올린다. 시간이 잘리면 위에서부터만 실행한다.

3단계가 핵심이다. 오류 추정을 어려워하는 사람은 대부분 빈 종이에서 생각해 내려고 한다. 목록을 놓고 고르는 방식으로 바꾸면 난이도가 완전히 달라진다.

자주 터지는 결함 패턴 — 카테고리별 체크리스트

아래는 어느 기능에나 가져다 댈 수 있는 범용 목록이다. 전부 실행하라는 게 아니라, 훑으면서 해당되는 것을 고르는 메뉴판 으로 쓴다.

A. 입력값

• 빈 값으로 제출 / 공백(스페이스)만 입력 / 탭·개행만 입력
• 선택 항목을 아무것도 안 고른 채 진행
• 최대 길이 정확히 / 최대 길이 + 1 / 아주 긴 문자열(1만 자 붙여넣기)
• 특수문자 < > & " ' / \ % 와 <script> 같은 태그 형태 문자열
• SQL 인젝션성 문자열 — ' OR 1=1 --, 작은따옴표가 포함된 이름(O'Brien)
• 이모지, 한글·중국어·아랍어(우→좌 표기), 결합 문자(가족 이모지)
• 숫자 필드에 문자, 소수점, 음수, 0, 앞자리 0(007), 지수 표기(1e10)
• 아주 큰 수(21억 초과), 아주 작은 수, 통화 최소 단위 미만
• 앞뒤 공백이 붙은 이메일·아이디 — 잘라내는가 그대로 저장하는가
• 대소문자만 다른 중복 값(Kim@a.com 과 kim@a.com)
• 붙여넣기로만 입력(키 입력 이벤트에 검증이 걸려 있으면 뚫린다)
• 날짜: 2월 30일, 윤년 2월 29일, 과거 날짜, 100년 뒤, 시작 > 종료

B. 상태와 흐름

• 브라우저 뒤로가기 로 결제·제출 이후 화면에서 되돌아오기
• 제출 직후 새로고침 — 중복 제출되는가, 경고가 뜨는가
• 제출 버튼 빠르게 2~3회 연타
• 두 개의 탭·기기에서 같은 데이터를 동시에 수정
• 중간에 창을 닫았다가 다시 들어오기 — 임시 저장은 되는가
• 로그인 세션이 만료된 상태로 제출
• URL을 직접 입력해 중간 단계로 진입(1단계를 건너뛰고 3단계로)
• 이미 처리된 요청을 다시 처리(이미 환불된 주문 재환불)
• 목록에서 항목을 지운 뒤, 열어둔 다른 탭에서 그 항목을 수정

C. 시간과 타이밍

• 처리 중(스피너)일 때 다른 버튼 누르기
• 타임아웃 직전·직후의 요청
• 자정 경계(23:59에 시작해 00:01에 완료)
• 예약·만료 시각이 정확히 지금인 경우
• 서버 시간과 기기 시간이 다를 때(기기 시계를 앞뒤로 돌려본다)

D. 환경과 설정

• 느린 네트워크 — 개발자 도구에서 3G로 제한하고 전 과정 수행
• 요청 도중 네트워크 끊김 → 다시 연결
• 기기 시간대 변경 (서울 → 로스앤젤레스) 후 날짜 표시 확인
• 기기 언어 설정 변경 — 미번역 문구, 잘린 버튼, 날짜·통화 형식
• 브라우저 확대 200%, 아주 좁은 화면, 아주 넓은 화면
• 쿠키·로컬스토리지를 비운 첫 방문 상태
• 광고 차단기·자동 번역 확장이 켜진 브라우저

E. 권한과 데이터

• 로그아웃 상태에서 로그인 전용 URL 직접 접근
• 남의 데이터 URL 직접 접근(주문 번호를 1 바꿔서)
• 권한이 낮은 계정으로 관리자 기능 호출
• 데이터가 0건 일 때 화면(빈 상태 안내가 있는가)
• 데이터가 1건 일 때(복수형 문구가 어색해지는 자리)
• 데이터가 아주 많을 때 (페이지네이션, 정렬, 성능)
• 긴 이름·이미지 없음·값이 null인 항목이 섞인 목록

A~E를 다 합치면 50개가 넘는다. 전부 하라는 목록이 아니다. 새 기능을 맡았을 때 5분 동안 훑으면서 "이건 해당된다" 싶은 것에만 표시하면, 그것만으로 명세에 없던 테스트 케이스가 열 개 넘게 확보된다.

체크리스트 기반 테스트 — 개인의 경험을 팀의 자산으로

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

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

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

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

쓸모 있는 체크리스트 항목의 조건

체크리스트를 만들어봤지만 아무도 안 쓰게 되는 경우가 많다. 대개 항목의 문장이 나쁘기 때문이다.

규칙은 하나다. 한 줄을 읽고 바로 손이 움직일 수 있어야 한다. 이건 모듈 2에서 배운 "테스트 가능한 요구사항"의 조건과 정확히 같은 원리다 — 판정 기준이 관찰 가능한 형태로 적혀 있어야 한다.

체크리스트를 자라게 하는 회로

체크리스트의 가치는 만든 날이 아니라 1년 뒤 에 드러난다. 자라게 하려면 결함과 체크리스트를 잇는 습관 하나면 된다.

1. 운영에서 장애나 심각한 결함이 나면, 회고에서 "이걸 잡을 수 있었던 한 줄" 을 만든다.
2. 그 줄을 해당 화면 유형의 체크리스트 맨 위에 넣는다.
3. 항목마다 왜 생겼는지(결함 번호) 를 같이 적어둔다.
4. 반년에 한 번, 오래도록 한 번도 결함을 잡은 적 없는 항목은 아래로 내리거나 지운다.

3번을 빼먹으면 몇 달 뒤 "이 항목 왜 있는 거예요?"라는 질문에 아무도 답하지 못하고, 근거를 모르는 항목은 결국 형식적으로 체크만 되고 실행되지 않는다. 4번을 빼먹으면 체크리스트가 200줄이 되고, 200줄짜리 체크리스트는 아무도 안 쓴다. 자라기만 하고 줄지 않는 체크리스트는 죽은 체크리스트다.

이 기법의 한계 — 재현성과 설명 가능성이 약하다

경험 기반 기법을 배울 때 반드시 같이 알아야 할 것이 약점이다. 이 기법은 근거가 테스터 개인의 경험치 에 크게 의존하기 때문에 구조적인 한계가 있다.

마지막 줄이 중요하다. 이 레슨의 카테고리별 목록과 결함 이력 검색은 경력이 없는 사람에게 경력을 빌려주는 장치 다. 그래서 신입일수록 오히려 체크리스트를 더 적극적으로 써야 한다.

그래서 명세 기반 기법과 항상 병행한다

경험 기반 기법 하나만으로 테스트를 구성하면 안 되는 이유는 커버리지를 말할 수 없기 때문이다. 두 기법은 채우는 영역이 다르다.

실무 순서는 대개 이렇다. 먼저 동등분할·경계값 분석(레슨 1)으로 뼈대를 세우고, 조건 조합이 많으면 결정 테이블·페어와이즈(레슨 3, 5)로 줄이고, 그 위에 경험 기반 체크리스트를 덮어 명세가 말하지 않은 구멍을 메운다. 순서를 뒤집으면 "재미있는 케이스는 많은데 기본 요구사항 확인이 빠진" 테스트가 된다. 이건 실제로 흔한 실패 모습이다.

시간이 극도로 부족할 때 — 릴리즈 D-1의 우선순위

경험 기반 기법이 가장 빛나는 순간은 시간이 없을 때다. 다만 시간이 없을수록 무엇부터 볼지 를 판단하는 기준이 필요하다. 아무 데나 체크리스트를 대면 남은 30분을 별로 안 중요한 화면에 다 쓰게 된다.

판단 기준 — 두 축으로 자른다

• 터졌을 때의 피해 크기: 돈이 잘못 움직이는가? 데이터가 사라지는가? 남의 정보가 보이는가? 되돌릴 수 있는가?
• 터질 확률: 이번에 바뀐 코드에 가까운가? 과거에 자주 깨졌던 영역인가? 급하게 만들어졌는가?

두 축을 곱해 높은 순으로 본다. 실무에서 위쪽에 오는 영역은 거의 항상 같다.

1~3위가 결제·인증·삭제 인 이유는 하나다. 되돌릴 수 없거나, 되돌리는 비용이 비싸기 때문이다. 목록이 잘못 정렬되는 결함은 다음 날 고쳐도 되지만, 잘못 빠져나간 돈과 유출된 개인정보와 지워진 데이터는 다음 날 고칠 수 없다. 릴리즈 직전의 판단 기준은 "결함 개수"가 아니라 "돌이킬 수 있는가" 다.

남은 시간별 배분

못 한 것을 반드시 기록한다

시간이 없어 못 본 것을 조용히 넘기면, 릴리즈 결정을 내리는 사람은 "다 봤다"고 착각한다. 이건 결함보다 위험하다. 30분을 썼다면 마지막 5분은 이걸 쓰는 데 쓴다.

확인함: 결제 정상 1건, 결제 연타, 인증 만료 후 제출, 삭제 확인창 확인 못 함: 다국어 화면, 느린 네트워크, 관리자 통계 화면 가장 걱정되는 것: 결제 도중 네트워크 끊김을 못 봤습니다. 지난 분기에 같은 유형으로 장애가 있었습니다(DEF-1042).

이렇게 쓰면 릴리즈 여부는 팀이 알고 결정한다. 이게 체크리스트가 주는 가장 실용적인 가치다 — 결함을 잡는 것보다, 무엇을 안 봤는지 말할 수 있게 해주는 것 이 더 자주 팀을 구한다. 리스크로 우선순위를 정하는 방법은 모듈 4의 리스크 기반 테스트에서 훨씬 체계적으로 다룬다.

탐색적 테스팅과는 다르다

경험 기반 기법(오류 추정, 체크리스트)은 미리 목록을 만들어두고 그대로 적용 한다는 점에서, 실행하면서 동시에 다음에 뭘 볼지 즉흥적으로 판단하는 탐색적 테스팅(모듈 5) 과 다르다.

오류 추정 체크리스트가 "정해진 질문지를 들고 확인하는 것"이라면, 탐색적 테스팅은 "질문지 없이 직접 돌아다니며 새로운 질문을 그 자리에서 만들어가는 것"에 가깝다. 둘은 상호 보완적이며, 이 커리큘럼의 모듈 5에서 탐색적 테스팅을 훨씬 깊게 다룬다.

실무에서는 둘이 자연스럽게 이어진다. 체크리스트를 훑다가 이상한 반응을 발견하면, 그 지점에서 목록을 잠시 놓고 파고드는 것이 탐색적 테스팅이다. 체크리스트는 출발점을 주고, 탐색은 거기서 깊이를 만든다.

사례 연구 — 닉네임 이모지 하나가 만든 장애

경험 기반 기법이 실제로 어떻게 작동하는지, 흔한 장면 하나로 보자.

프로필 편집 화면에 닉네임 필드가 추가됐다. 명세는 두 줄이었다. "닉네임은 2자 이상 10자 이하", "중복 불가".

명세 기반 기법만 적용하면 케이스는 이렇게 나온다 — 1자(실패), 2자(성공), 10자(성공), 11자(실패), 중복(실패). 레슨 1의 경계값 분석 그대로다. 다 통과했다.

여기에 경험 기반 체크리스트 A를 5분 훑으며 세 개를 더 골랐다.

1. 이모지 닉네임 — "😀😀😀"
2. 앞뒤 공백이 붙은 닉네임 — " 홍길동 "
3. 대소문자만 다른 중복 — 기존 Kim, 신규 kim

결과는 셋 다 결함이었다.

세 결함 모두 명세에는 한 글자도 언급이 없다. 명세 기반 기법으로는 구조적으로 잡을 수 없는 것들이고, 코드를 볼 수 없어도 잡을 수 있는 것들이다. 여기서 얻을 교훈은 두 가지다.

• 명세를 다 커버했다는 것과 문제가 없다는 것은 다른 말이다. 명세는 "무엇을 만들지"를 적은 문서지, "무엇이 깨질 수 있는지"를 적은 문서가 아니다.
• 5분이면 된다. 세 케이스를 고르는 데 든 시간은 목록을 훑은 5분이고, 실행에는 각 1분이 들었다.

이후 이 팀은 "이모지 닉네임", "앞뒤 공백", "대소문자 중복"을 입력 필드 체크리스트에 결함 번호와 함께 추가 했다. 다음 분기에 댓글 기능이 나왔을 때, 같은 세 줄이 또 두 개의 결함을 잡았다. 이게 개인의 발견이 팀의 자산이 되는 과정이다.

실무에서 왜 필요한가

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

신입 QA에게 특히 필요한 이유

"경험 기반"이라는 이름 때문에 신입은 이 기법을 자기 것이 아니라고 느끼기 쉽다. 사실은 정반대다. 신입에게 가장 부족한 것이 "어디가 깨질지에 대한 감"인데, 체크리스트는 그 감을 빌려주는 장치 다. 팀의 결함 이력을 검색하고 카테고리별 목록을 훑는 것만으로, 3년차가 감으로 하는 일의 상당 부분을 절차로 대체할 수 있다.

그리고 실제로 신입이 팀에서 인정받는 가장 빠른 경로 중 하나가 이것이다. 명세대로만 테스트해서 "이상 없음"을 보고하는 사람은 많다. 명세에 없는데 사용자가 실제로 겪을 문제를 하나 찾아오는 사람 은 드물다.

팀 차원에서 무엇이 달라지는가

• 담당자가 바뀌어도 품질이 유지된다. 경험이 개인의 머리에만 있으면 퇴사·이동과 함께 사라진다. 체크리스트는 남는다.
• 회고가 행동으로 이어진다. 대부분의 장애 회고는 "다음엔 조심하자"로 끝난다. 체크리스트에 한 줄을 추가하는 것은 회고를 다음 릴리즈에 실제로 작동하는 장치 로 바꾸는 가장 싼 방법이다.
• 테스트 인수인계가 가능해진다. "이 화면 좀 봐주세요"가 "이 체크리스트 훑어주세요"가 되면, 개발자나 기획자에게도 부분적으로 넘길 수 있다.

실습 과제

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

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

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

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

과제 3 — 결함 이력에서 체크리스트 뽑기 (12분)

아래는 어느 팀의 최근 결함 다섯 건이다. 각각에 대해 "이걸 잡을 수 있었던 체크리스트 한 줄" 을 만들고, 본문 A~E 중 어느 카테고리에 넣을지 정한다.

1. 쿠폰 코드 입력창에 앞뒤 공백이 붙은 코드를 넣으면 "없는 코드"로 나온다.
2. 주문 상세 URL의 주문번호를 바꾸면 다른 사람 주문이 보인다.
3. 배송지 목록이 0건일 때 화면이 완전히 비어 있어 무엇을 해야 할지 모르겠다.
4. 자정 직전에 주문하면 주문 목록에서 날짜가 하루 뒤로 표시된다.
5. 리뷰 작성 후 뒤로가기를 하면 같은 리뷰가 한 번 더 등록된다.

과제 4 — 릴리즈 D-1, 30분 배분하기 (10분)

내일 오픈인데 남은 시간이 30분이다. 이번 릴리즈에는 다음이 포함됐다.

• 결제 수단에 간편결제 추가
• 마이페이지 프로필 이미지 변경 기능
• 상품 목록 정렬 옵션 추가
• 이용약관 문구 수정

무엇을 어떤 순서로 볼지 정하고, 못 본 것을 어떻게 보고할지 까지 써본다.

자가 체크리스트

• 오류 추정이 "즉흥적 짐작"이 아니라 "누적된 경험의 체계적 적용"임을 설명할 수 있다
• 오류 추정의 세 가지 근거(과거 결함 데이터, 흔한 실수 패턴, 도메인 사고 이력)를 댈 수 있다
• 팀의 결함 이력을 유형별로 세어보는 것이 왜 유용한지 설명할 수 있다
• off-by-one, null 미처리, 타입 변환, 동시성 문제가 화면에서 어떤 증상으로 보이는지 말할 수 있다
• 오류 추정 4단계 절차를 순서대로 적용할 수 있다
• 입력값·상태·시간·환경·권한 다섯 카테고리로 체크리스트를 훑을 수 있다
• 쓸모 있는 체크리스트 항목의 조건("읽고 바로 손이 움직인다")을 설명할 수 있다
• 체크리스트를 자라게 하는 회로(결함 → 한 줄 → 근거 기록 → 정리)를 안다
• 경험 기반 기법의 한계(재현성·설명 가능성·커버리지 측정 불가·편향)를 설명할 수 있다
• 명세 기반 기법으로 뼈대를 세우고 경험 기반을 그 위에 얹는 순서를 설명할 수 있다
• 시간이 없을 때 결제·인증·삭제를 먼저 보는 이유를 "되돌릴 수 있는가"로 설명할 수 있다
• 못 본 것을 기록해 보고하는 형식을 쓸 수 있다
• 경험 기반 기법과 탐색적 테스팅의 차이를 설명할 수 있다
• 주어진 기능에 대해 오류 추정 체크리스트를 직접 작성할 수 있다

흔한 실수

• 경험 기반 기법을 "제대로 된 테스트 설계가 아니다"라고 낮게 본다. 명세 기반 기법으로 커버 안 되는 실제 결함 패턴을 잡아주는, 엄연히 독립적인 기법이다.
• 반대로 경험 기반 기법만으로 테스트를 구성한다. 커버리지를 말할 수 없어 "무엇이 남았는지"를 보고할 수 없다. 명세 기반으로 뼈대를 세운 위에 얹는다.
• 결함 이력을 안 보고 머리로만 짜낸다. 오류 추정을 잘 하는 사람과 못 하는 사람의 차이는 재능이 아니라 이력을 검색해봤느냐다. 새 기능을 맡으면 결함 관리 시스템에서 비슷한 기능 이름으로 먼저 검색한다.
• 체크리스트를 한 번 만들고 갱신하지 않는다. 새로운 유형의 결함이 발견되면 체크리스트에 추가해야 계속 쓸모가 있다 — 팀의 결함 이력이 쌓일수록 체크리스트도 함께 자라야 한다.
• 체크리스트가 자라기만 하고 줄지 않는다. 200줄짜리 체크리스트는 아무도 안 쓴다. 오래 아무것도 잡지 못한 항목은 내리거나 지운다.
• 체크리스트 항목을 모호하게 쓴다. "보안 점검", "성능 확인" 같은 줄은 읽어도 손이 안 움직인다. 한 줄이 곧 하나의 실행 가능한 동작이어야 한다.
• 항목의 근거를 안 남긴다. 왜 생긴 줄인지 모르면 몇 달 뒤 형식적으로 체크만 되고 실제로 실행되지 않는다. 결함 번호를 같이 적는다.
• 체크리스트만 믿고 그 기능만의 고유한 리스크를 놓친다. 체크리스트는 "일반적으로" 자주 터지는 패턴이다. 그 기능만의 특수한 리스크는 여전히 다른 기법(리스크 기반 테스트, 모듈 4)으로 별도로 봐야 한다.
• 시간이 없을 때 눈에 보이는 것부터 아무 순서로 본다. 되돌릴 수 없는 것(결제·인증·삭제)이 먼저다. 화면 순서대로 보는 것은 우선순위가 아니다.
• 못 본 것을 말하지 않는다. 침묵은 "다 봤다"로 읽힌다. 확인 못 한 범위를 적어내는 것이 릴리즈 결정을 내리는 사람에게 가장 필요한 정보다.

참고 자료

• ISTQB Foundation Level Syllabus — Experience-Based Techniques — 오류 추정, 체크리스트 기반 테스트의 공식 정의
• Test Heuristics Cheat Sheet — 오류 추정에 쓸 수 있는 대표적인 휴리스틱 모음. 모듈 5에서 더 상세한 버전을 다룬다
• Elisabeth Hendrickson, Explore It! — 휴리스틱과 탐색적 테스팅을 잇는 고전. 부록의 휴리스틱 목록은 이 레슨의 카테고리별 체크리스트를 확장할 때 바로 쓸 수 있다
• OWASP Web Security Testing Guide — 권한·인증 관련 체크리스트를 팀 목록에 옮겨 담기 좋은 출처
• Cem Kaner, James Bach & Bret Pettichord, Lessons Learned in Software Testing — 경험 기반 테스트의 근거와 한계를 실무 사례로 정리한 책