테스트 휴리스틱 치트시트 (일반 + 웹)

개념

이 모듈의 마지막 레슨이다. 지금까지 배운 개별 기법들을 막혔을 때 바로 꺼내 쓸 수 있는 하나의 참조표로 정리한다.

휴리스틱(heuristic) 은 "반드시 맞는 규칙" 이 아니라 대체로 도움이 되는 생각의 단서를 뜻한다. 번역하면 "경험 법칙" 정도다. 답을 보장하지 않는 대신 빠르게 쓸 만한 방향을 준다.

요리를 떠올리면 이해가 쉽다. 레시피는 "설탕 2스푼" 처럼 정확한 지시이고, "단맛이 부족하면 짠맛을 조금 더해 봐라" 는 휴리스틱이다. 후자는 틀릴 때도 있지만, 레시피가 없는 상황에서 다음에 무엇을 해 볼지를 알려 준다.

탐험 중에 가장 자주 오는 막힘은 "다음에 뭘 해 보지" 다. 30분쯤 지나면 아이디어가 떨어진다. 그 순간 꺼내 보는 종이가 이 레슨의 결과물이다.

휴리스틱 치트시트란

체크리스트(모듈 3, 레슨 8)와 비슷해 보이지만 쓰임이 다르다. 체크리스트는 "이 항목을 하나씩 다 확인하라"는 목적이지만, 휴리스틱 치트시트는 "탐험 아이디어가 떨어졌을 때 훑어보고 영감을 얻는" 목적이다. 기계적으로 체크하는 게 아니라, 막혔을 때 "아, 이 관점은 아직 안 봤네"를 떠올리게 해주는 도구다.

SFDPOT — 가장 유명한 일반 휴리스틱

James Bach가 만든 SFDPOT("샌프란시스코 창고"라는 뜻의 두문자어 암기법)는 소프트웨어를 여섯 관점에서 훑어보게 한다.

이 표 자체가 이 모듈 전체의 요약이기도 하다 — SFDPOT의 각 글자가 이 모듈에서 배운 구체적인 기법과 연결된다.

SFDPOT를 질문으로 바꿔 두기

관점 이름만 적어 두면 막혔을 때 떠오르지 않는다. 각 글자를 질문으로 바꿔 두면 바로 쓸 수 있다.

데이터와 시간 두 줄이 가장 많이 걸린다. 기능은 다들 눌러 보지만, "0건일 때 목록 화면" 과 "빨리 두 번 누르기" 는 의식하지 않으면 지나친다.

데이터 휴리스틱 — 어떤 값을 넣어 볼까

입력란을 만나면 꺼내는 목록이다. 외워 둘 만큼 자주 쓴다.

이모지와 줄바꿈이 의외로 많이 걸린다. 글자 수를 세는 방식과 저장 방식이 어긋나면 "닉네임에 이모지 하나 넣으면 저장이 안 되는" 류의 결함이 나온다. 레슨 7에서 데이터를 따라가 봤던 흐름에 이 값들을 흘려 보면 된다.

상태와 흐름 휴리스틱 — 어떤 조작을 해 볼까

값이 아니라 행동을 바꿔 보는 목록이다.

• 중간에 그만둔다 — 결제 직전에 창을 닫고 다시 들어오면?
• 뒤로 간다 — 완료 화면에서 뒤로가기를 누르면 두 번 처리되나?
• 두 번 누른다 — 버튼을 빠르게 두 번 누르면 두 건이 생기나?
• 순서를 바꾼다 — 보통 A → B 인데 B를 먼저 하면?
• 동시에 한다 — 같은 계정으로 두 탭에서 같은 작업을 하면?
• 아주 느리게 한다 — 10분을 머문 뒤 제출하면 세션이 살아 있나?
• 권한을 바꾼다 — 작업 도중에 권한이 회수되면?
• 다시 한다 — 같은 작업을 연달아 세 번 하면?

세 번째와 다섯 번째가 실제 사고로 가장 많이 이어진다. 중복 결제·중복 발송은 거의 전부 이 두 가지에서 나온다.

품질 특성 휴리스틱 — 무엇을 본다고 말할 것인가

기능이 "된다/안 된다" 외에도 볼 것이 있다. 아래는 보고할 때 말의 이름 으로도 쓰인다.

설치·업데이트 줄이 가장 많이 빠진다. 새로 깔고 테스트하면 통과하지만, 기존 사용자가 올라올 때 깨지는 경우가 흔하다. 모듈 8의 회귀 테스트와 직접 이어진다.

세 가지 크기 휴리스틱

한 줄로 외워 두기 좋은 것 하나. "너무 작게 · 딱 맞게 · 너무 크게" 를 항상 해 본다.

가운데만 보고 끝내는 것이 가장 흔한 미탐이다. 양쪽 끝을 습관으로 만들면 모듈 3에서 배운 경계값 분석을 탐험 중에도 쓰게 된다.

웹 특화 휴리스틱

일반 휴리스틱에 더해, 웹 애플리케이션에서 특히 자주 쓰는 항목들이 있다.

• 브라우저 뒤로가기·앞으로가기, 새로고침을 액션 중간에 시도
• 같은 계정으로 여러 탭·여러 브라우저를 동시에 열기
• 화면 확대·축소, 창 크기 조절
• 네트워크 속도를 인위적으로 느리게(스로틀링)
• 입력 필드에 복사-붙여넣기, 자동완성 값 그대로 제출
• 브라우저 확장 프로그램(광고 차단 등)이 켜진 상태
• 키보드만으로 전체 흐름 조작 (마우스 없이) — 접근성(모듈 16)과도 연결됨
• 우클릭 메뉴, 브라우저 기본 단축키와의 충돌

왜 이것들이 걸리는지 짧게 짚어 두면 기억에 남는다.

네 번째가 가장 값진 한 줄이다. 브라우저 개발자 도구에서 네트워크를 느리게 설정해 두고 평범한 흐름을 한 번 돌려 보면, 중복 제출·로딩 중 깨짐·타임아웃 처리 누락이 한꺼번에 드러난다. 레슨 5에서 다룬 "숨은 변수" 의 대표가 바로 속도다.

모바일에서 더 보는 것

웹 화면을 휴대폰에서도 쓴다면 몇 줄을 더 둔다.

• 가로·세로 전환을 입력 중에 해 본다
• 전화·알림이 중간에 끼어든 뒤 돌아온다
• 앱을 백그라운드에 두고 몇 분 뒤 복귀한다
• 데이터를 끄고(비행기 모드) 제출한 뒤 다시 연결한다
• 글자 크기를 시스템 설정에서 아주 크게 해 둔다
• 화면 위쪽 노치·아래쪽 홈 바에 버튼이 가리는지 본다

네 번째가 모바일 특유의 결함을 잘 끌어낸다. 끊긴 상태의 제출을 쌓아 두는지, 버리는지, 두 번 보내는지가 제품마다 다르고 대개 문서에 없다.

도메인 휴리스틱 — 우리 업종에서만 걸리는 것

일반 휴리스틱으로 잡히지 않는 결함이 있다. 업종의 규칙을 알아야 보이는 것들이다.

금융의 반올림이 좋은 예다. 일반 휴리스틱에는 "소수점" 한 줄이 있을 뿐이지만, "할인 적용 후 부가세 계산에서 1원이 사라진다" 는 결함은 업종 규칙을 알아야 떠오른다. 이런 줄이 치트시트에서 가장 값나가는 부분이고, 그래서 남의 표를 그대로 쓰면 안 되는 이유이기도 하다.

치트시트를 쓰는 올바른 방법

기계적으로 순서대로 확인하지 않는다. 탐험하다가 "다음에 뭘 해야 하지?"라는 순간이 오면, 치트시트를 훑어보며 "아직 안 건드려본 관점이 뭐지?"를 찾는 용도로 쓴다. 이게 이 도구를 체크리스트(모듈 3, 레슨 8)와 구분 짓는 핵심이다 — 치트시트는 탐험을 대체하지 않고, 막혔을 때 다시 굴러가게 돕는다.

쓰는 순서를 정해 두면 손이 익는다.

1. 차터(레슨 2)를 보고 그 차터와 관련 있는 관점만 고른다 2 ~ 3개를 골라 각각 아이디어 1개를 적는다
2. 적은 것을 해 본다 — 하다 보면 새 아이디어가 나온다
3. 또 막히면 다른 관점으로 돌아온다

1번을 건너뛰면 치트시트가 체크리스트가 된다. 결제 차터에 "지역화" 관점을 억지로 끼워 넣을 필요는 없다. 차터와 관계있는 관점만 고르는 판단이 탐험을 탐험으로 유지한다.

치트시트는 팀의 자산으로 키운다

남이 만든 표를 그대로 쓰는 것으로 끝내면 효과가 절반이다. 우리 제품에서 실제로 걸렸던 것을 한 줄씩 더해야 날카로워진다.

첫 줄이 핵심이다. 운영 사고를 회고할 때 "누가 놓쳤나" 대신 "어떤 질문이 없었나" 를 묻고, 그 질문을 치트시트에 넣는다. 그러면 사고 하나가 팀의 영구적인 능력으로 남는다. 모듈 10에서 다루는 결함 분석과 이어진다.

치트시트는 한 장을 넘기지 않는다. 세 장이 되면 아무도 안 본다. 새 줄을 더할 때 낡은 줄 하나를 뺀다는 규칙을 두면 분량이 유지된다.

사례 — 막힌 세션을 되살리기

"장바구니" 차터로 40분을 탐험했는데 결함이 하나도 안 나왔다. 더 볼 것이 없는 것처럼 느껴졌다. 치트시트를 꺼내 아직 안 쓴 관점을 골랐다.

20분 만에 4건이 나왔다. 기능을 덜 본 것이 아니라 관점이 한쪽에 몰려 있었다. 40분 동안 "기능" 관점만 쓰고 있었던 것이다.

세 번째 건이 가장 비싼 결함이었고, 치트시트의 "시간" 한 줄이 없었으면 그 세션에서는 나오지 않았을 것이다.

실무에서 왜 필요한가

경험 많은 탐색적 테스터는 이런 관점들을 이미 몸에 익혀서 자연스럽게 쓴다. 이제 막 시작하는 사람에게는 이 치트시트가 그 내재화된 감각을 빠르게 흉내 낼 수 있게 해주는 실용적인 도구다. 실제로 팀 안에서 "막혔을 때 이 표를 봐"라고 공유해두면, 신입도 금방 탐험의 폭을 넓힐 수 있다.

미탐의 대부분은 "관점 편중" 에서 나온다

운영에서 사고가 난 뒤 "어떻게 이걸 못 봤지" 를 따져 보면, 대개 기능은 충분히 봤는데 데이터·시간·플랫폼 중 한 축을 아예 안 봤다는 결론이 나온다. 사람은 자기가 익숙한 관점으로 자동으로 끌리기 때문이다.

치트시트는 능력을 키우는 도구가 아니라 편중을 교정하는 도구다. 실력이 늘어도 편중은 그대로 남기 때문에, 경력자도 계속 쓴다.

탐험의 폭을 말로 설명할 수 있게 된다

관점에 이름이 붙으면 보고가 가능해진다.

오른쪽은 레슨 13의 종료 보고와 바로 이어진다. 무엇을 못 봤는지를 말할 수 있게 되는 것이 치트시트의 숨은 효용이다.

자동화할 것을 골라낸다

치트시트 항목 중 매 배포마다 반복해야 하는 것이 자동화 후보다. "0건 목록", "허용 용량 바로 위 파일", "느린 네트워크" 같은 항목은 사람이 매번 손으로 하기엔 아깝다. 모듈 11~13의 자동화 대상 선정이 여기서 출발한다.

채용시장에서의 위치

면접에서 "탐색적 테스팅을 어떻게 하세요" 를 물으면 대부분 "직접 써 보면서 이상한 걸 찾습니다" 라고 답한다. 이 답은 방법이 없다는 뜻으로 읽힌다.

두 번째가 면접관이 가장 눈여겨보는 답이다. 놓친 경험을 개인의 실수로 끝내지 않고 팀의 절차로 바꾼 사람은 흔하지 않다. 리드 역할을 뽑을 때 정확히 이 태도를 본다.

공고의 표현으로는 "탐색적 테스팅 경험", "테스트 설계 역량", "테스트 자산 관리" 가 이 레슨의 내용에 걸린다. 치트시트를 팀에 도입하고 운영한 경험은 시니어·리드 지원에서 바로 쓸 수 있는 이야기다.

실습 과제

과제 1 — SFDPOT 적용하기 (15분)

"동영상 업로드" 기능에 대해 SFDPOT 여섯 관점 각각에서 탐험 아이디어를 하나씩 만든다 (총 6개).

과제 2 — 나만의 웹 체크리스트 만들기 (10분)

이 레슨과 이 모듈의 앞선 레슨들에서 배운 내용을 종합해, 자신만의 "웹 탐색 체크리스트" 8개 항목을 만든다. 각 항목 옆에 이 모듈의 어느 레슨에서 나온 아이디어인지 태그를 단다.

과제 3 — 막힌 세션 되살리기 (20분)

익숙한 웹 서비스에서 차터 하나를 정해 15분을 먼저 탐험한다. 아이디어가 떨어지면 멈추고, 다음을 적는다.

1. 15분 동안 주로 쓴 관점 하나
2. 치트시트에서 아직 안 쓴 관점 3개
3. 그 3개로 각각 1개씩 시도한 뒤 새 발견이 있었는지

자가 체크리스트

• SFDPOT 여섯 관점을 나열하고 각각의 의미를 설명할 수 있다
• 휴리스틱 치트시트와 체크리스트(모듈 3)의 쓰임 차이를 설명할 수 있다
• 웹 특화 휴리스틱을 최소 5가지 나열할 수 있다
• SFDPOT의 각 관점이 이 모듈의 어느 레슨과 연결되는지 설명할 수 있다
• 입력란을 만났을 때 넣어 볼 값을 개수·경계·길이·문자 종류로 나눠 말할 수 있다
• 상태·흐름 휴리스틱에서 중복 사고로 이어지는 두 가지를 안다
• 품질 특성 중 설치·업데이트를 왜 자주 빠뜨리는지 설명할 수 있다
• "너무 작게 · 딱 맞게 · 너무 크게" 를 실제 대상에 적용할 수 있다
• 치트시트에 새 줄을 언제 더하고 언제 빼는지 규칙을 말할 수 있다
• 치트시트 항목 중 자동화 후보를 골라낼 수 있다

흔한 실수

• 치트시트를 체크리스트처럼 하나씩 기계적으로 확인한다. 그러면 탐색적 테스팅의 적응적 성격이 사라지고 다시 스크립트가 되어버린다.
• 치트시트에 의존해 스스로 생각하기를 멈춘다. 치트시트는 막혔을 때 쓰는 보조 도구이지, 탐험 전체를 대신하는 게 아니다.
• 일반 휴리스틱(SFDPOT)만 쓰고 도메인 특화 지식을 무시한다. 실제로는 이 모듈의 일반 기법에 더해, 자신이 다루는 제품의 도메인 지식(예: 의료·금융의 특수 규칙)을 결합해야 가장 효과적이다.
• 차터와 무관한 관점을 억지로 끼워 넣는다. 결제 차터에 지역화 관점을 넣을 필요는 없다. 차터와 관계있는 관점만 고르는 것이 판단력이다.
• 치트시트를 계속 늘려 세 장을 만든다. 길어지면 아무도 안 본다. 한 줄을 더할 때 낡은 한 줄을 뺀다는 규칙을 둔다.
• 남이 만든 표를 그대로만 쓴다. 우리 제품에서 실제로 걸렸던 것을 더하지 않으면 날카로워지지 않는다.
• 운영 사고 회고에서 "누가 놓쳤나"를 묻는다. 물어야 할 것은 "어떤 질문이 없었나" 이고, 그 질문을 치트시트에 넣어야 사고가 능력으로 남는다.
• 각 항목에 출처를 안 적는다. 왜 있는 줄인지 잊으면 뺄 수도 없어 목록이 비대해진다.

참고 자료

• James Bach, "Heuristic Test Strategy Model" — SFDPOT를 포함한 휴리스틱 테스트 전략의 원출처
• Test Heuristics Cheat Sheet — 모듈 3(레슨 8)에서 미리 언급했던 그 치트시트. 이제 이 모듈 전체를 배운 뒤 다시 보면 훨씬 잘 이해된다
• Elisabeth Hendrickson, Explore It! — 이 모듈 전체가 참고한 탐색적 테스팅의 대표 실무서. 마지막까지 함께한 만큼, 더 깊이 파고들고 싶다면 이 책 전체를 추천한다
• Satisfice — Heuristic Test Strategy Model — SFDPOT와 품질 특성 목록의 원문 PDF

이 커리큘럼 안에서

• 모듈 5 레슨 2 — 차터. 어떤 관점을 고를지는 차터에서 출발한다
• 모듈 5 레슨 5~7 — 숨은 변수·순서·데이터. 치트시트 각 축의 실제 연습
• 모듈 5 레슨 13 — 종료 기준. 관점을 바꿔 본 뒤에야 수확 체감을 선언한다
• 모듈 3 레슨 8 — 체크리스트. 쓰임의 차이를 비교해 볼 곳
• 모듈 3 — 경계값·동등 분할. "세 가지 크기" 의 이론적 뿌리
• 모듈 10 — 결함 분석. 사고를 치트시트의 한 줄로 바꾸는 절차
• 모듈 16 — 접근성. 키보드 전용 조작 항목의 배경

모듈 5 마무리 — 탐색적 테스팅은 "감으로 아무거나 눌러 보는 것" 이 아니다. 차터로 범위를 정하고(레슨 2), 관점을 바꿔 가며 보고(이 레슨), 세션 노트로 남기고(레슨 11), 멈출 근거를 갖는다(레슨 13). 이 네 가지가 갖춰지면 탐색적 테스팅은 계획·추정·보고가 가능한 정식 테스트 활동이 된다.