개념
"테스트 충분히 했어요?"에 답할 수 없는 이유
스프린트 리뷰 하루 전에 PO가 묻는다. "테스트 충분히 했죠?" QA는 "네, 주요 시나리오는 다 봤습니다"라고 답한다. 이 대화에는 기준이 없다. 무엇의 몇 퍼센트인지 를 말하지 않았기 때문이다.
커버리지 숫자로 답하는 것도 답이 아니다. 단위 테스트 커버리지 82%는 "비즈니스 규칙이 맞게 구현됐는가"에 대해 아무것도 말해 주지 않고, 기능 테스트 120건 통과는 "부하가 몰리면 버티는가"에 대해 아무것도 말해 주지 않는다. 문제는 양이 아니라 종류의 공백 이다.
테스트 4분면은 그 공백을 보이게 만드는 도구다. 커버리지 측정 도구가 아니라 대화 도구 라는 점이 중요하다.
두 개의 축
Brian Marick이 2003년에 제안한 매트릭스를 Lisa Crispin과 Janet Gregory가 『Agile Testing』(2009)에서 4분면 모델로 정리했다. 축은 둘이다.
기술을 향함 (Technology Facing)
▲
│
Q4 │ Q1
성능·부하·보안 │ 단위 테스트
확장성·복구 │ 컴포넌트 테스트
│
제품을 비평 ◀───────────────┼───────────────▶ 팀을 이끎
(Critique Product) │ (Guiding Development)
│
Q3 │ Q2
탐색적 테스팅 │ 기능 테스트·예제
사용성 테스트 │ 스토리 테스트
UAT·알파/베타 │ 프로토타입·시뮬레이션
│
▼
비즈니스를 향함 (Business Facing)- 가로축 — 그 테스트가 팀을 이끄는가, 아니면 완성된 제품을 비평하는가 . 왼쪽은 만들어진 것을 검사하고, 오른쪽은 만들기 전에 방향을 정한다.
- 세로축 — 그 테스트가 기술 언어로 말하는가, 비즈니스 언어로 말하는가 . 위쪽은 개발자가 읽고, 아래쪽은 PO와 고객이 읽는다.
Crispin과 Gregory는 이후 판(『Agile Testing Condensed』, quadrants v3)에서 가로축 왼쪽 레이블을 "Supporting Programming"에서 "Guiding Development" 로 바꿨다. 테스트가 코딩을 거드는 보조 활동이 아니라 무엇을 만들지 정하는 활동 이라는 점을 드러내기 위해서다. 사분면 번호는 활동의 순서가 아니다 — Q1부터 Q4까지 차례대로 하는 것이 아니라, 네 칸이 동시에 돌아간다.
사분면별로 무엇이 들어가는가
| 사분면 | 성격 | 대표 활동 | 주 수행자 | 자동화 |
|---|---|---|---|---|
| Q1 | 기술 · 팀을 이끎 | 단위 테스트, 컴포넌트 테스트, TDD | 개발자 | 전면 자동화 |
| Q2 | 비즈니스 · 팀을 이끎 | 예제 기반 스토리 테스트, 인수 기준 기반 기능 테스트, 프로토타입, 와이어프레임 검토 | 개발자 + QA + PO | 상당 부분 자동화 |
| Q3 | 비즈니스 · 제품을 비평 | 탐색적 테스팅, 시나리오 테스트, 사용성 테스트, UAT, 알파/베타 | QA + 실사용자 | 수동이 본질 |
| Q4 | 기술 · 제품을 비평 | 성능·부하 테스트, 보안 테스트, 신뢰성·복구 테스트, 호환성 | QA + 개발자 + 전문 도구 | 도구 기반 |
Q1과 Q2는 모듈 7(레슨 5)의 TDD·BDD가 앉는 자리다. Q3의 탐색적 테스팅은 모듈 5 전체가 다룬다. Q4의 성능·보안은 스테이지 5에서 따로 다룬다. 이 레슨의 목적은 그 각각을 다시 설명하는 것이 아니라, 네 칸의 균형을 팀이 함께 보게 만드는 것이다.
공백 패턴 세 가지
현장에서 4분면을 그려 보면 공백이 비슷한 모양으로 나온다.
| 패턴 | 그림 | 증상 | 처방 |
|---|---|---|---|
| Q3 편중형 | Q3만 가득 참 | QA 혼자 수동으로 다 본다. 회귀에 매 스프린트 3일 | Q1·Q2를 개발과 함께 채운다. 회귀 부담을 자동화로 옮긴다 |
| Q1·Q2 편중형 | 위·왼쪽만 가득 참 | 테스트는 다 초록인데 운영에서 사용자가 못 쓴다고 한다 | Q3 탐색 차터를 스프린트에 배정한다 |
| Q4 공백형 | 오른쪽 위가 빔 | 기능은 되는데 이벤트 날 터진다 | 스프린트마다 최소 한 번 부하·보안 점검을 DoD에 건다 |
가장 흔한 것은 Q3 편중형 이다. QA가 한 명이고 개발자가 여섯 명인 팀에서 자연스럽게 생긴다. 이 경우 QA가 더 열심히 하는 것은 해법이 아니다. 4분면 그림을 스프린트 계획 회의에 가져가서 "이 칸이 비어 있어서 저 칸에 일이 몰린다"를 보여 주는 것이 해법이다.
스프린트 안 타이밍 — 사분면을 날짜에 꽂기
4분면은 종류를 알려 주지만 순서는 알려 주지 않는다. 순서는 팀이 설계해야 한다. 2주 스프린트의 예다.
Day -3 -2 -1 │ 1 2 3 4 5 6 7 8 9 10
───────────┼────────────────────────────────────────
Q2 ██ ██ │ ██ ██ ← 예제/AC 확정은 스프린트 "전"에 끝난다
Q1 │ ██ ██ ██ ██ ██ ██ ██ ← 개발과 동시에, 매 커밋
Q3 │ ██ ██ ██ ██ ██ ██ ██ ← 기능이 돌아가는 순간부터 탐색 시작
Q4 │ ██ ██ ██ ← 야간 파이프라인 + 스프린트 말 1회
───────────┼────────────────────────────────────────
│ ▲
│ 리뷰/DoD 판정세 가지가 설계의 핵심이다.
- Q2는 스프린트가 시작되기 전에 끝난다. 인수 기준과 예제를 스프린트 안에서 합의하기 시작하면 개발이 멈춘다. 리파인먼트에서 끝내는 이유다(레슨 3).
- Q3는 "개발 완료" 이후가 아니라 "돌아가는 순간"부터 시작한다. 기능 플래그 뒤에서라도 화면이 뜨면 탐색을 시작한다. 이것이 스프린트 마지막 이틀 몰림을 푸는 유일한 방법이다.
- Q4는 사람이 스프린트 안에 넣지 않으면 영원히 밀린다. 야간 파이프라인으로 상시 돌리고, 사람이 결과를 보는 시각을 정해 둔다.
몰림 현상을 진단하는 한 줄 지표
스프린트마다 "스토리가 QA에 도착한 시각" 을 기록한다. 스프린트 10일 중 8일 차 이후에 도착한 스토리의 비율이 그대로 몰림 지표다.
| 8일 차 이후 도착 비율 | 해석 |
|---|---|
| 20% 이하 | 흐름이 있다 |
| 20~50% | 스토리가 너무 크거나 Q1이 약하다 |
| 50% 초과 | 스프린트가 사실상 미니 워터폴이다 |
50%를 넘으면 원인은 거의 항상 둘 중 하나다 — 스토리가 안 쪼개졌거나(레슨 3), Q1이 없어서 개발이 "다 만들고 한 번에" 넘기거나.
4분면을 쓰면 안 되는 방식
- 사분면을 채우기 위한 테스트를 만들지 않는다. Q4가 비었다고 의미 없는 부하 테스트를 만들면 유지 비용만 생긴다. 비어 있는 칸은 "여기 위험이 있는가"를 묻는 신호이지 할당량이 아니다.
- 사분면을 담당자 구분으로 쓰지 않는다. "Q1은 개발, Q3는 QA"로 고정하면 모듈 7에서 본 "품질은 팀 전체의 책임"이 무너진다. Q3에 개발자를 초대하는 것이 몹 테스팅(레슨 4)이다.
- 번호를 단계로 읽지 않는다. Q1 → Q2 → Q3 → Q4 순서로 진행하는 프로세스가 아니다.
실무에서 왜 필요한가
4분면의 실제 값어치는 회의에서 말이 통하게 만드는 것 에 있다. "테스트 리소스가 부족합니다"는 예산 이야기로 들리고 대개 거절당한다. 반면 4분면 그림 위에 Q3만 빨갛게 칠해서 "우리 팀 테스트의 80%가 이 칸에 있고, 그래서 회귀에 매 스프린트 3일이 든다"를 보여 주면, 그것은 구조 이야기가 되고 개발 리드가 함께 푸는 문제가 된다.
또 하나는 신규 팀 진단 도구 로서의 값이다. 새 스쿼드를 맡았을 때 30분 안에 팀의 품질 상태를 파악해야 한다면, 4분면 워크숍이 가장 빠르다. 팀원들이 각자 포스트잇에 자기가 하는 테스트를 적어 칸에 붙이게 하면, 팀이 스스로 공백을 발견한다. 남이 지적한 공백보다 스스로 찾은 공백이 훨씬 잘 메워진다.
채용시장에서의 위치
면접에서 "애자일에서 테스트 전략을 어떻게 세우셨나요"는 자주 나오는 질문이다. 4분면은 이 질문에 구조를 가진 답 을 줄 수 있는 몇 안 되는 도구다. 여기에 "우리 팀은 Q4가 비어 있어서 부하 점검을 DoD에 넣었고, 그 뒤로 이벤트 날 장애가 없었다"처럼 한 칸을 실제로 메운 사례를 붙이면 답이 완성된다. ISTQB CTFL-AT(Agile Tester) 실러버스도 이 모델을 다룬다.