개념
테스트 가능하다는 것의 의미
요구사항이 "테스트 가능하다"는 건 "이 요구사항이 충족됐는지 아닌지를 명확하게 판단할 수 있는 기준이 있다" 는 뜻이다. 판단 기준이 사람마다 다르게 해석된다면, 그 요구사항은 테스트할 수 없다 — 통과인지 실패인지 합의가 안 되기 때문이다.
여기서 먼저 분리해둘 것이 있다. "테스트하기 어렵다"와 "테스트할 수 없다"는 전혀 다른 문제다.
- 동시 접속자 1만 명 상황을 만들어보는 건 어렵다. 장비도 시간도 든다. 하지만 돈과 시간을 쓰면 통과인지 실패인지는 결국 판정할 수 있다.
- "시스템은 사용자 친화적이어야 한다"는 불가능하다. 장비를 아무리 늘려도, 시간을 아무리 써도 통과 여부에 합의할 수 없다. 기준 자체가 없기 때문이다.
어려움은 비용의 문제이고, 테스트 불가능성은 기준의 문제다. 요구사항 단계에서 QA가 반드시 잡아야 하는 건 후자다. 비용 문제는 나중에 도구·환경으로 풀 수 있지만, 기준 문제는 시간이 지날수록 오히려 풀기 어려워진다 — 이미 만들어진 결과물이 무의식중에 "기준"처럼 굳어버리기 때문이다.
쉬운 비유로 다시 보기 — 심판이 있는 경기와 없는 경기
농구에서 "공이 링을 통과하면 2점"은 누가 심판을 봐도 같은 판정이 나온다. 규칙이 관찰 가능한 사건 하나에 걸려 있기 때문이다. 그런데 규칙에 "멋진 플레이를 하면 가산점"이라는 항목이 있다고 해보자. 심판 세 명이 같은 장면을 보고 각각 다른 점수를 줄 것이고, 경기가 끝난 뒤에는 "그게 왜 가산점이냐"는 항의가 남는다.
요구사항도 똑같다.
| 규칙이 명확한 경기 | 심판 재량에 맡긴 경기 | |
|---|---|---|
| 판정 | 누가 봐도 같음 | 사람마다 다름 |
| 항의 | 거의 없음 | 경기 끝나고 몰림 |
| 선수 | 무엇을 하면 점수가 나는지 안다 | 뭘 해야 할지 모른 채 뛴다 |
마지막 줄이 특히 중요하다. 테스트 가능한 요구사항은 QA만을 위한 장치가 아니다. 규칙이 명확해야 선수가 무엇을 해야 할지 알듯, 판정 기준이 명확해야 개발자도 "이제 다 됐다"를 스스로 판단할 수 있다. 기준이 없으면 개발자는 완료 여부를 QA에게 물어봐야만 알 수 있고, 그 판정은 항상 가장 늦은 시점에 내려진다.
그리고 소프트웨어에서 그 "항의"는 대개 릴리즈 직전, 아무도 시간이 없을 때 몰린다.
테스트 불가능한 요구사항의 특징
| 특징 | 예시 | 왜 판정이 안 되는가 | QA가 던질 질문 |
|---|---|---|---|
| 모호한 형용사 | "시스템은 사용자 친화적 이어야 한다" | "친화적"의 기준이 사람마다 다름 | 무엇이 관찰되면 친화적이라고 볼 수 있나요? |
| 측정 불가능한 정도 표현 | "응답 속도가 충분히 빨라야 한다" | "충분히"가 몇 초인지 안 정해짐 | 몇 초를 넘으면 실패로 볼까요? |
| 검증 방법이 없음 | "코드는 유지보수하기 좋아야 한다" | 무엇을 확인해야 통과인지 불명확 | 이걸 누가 어떻게 확인하나요? |
| 여러 해석이 가능 | "적절한 에러 메시지를 보여준다" | "적절한"의 기준 없음 | 메시지에 반드시 들어가야 할 정보는 뭔가요? |
| 판정 주체가 없음 | "사용자가 만족해야 한다" | 누가 만족을 선언하는지 없음 | 누구의 어떤 판단을 근거로 통과로 볼까요? |
| 전칭 부정형 | "어떤 경우에도 데이터가 유실되지 않는다" | "모든 경우"를 다 볼 수 없어 통과 선언이 불가능 | 어떤 장애 상황까지를 범위로 볼까요? |
아래 두 줄은 처음 보면 멀쩡해 보여서 잘 통과되는 유형이라 따로 짚는다.
판정 주체가 없는 요구사항. "사용자가 만족해야 한다"에는 숫자도 형용사도 아닌 다른 문제가 있다. 문장 자체는 뜻이 분명한데, 그 판단을 누가 언제 내리는지가 없다. 릴리즈 회의에서 "사용자가 만족할까요?"라는 질문이 나오면 그 자리에 있는 가장 목소리 큰 사람의 의견이 판정이 된다. 요구사항에 "누가 판정하는가"를 넣는 것만으로 통과 여부가 훨씬 안정된다.
전칭 부정형 요구사항. "어떤 경우에도 유실되지 않는다"는 논리적으로 통과를 증명할 수 없는 형태다. 유실 사례를 하나 찾으면 실패는 증명되지만, 아무리 많이 테스트해도 통과는 증명되지 않는다(모듈 1의 "테스트는 결함의 존재를 보일 뿐 부재를 증명하지 못한다"와 정확히 같은 이야기다). 그래서 실무에서는 범위를 잘라준다 — "단일 서버 장애 시, 커밋 완료된 주문 데이터는 유실되지 않는다"처럼.
테스트 가능한 형태로 바꾸기
모호한 요구사항은 구체적인 숫자, 조건, 관찰 가능한 동작으로 바꾸면 테스트 가능해진다.
❌ "시스템은 사용자 친화적이어야 한다."
✅ "회원가입은 3단계 이하로 완료할 수 있어야 하고, 각 단계의 필수 입력 필드는 3개를 넘지 않아야 한다."
❌ "응답 속도가 충분히 빨라야 한다."
✅ "검색 결과는 요청 후 2초 이내에 화면에 표시되어야 한다 (95번째 백분위수 기준)."
❌ "적절한 에러 메시지를 보여준다."
✅ "입력값이 유효하지 않으면, 어떤 필드가 왜 잘못됐는지 필드 아래에 즉시 표시한다."
❌ "관리자는 필요한 정보를 볼 수 있어야 한다."
✅ "관리자 대시보드는 최근 30일간의 일별 가입자 수, 결제 건수, 환불 건수를 표 형태로 보여준다."
❌ "장애 시 빠르게 복구되어야 한다."
✅ "단일 서버 인스턴스가 다운되면, 남은 인스턴스로 트래픽이 60초 이내에 전환되고 사용자에게는 오류 화면이 노출되지 않는다."
바뀐 문장들은 전부 "통과/실패를 판단할 수 있는 관찰 가능한 기준" 을 담고 있다. 이게 테스트 가능성의 핵심이다.
다시 쓰는 4단계 절차
"구체적으로 쓰라"는 말은 막막하다. 실제로는 아래 순서로 하면 대부분 풀린다.
- 모호한 단어에 표시한다. 빠른, 안전한, 편리한, 직관적인, 적절한, 충분한, 안정적인, 최소한의, 대부분의 — 이런 단어에 밑줄을 긋는다.
- "누가 판정하는가"를 상상한다. 이 요구사항의 통과 여부를 릴리즈 회의에서 선언해야 한다면, 무엇을 근거로 삼을 것인가?
- 관찰 가능한 신호로 바꾼다. 화면에 보이는 것, 로그에 남는 것, 응답으로 돌아오는 것, 시간·횟수로 셀 수 있는 것 중에서 고른다.
- 조건·환경·허용 범위를 붙인다. 어떤 상황에서, 어떤 데이터로, 몇 퍼센트까지 허용되는지. 이 4단계를 빼먹는 게 가장 흔한 실수이고, 바로 다음 절의 주제다.
측정 가능과 테스트 가능은 같은 말이 아니다
여기가 이 레슨에서 가장 중요한 부분이다. 많은 사람이 "숫자를 넣으면 테스트 가능해진다"고 배우고 거기서 멈춘다. 하지만 숫자는 테스트 가능성의 필요조건이지 충분조건이 아니다.
앞에서 좋은 예시로 든 문장을 다시 보자.
"검색 결과는 요청 후 2초 이내에 화면에 표시되어야 한다."
숫자가 들어갔으니 측정은 할 수 있다. 그런데 QA 두 명이 각자 측정하면 서로 다른 결론이 나온다. 왜 그런지 축을 하나씩 뜯어보자.
| 빠진 축 | 안 정하면 벌어지는 일 |
|---|---|
| 측정 환경 | 개발자는 사내 유선망에서 0.8초, QA는 지하철 LTE에서 3.4초. 둘 다 사실이다 |
| 데이터 규모 | 상품 100건짜리 테스트 DB에서는 통과, 상품 200만 건 운영 DB에서는 실패 |
| 몇 번째 요청인가 | 첫 요청은 캐시가 비어 4초, 두 번째부터 0.3초. "2초"는 어느 쪽 얘기인가 |
| 통계 기준 | 평균 1.2초지만 상위 5%는 6초. 평균으로 보면 통과, p95로 보면 실패 |
| 측정 시작·끝 지점 | 서버가 응답을 다 보낸 시점인가, 화면에 글자가 그려진 시점인가. 보통 1초 이상 차이 난다 |
| 허용 실패율 | 100번 중 3번 2초를 넘으면 실패인가 통과인가 |
표에 나온 말 둘을 짚고 가자. 캐시 는 한 번 꺼내 온 것을 가까운 곳에 잠깐 베껴 두는 장치다 — 그래서 같은 화면이라도 처음 열 때와 두 번째 열 때 속도가 크게 다르다. p95 는 "느린 쪽 5%를 뺀 나머지가 이 안에 들어온다" 는 뜻이다. 100번 중 95번이 그 시간 안에 끝났다는 말이고, 평균보다 사용자 체감에 가깝다 — 평균은 아주 느린 몇 건에 가려진다.
여섯 축이 다 빠져 있으면, "2초 이내"라는 숫자는 논쟁을 없애는 게 아니라 논쟁을 숫자를 낀 논쟁으로 바꿀 뿐이다. 이걸 다 채우면 이렇게 된다.
✅ "상품 200만 건이 적재된 스테이징 환경에서, 4G 네트워크 프로파일(다운로드 10Mbps, RTT 70ms) 조건으로 검색 요청을 100회 반복했을 때, 검색어 입력 후 결과 목록의 첫 화면이 그려질 때까지의 시간이 95번째 백분위수 기준 2초 이내여야 한다. 캐시가 비워진 첫 요청 1회는 측정에서 제외한다."
길다. 처음 보면 "이렇게까지 써야 하나" 싶을 것이다. 하지만 이 문장이 있으면 릴리즈 회의에서 성능 논쟁이 아예 발생하지 않는다. 길이는 한 번 드는 비용이고, 논쟁은 매번 드는 비용이다.
한 가지 덧붙이면, 이 여섯 축을 전부 QA가 혼자 정할 필요는 없고 그래서도 안 된다. QA가 하는 일은 "이 축이 비어 있다"를 드러내는 것이고, 값을 정하는 건 제품·개발과 함께 하는 일이다. 이 구분이 뒤에 나올 "고칠 권한이 없을 때" 절의 핵심이 된다.
직접 해부해보기 — "동시 접속자 1,000명을 지원한다"
같은 방식으로 하나 더 뜯어보자. 이 문장도 숫자가 들어 있어서 언뜻 테스트 가능해 보인다. 하지만 아래 질문들에 답할 수 없다면 판정은 여전히 불가능하다.
- "동시 접속"이 무슨 뜻인가? 브라우저 탭을 열어둔 사람 1,000명인가, 같은 1초 안에 요청을 보내는 사람 1,000명인가? 후자가 전자보다 훨씬 가혹하다.
- 1,000명이 무엇을 하고 있는가? 전부 메인 화면만 보고 있는 것과, 전부 결제를 누르는 것은 부하가 수십 배 차이 난다.
- "지원한다"는 어떤 상태인가? 죽지만 않으면 되는가, 응답 시간이 평소와 같아야 하는가, 오류율이 몇 퍼센트 이하여야 하는가?
- 얼마나 오래 버텨야 하는가? 1분인가 1시간인가. 메모리 누수는 짧은 부하에서는 안 드러난다.
- 어떤 규모의 인프라에서인가? 서버를 20대 붙이면 되는 얘기라면 요구사항이라기보다 예산 얘기다.
이 질문들을 반영하면 이렇게 바뀐다.
✅ "운영과 동일한 사양의 서버 2대 구성에서, 초당 200건의 주문 생성 요청을 10분간 지속했을 때 HTTP 5xx 응답 비율이 0.1% 이하이고 응답 시간 p95가 1.5초 이내를 유지한다."
원문에는 있던 "1,000명"이라는 숫자가 사라졌다는 점을 눈여겨보자. 숫자를 지키는 게 목적이 아니라, 판정 가능한 문장을 만드는 게 목적이다. 원래 숫자가 무엇을 의미했는지 되물어보면, 종종 그 숫자 자체가 근거 없이 적힌 것이었다는 사실이 드러난다. 이 발견도 QA가 요구사항 단계에서 만드는 가치다.
사례 연구 — 릴리즈 D-1, "이 정도면 빠른 거 아닌가요"
테스트 불가능한 요구사항이 실제로 어떻게 갈등이 되는지, 흔한 장면 하나로 보자. 요구사항 문서에는 이렇게만 적혀 있었다. "검색은 빠르게 동작해야 한다."
릴리즈 하루 전 점검 회의다.
QA: 검색 성능 확인했는데요, 상품이 많은 카테고리에서 결과가 나오기까지 4초 정도 걸립니다. 이건 릴리즈 블로커로 봐야 할 것 같습니다.
개발: 제 로컬에서는 0.6초인데요? 방금 다시 해봐도 1초 안 넘습니다.
QA: 저는 운영 데이터가 복제된 스테이징에서 모바일 네트워크로 쟀습니다.
PM: 음… 4초면 좀 느린 것 같긴 한데, 요구사항에는 "빠르게"라고만 되어 있어서요. 이 정도면 빠른 거 아닌가요? 경쟁사도 비슷하지 않나요?
개발: 지금 고치려면 인덱스를 다시 설계해야 해서, 최소 3일입니다.
PM: 내일이 오픈인데요.
이 회의에서 무슨 일이 벌어졌는지 정리해보자.
| 겉으로 보이는 문제 | 실제 문제 |
|---|---|
| 4초가 느린가 아닌가로 다툰다 | 기준이 없어서 지금 즉석에서 기준을 만들고 있다 |
| 개발과 QA의 측정값이 다르다 | 측정 환경·데이터 규모가 합의된 적이 없다 |
| 고치려면 3일이 필요하다 | 설계 단계에 알았다면 3일이 아니라 반나절이었다 |
| PM이 판단을 못 한다 | 판정 주체와 근거가 요구사항에 없다 |
가장 나쁜 건 마지막이다. 기준이 없으면 논쟁은 기술 논쟁이 아니라 힘의 논쟁이 된다. 릴리즈 일정이 걸려 있으니 대개는 "일단 나가고 다음 스프린트에 개선"으로 끝나고, 그 개선 티켓은 우선순위에서 밀린다.
이 회의를 3주 전에 없앨 수 있었던 한 문장은 이것이다.
"상품 200만 건 기준 스테이징 환경에서, 4G 네트워크 조건으로 검색 결과 첫 화면이 p95 기준 2초 이내에 표시된다."
이 문장이 요구사항에 있었다면, 개발자는 설계 단계에서 인덱스 구조를 다르게 잡았을 것이다. 4초가 나왔을 때도 논쟁이 아니라 "기준 미달, 수정 필요"라는 사실 확인으로 끝난다. 요구사항을 테스트 가능하게 만드는 일의 진짜 가치는 QA가 편해지는 게 아니라, 릴리즈 직전의 감정적 협상을 개발 시작 전의 기술적 결정으로 옮기는 것이다.
모듈 1에서 본 결함 수정 비용 곡선을 떠올려보자. 이 사례는 그 곡선을 요구사항 문장 하나로 실감하는 예다 — 같은 문제를 요구사항 단계에서 처리하면 문장 한 줄이고, 릴리즈 전날에 처리하면 3일과 신뢰다.
모든 요구사항이 숫자가 되지는 않는다
지금까지 읽으면 "모든 요구사항을 숫자로 바꾸면 되겠다"고 생각하기 쉽다. 그렇지 않다. 정량화가 불가능하거나, 억지로 정량화하면 오히려 본질을 놓치는 요구사항이 있다.
"관리자 페이지는 직관적이어야 한다"를 억지로 "클릭 수 5회 이내"로 바꾸면, 클릭 수는 줄었지만 아무도 못 찾는 메뉴가 만들어질 수 있다. 이럴 때 쓰는 방법이 간접 측정이다. 정성적 목표를 그대로 두되, 그 목표가 달성됐음을 시사하는 관찰 가능한 신호를 기준으로 삼는다.
간접 측정에는 크게 네 가지 방식이 있다.
| 방식 | 어떻게 하는가 | 예시 |
|---|---|---|
| 과업 성공률 | 실제 사용자에게 과업을 주고 성공 여부를 센다 | "이 화면을 처음 보는 사용자 5명 중 4명이 도움말 없이 3분 안에 환불 처리를 완료한다" |
| 구조 조건 치환 | 목표를 만족시키는 관찰 가능한 구조 조건으로 바꾼다 | "주요 작업은 메인 화면에서 2뎁스 이내에 도달할 수 있다" |
| 표준·체크리스트 준수 | 이미 합의된 외부 기준을 빌려온다 | "WCAG 2.1 AA 기준 항목을 모두 통과한다" |
| 기준 예시 대조 | 통과로 인정할 결과물 예시를 미리 정해둔다 | "에러 메시지는 별첨 문구 가이드의 형식(무엇이·왜·다음에 뭘)을 따른다" |
첫 번째 방식이 특히 강력하다. "직관적"이라는 말은 판정할 수 없지만, "처음 쓰는 사용자 5명 중 4명이 3분 안에 완료"는 누가 봐도 같은 결론이 나온다. 정성적 목표를 버리지 않으면서 판정 가능성을 얻는 것이다. 이 방식은 모듈 1에서 배운 확인(Validation) 활동과도 직접 닿아 있다 — 명세 대조가 아니라 실제 사용자로 판정하기 때문이다.
다만 간접 측정에는 반드시 따라붙는 함정이 있다. 대리 지표는 목표가 되는 순간 왜곡된다. "5명 중 4명"이라는 기준이 정해지면, 사용자 모집을 쉬운 쪽으로 하거나 과업을 쉽게 설계하려는 압력이 생긴다. 그래서 간접 측정 기준을 쓸 때는 측정 방법 자체(누구를 어떻게 모집하는지, 과업 문구가 무엇인지)도 함께 적어둬야 한다.
INVEST — 테스트 가능성이 놓인 자리
애자일에서 사용자 스토리 품질을 볼 때 쓰는 INVEST 라는 기준이 있다. Bill Wake가 정리한 여섯 글자로, 이 레슨의 Testable은 그중 마지막 한 축이다. 나머지 다섯도 알아두면 요구사항을 볼 때 시야가 넓어진다.
| 글자 | 의미 | 위반하면 |
|---|---|---|
| Independent | 다른 스토리와 독립적으로 개발·배포 가능 | 순서가 꼬여 하나가 밀리면 전부 밀린다 |
| Negotiable | 세부 구현은 협상 가능한 여지가 있음 | 대화 없이 사양서만 던져지는 관계가 된다 |
| Valuable | 사용자·비즈니스에 가치가 있음 | 왜 만드는지 모른 채 만들게 된다 |
| Estimable | 규모를 추정할 수 있을 만큼 이해됨 | 일정을 세울 수 없다 |
| Small | 한 스프린트에 끝날 만큼 작음 | 진행 상황이 보이지 않는다 |
| Testable | 완료 여부를 판정할 수 있음 | 아무도 "다 됐다"를 말할 수 없다 |
왜 QA에게는 Testable이 특히 중요한가. 나머지 다섯은 위반해도 팀이 어떻게든 굴러간다 — 느려지고, 답답하고, 추정이 틀리지만 진행은 된다. 그런데 Testable이 무너지면 완료의 정의 자체가 사라진다. 개발도 끝났다고 말할 수 없고, QA도 통과를 선언할 수 없고, PM도 릴리즈 결정을 내릴 근거가 없다. QA의 업무 전체가 "기준 대비 판정"이라는 한 문장으로 요약된다는 걸 생각하면, Testable은 QA에게 여섯 개 중 하나가 아니라 나머지가 서 있는 바닥에 가깝다.
동시에, 나머지 다섯 항목의 위반도 QA에게는 유용한 신호다.
| 눈에 띄는 것 | QA가 의심할 것 |
|---|---|
| 스토리가 다른 여러 기능에 의존한다(I 위반) | 통합 지점이 많다 = 결함이 몰릴 자리다 |
| 스토리가 지나치게 크다(S 위반) | 요구사항 안에 여러 기능이 섞여 있다. 쪼개면 누락이 드러난다 |
| 추정이 안 된다(E 위반) | 팀이 아직 요구사항을 이해하지 못했다는 뜻이다 |
| 가치가 설명되지 않는다(V 위반) | 무엇을 우선 테스트할지 판단할 근거가 없다 |
특히 Negotiable과 Testable의 균형을 기억해두자. 테스트 가능성을 이유로 요구사항에 구현 세부까지 못 박으면 N을 해친다. "결과가 2초 이내에 보인다"는 Testable하면서도 Negotiable하지만, "Redis 캐시를 써서 2초 이내에 보인다"는 구현을 고정해버린다. 판정 기준은 결과에 걸고, 방법은 열어둔다. 이게 좋은 요구사항의 감각이다.
테스트 가능성을 판단하는 질문
요구사항을 보고 아래 질문에 "예"라고 답할 수 있으면 테스트 가능하다고 볼 수 있다.
- 이 요구사항이 충족됐는지, 서로 다른 두 사람이 같은 결론을 내릴 수 있는가?
- 통과/실패를 가르는 구체적인 기준(숫자, 조건)이 있는가?
- 이 요구사항을 확인할 방법(테스트 케이스, 측정 도구 등)을 상상할 수 있는가?
여기에 이 레슨에서 배운 내용을 더하면 두 개가 붙는다.
- 그 기준을 적용할 조건과 환경이 정해져 있는가? (어떤 데이터로, 어떤 환경에서, 몇 번째 시도부터, 어떤 통계 기준으로)
- 통과 여부를 누가 언제 선언하는지가 분명한가?
3번까지만 만족하면 "측정 가능"이고, 5번까지 만족해야 "테스트 가능"이다. 이 차이가 릴리즈 직전에 논쟁이 생기느냐 마느냐를 가른다.
고칠 권한이 없을 때 — 질문으로 되돌리기
신입 QA가 가장 자주 막히는 지점이 여기다. 모호한 요구사항을 발견했는데, 요구사항 문서를 고칠 권한은 QA에게 없다. 그럼 어떻게 하는가?
답은 간단하다. 고치는 게 아니라, 답이 필요한 질문으로 만들어 작성자에게 되돌린다. QA가 임의로 기준을 정해 문서를 고치면, 그 기준은 팀의 합의가 아니라 QA 개인의 추측이 되고, 나중에 "누가 이렇게 정했냐"는 문제가 다시 생긴다.
같은 지적도 표현에 따라 결과가 완전히 달라진다.
| 이렇게 말하면 | 이렇게 말하면 |
|---|---|
| "이 요구사항은 테스트 불가능합니다." | "이 문장으로는 제가 통과 판정을 내릴 수가 없어서요, 기준을 하나만 정해주실 수 있을까요?" |
| "빠르게가 몇 초인지 안 적혀 있는데요." | "성능 기준을 p95 2초로 잡아도 될까요? 다른 기준이 있으시면 맞추겠습니다." |
| "이건 잘못 쓰신 것 같습니다." | "제가 이 문장을 A로 이해했는데, B로 읽힐 수도 있을 것 같아서요. 어느 쪽이 맞을까요?" |
오른쪽 문장들의 공통점은 세 가지다.
- 문제를 사람이 아니라 판정 상황에 둔다. "당신이 잘못 썼다"가 아니라 "제가 판정을 못 한다"로 시작하면 상대가 방어적으로 반응하지 않는다.
- 초안을 함께 제시한다. "몇 초인가요?"보다 "p95 2초로 잡아도 될까요?"가 훨씬 빨리 답을 받는다. 빈칸을 채우는 것보다 제시된 안에 동의하거나 고치는 게 쉽기 때문이다.
- 결정권은 넘긴다. 초안을 내되 마지막은 항상 "이게 맞을까요?"로 끝난다. 기준을 정하는 건 제품의 결정이지 QA의 결정이 아니다.
그래도 답을 못 받는 경우가 있다. 담당자가 바쁘거나, 아직 결정이 안 났거나, "일단 만들어보고 정하자"는 상황이다. 이때 그냥 넘어가면 릴리즈 전날의 그 회의로 돌아간다. 대신 이렇게 한다.
"성능 기준에 대한 답을 아직 못 받아서, p95 2초를 가정으로 두고 테스트하겠습니다. 이 가정이 틀리면 알려주세요."
가정을 명시하고 기록에 남기는 것이다. 이러면 세 가지가 확보된다 — 테스트를 진행할 수 있고, 나중에 기준이 달라져도 "왜 이 기준으로 쟀는지"를 설명할 수 있고, 무엇보다 결정되지 않은 사항이 결정된 것처럼 조용히 묻히는 일을 막는다.
회의 자리에서 이 질문들을 실제로 꺼내는 법 — 우선순위를 매기고, 비난 없이 전달하는 기술은 이 모듈의 마지막 레슨에서 따로 다룬다.
지나치게 밀어붙일 때의 함정
테스트 가능성은 좋은 것이지만, 무조건 밀어붙이면 역효과가 난다. 세 가지를 조심한다.
- 숫자를 위한 숫자. 근거 없이 "3초"라고 적으면 그 숫자가 나중에 설계 제약이 된다. 근거가 없을 때는 차라리 "기준 미정 — 1차 측정 후 결정"이라고 적고 미정임을 드러내는 편이 낫다.
- 과잉 명세. 모든 문장에 여섯 축을 다 붙이면 아무도 안 읽는 문서가 된다. 위험이 큰 항목에 집중한다 — 성능, 보안, 결제, 데이터 정합성처럼 틀렸을 때 비싼 것들이다.
- 협상 여지 제거. 앞서 본 INVEST의 N과 충돌하는 지점이다. 판정 기준을 결과에 걸지 않고 구현 방법에 걸면, 더 나은 구현이 나와도 못 쓰게 된다.
실무에서 왜 필요한가
테스트 불가능한 요구사항은 "완료됐다"를 아무도 확신 있게 말할 수 없게 만든다. 실무에서 이런 요구사항은 릴리즈 직전에 "이게 충분히 빠른 거 맞나요?", "이 정도면 사용자 친화적인가요?" 같은 논쟁으로 되돌아온다. 이때는 이미 개발이 끝난 뒤라 기준을 다시 정하기엔 늦다. 개발이 시작되기 전에 요구사항을 테스트 가능한 형태로 다듬는 것이 이런 논쟁 자체를 없앤다. 이건 수용 기준(다음다음 레슨)을 쓰는 작업과 직접 이어진다.
조금 더 구체적으로, 테스트 가능성이 실무에서 만드는 차이는 네 가지다.
첫째, 테스트 케이스가 자동으로 나온다. "p95 2초 이내"라고 쓰인 요구사항에서는 테스트 케이스를 무엇으로 쓸지 고민할 필요가 없다 — 요구사항 문장이 거의 그대로 테스트 케이스가 된다. 반대로 "빠르게"라고 적힌 요구사항에서는 QA가 케이스를 만들기 전에 기준부터 만들어야 하고, 그 기준은 QA 혼자 정할 수 없다.
둘째, 자동화 가능 여부가 갈린다. 자동화 스크립트는 애매함을 처리하지 못한다.
assert(응답시간 < 2000)은 짤 수 있지만 assert(사용자_친화적)은 짤 수 없다.
테스트 가능성이 없는 요구사항은 구조적으로 자동화 대상이 되지 못한다 — 스테이지
4에서 자동화를 배울 때 이 제약을 다시 만나게 된다.
셋째, 결함 리포트의 성격이 달라진다. 기준이 있으면 "4초 걸립니다"가 아니라 "기준 2초 대비 4.1초, 기준 미달"이라고 쓸 수 있다. 앞은 의견이고 뒤는 사실이다. 사실로 쓰인 리포트는 반박당하지 않는다.
넷째, QA의 발언권이 달라진다. 기준 없는 논쟁에서 QA는 "느린 것 같다"고 말하는 한 명일 뿐이다. 기준이 있으면 QA는 합의된 기준에 대해 측정 결과를 보고하는 사람이 된다. 같은 내용이라도 후자가 훨씬 강하다.
신입 QA가 특히 조심할 것. 모호한 요구사항을 보고도 "다들 그러려니 하는 것 같으니 나만 모르는 건가" 싶어 넘기는 경우가 아주 많다. 대개는 그렇지 않다 — 다른 사람들도 각자 다르게 이해한 채 넘어가고 있을 뿐이다. 그 불일치는 사라지지 않고 릴리즈 직전에 한꺼번에 나타난다. "이 문장으로는 제가 통과 판정을 내릴 수 없습니다"라는 한마디는 신입이 할 수 있는 가장 값싸고 가장 효과가 큰 기여 중 하나다.
채용시장에서의 위치
요구사항 테스트 가능성은 QA 면접에서 실기 형태로 자주 나온다. 전형적인 질문은 이렇다.
- "'앱이 빠르게 동작해야 한다'는 요구사항을 받았습니다. 어떻게 하시겠어요?"
- "요구사항이 모호한데 담당 기획자가 바빠서 답이 없습니다. 그럼 어떻게 하시나요?"
- "테스트 가능한 요구사항과 그렇지 않은 요구사항의 예를 들어보세요."
첫 번째 질문에서 면접관이 보는 건 숫자를 제시하는지가 아니라 어떤 축이 빠졌는지를 짚어내는지다. "2초로 하겠습니다"보다 "측정 환경, 데이터 규모, 통계 기준을 먼저 합의해야 할 것 같습니다"가 훨씬 좋은 답이다. 두 번째 질문은 "가정을 명시하고 기록에 남긴 뒤 진행한다"는 답을 기대하는 질문이고, 이건 앞 절에서 그대로 다뤘다.
INVEST를 알고 있으면 "테스트 가능성은 사용자 스토리 품질 기준 INVEST의 T에 해당하고…"처럼 답의 근거를 프레임워크에 연결할 수 있다. 신입 지원자 사이에서 드물게 나오는 답이라 인상에 남는다.