435. 체크리스트 (Checklist) 기반 테스팅

⚠️ 이 문서는 복잡한 테스트 설계 기법(수학적 모델링 등)을 쓰기에는 시간이나 자원이 부족할 때, 테스터의 경험과 과거의 버그 내역을 바탕으로 "이거 이거는 꼭 확인해 봐야 해!"라는 필수 확인 목록을 만들어 빠르게 훑고 지나가는 실용적인 테스트 기법인 '체크리스트 기반 테스팅'을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 체크리스트 기반 테스팅(Checklist-based Testing)은 경험 기반 테스팅(Experience-based Testing)의 일종으로, 과거에 자주 발생했던 결함이나 도메인 전문가의 노하우를 '질문 목록(O/X)' 형태로 정리해 두고 이를 하나씩 지워나가며 테스트하는 방법이다.
  2. 가치: 테스트 케이스를 설계하는 데 드는 막대한 문서화 시간을 단축시켜 주며, 초보 테스터도 고수 테스터가 만들어둔 체크리스트만 있으면 최소한의 치명적 결함들을 빼먹지 않고 빠르게 잡아낼 수 있도록 상향 평준화를 이뤄준다.
  3. 기술 체계: 공식적인 명세서(Specification)가 부실할 때 가장 빛을 발하며, 보안(Security)이나 사용성(Usability) 같은 비기능적 테스트, 또는 탐색적 테스트(Exploratory Testing)를 수행할 때 훌륭한 길잡이(가이드라인) 역할을 한다.

Ⅰ. 개요: 경험을 문서화하다 (Context & Necessity)

"이번 주 금요일 런칭인데, 테스트 케이스 1만 개 짤 시간 없어요! 어떡하죠?"

테스트 공학 교과서에는 동등 분할, 직교 배열 등 우아하고 수학적인 테스트 기법들이 가득하지만, 현실의 소프트웨어 프로젝트는 항상 시간에 쫓긴다. 기획서는 부실하고 테스트 스크립트를 짤 시간조차 없을 때 QA 팀장은 결단을 내린다. "우리 회사가 지난 3년 동안 쇼핑몰 만들면서 가장 많이 터졌던 버그 50개만 뽑아서 **체크리스트(Checklist)**를 만들어! 이것만 확인하고 오픈한다!"

  • 결제 취소 버튼을 연타했을 때 돈이 두 번 환불되지 않는가?
  • 아이디 칸에 특수문자 <script>를 넣었을 때 에러가 안 나는가?
  • 뒤로 가기 버튼을 눌렀을 때 장바구니가 날아가지 않는가?

이처럼 경험과 직관, 그리고 과거의 오답 노트를 무기 삼아 시스템의 급소를 빠르게 찌르는 것이 바로 체크리스트 기반 테스팅이다.

📢 섹션 요약 비유: 비행기가 이륙하기 전 조종사가 수백 쪽짜리 매뉴얼을 다 읽을 시간은 없습니다. 대신 "엔진 온도 정상? 윙 플랩 각도 정상? 무전기 켜짐?"이라고 쓰인 딱 한 장짜리 체크리스트(Checklist) 팻말을 들고 O/X를 쳐가며 치명적인 사고를 5분 만에 예방하는 것과 정확히 같습니다.

Ⅱ. 체크리스트 테스팅의 장점과 한계

1. 강력한 장점 (Agility & Experience)

  • 초보자의 상향 평준화: 신입 QA가 들어와도, 시니어 QA가 만들어둔 '보안 체크리스트' 한 장만 쥐여주면 그 신입은 시니어의 시선으로 보안 버그를 짚어낼 수 있다.
  • 명세서가 없어도 가능: "기능 명세서가 완벽해야 테스트를 짠다"는 명세 기반 테스트의 깐깐함을 무시한다. "그냥 앱 켜놓고 이 리스트에 있는 거 되나 안 되나 눌러봐!"라는 식의 애자일(Agile)한 접근이 가능하다.
  • 표준 및 규정 준수에 탁월: 웹 접근성 검사, 개인정보보호법(GDPR) 준수 검사 등 법적/규제적 요건을 빠짐없이 검사할 때 가장 완벽한 툴이다.

2. 치명적인 단점 (Omission & Outdated)

  • 체크리스트에 없는 버그는 영원히 못 찾는다: 테스터의 시야가 체크리스트 안에 갇혀버리는 '터널 시야(Tunnel Vision)' 현상이 발생한다. 리스트 밖에서 터지는 기상천외한 버그는 잡을 수가 없다.
  • 유지보수의 저주: 소프트웨어는 변하는데 체크리스트 문서가 업데이트되지 않으면, 있지도 않은 옛날 메뉴를 검사하려 들거나 정작 중요한 새 기능의 버그는 모조리 놓치게 된다.
┌────────────────────────────────────────────────────────────────────────┐
│           명세 기반 테스트 vs 체크리스트 기반 테스트 비교 시각화       │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│ 📘 [ 명세 기반 테스트 (Black-box) ]                                    │
│   입력: 기획서 (SRS)                                                   │
│   방식: 기획서를 분석해서 수학적으로 완벽한 테스트 케이스 100개 도출   │
│   특징: 논리적이고 빈틈없지만 시간이 너무 오래 걸림                    │
│                                                                        │
│ 📋 [ 체크리스트 기반 테스트 (Experience-based) ]                       │
│   입력: 고수들의 경험, 과거 버그 리포트 (오답 노트)                    │
│   방식: "이건 꼭 확인해!" 20개 리스트만 O/X로 빠르게 체크              │
│   특징: 10분 만에 테스트 가능. 단, 리스트에 없는 버그는 놓칠 수 있음!  │
└────────────────────────────────────────────────────────────────────────┘

Ⅲ. 실무 활용: 탐색적 테스팅(Exploratory)과의 결합

체크리스트 테스팅의 단점(리스트에 없는 건 못 찾음)을 보완하기 위해, 실무에서는 자유도를 극한으로 끌어올린 **탐색적 테스팅(Exploratory Testing)**과 결합하여 사용한다.

  • 차터 (Charter) 기반 탐색: "오늘은 '결제 모듈'에 대해서만 자유롭게 버그를 사냥해 보자!"
  • 체크리스트의 가이드 역할: 테스터는 자유롭게 결제 화면을 누르며 버그를 찾되, 옆에 조그만 체크리스트를 띄워두고 "아, 맞다! 뒤로가기 버튼 연타하는 거 잊지 말고 해봐야지!" 하고 길을 잃지 않는 용도(가이드레일)로만 체크리스트를 활용한다.

Ⅳ. 결론

"완벽을 추구하다 늦는 것보다, 핵심을 찌르고 제때 출시하는 것이 낫다." 체크리스트 기반 테스팅은 학술적으로는 덜 우아할지 몰라도, 전 세계 수많은 IT 스타트업과 애자일 팀들이 매일 배포(CI/CD)를 할 수 있게 지탱해 주는 실전 최고의 무기다. 과거의 피눈물 나는 실패와 뼈아픈 버그 리포트들이 한 줄 한 줄 녹아들어 만들어진 회사의 '비급 마법서'와 같기 때문이다. 훌륭하게 관리되는 체크리스트는 그 자체로 QA 조직의 경험적 자산(Asset)이자, 프로젝트의 치명적 리스크를 최단 시간에 쳐내는 가장 예리한 칼날이다.

📌 관련 개념 맵

  • 상위 분류: 경험 기반 테스팅 (Experience-based Testing)
  • 형제 기법: 오류 예측 (Error Guessing), 탐색적 테스팅 (Exploratory Testing)
  • 대척점 기법: 명세 기반 테스팅 (Black-box), 구조 기반 테스팅 (White-box)
  • 적용 분야: 사용성(UX) 검사, 보안 취약점 검사, 릴리스 전 산티니(Sanity) 체크

👶 어린이를 위한 3줄 비유 설명

  1. 내일 아침 소풍을 가기 전에 짐을 챙겨야 하는데, 엄마가 "수학적으로 배낭의 빈 공간을 계산해서 챙기렴"이라고 하면 머리가 아프죠?
  2. 그럴 때 엄마가 "1. 돗자리 챙겼니? 2. 김밥 챙겼니? 3. 물병 챙겼니?"라고 적힌 종이(체크리스트) 한 장을 주면 5분 만에 짐을 쌀 수 있어요.
  3. 이렇게 과거의 경험을 살려서 꼭! 확인해야 할 중요한 것들만 목록으로 만들어서 빠르고 확실하게 검사하는 방법을 체크리스트 테스팅이라고 한답니다!