테스트 가능한(testable) 요구사항의 조건

개념

테스트 가능하다는 것의 의미

요구사항이 "테스트 가능하다"는 건 **"이 요구사항이 충족됐는지 아닌지를 명확하게 판단할 수 있는 기준이 있다"**는 뜻이다. 판단 기준이 사람마다 다르게 해석된다면, 그 요구사항은 테스트할 수 없다 — 통과인지 실패인지 합의가 안 되기 때문이다.

테스트 불가능한 요구사항의 특징

테스트 가능한 형태로 바꾸기

모호한 요구사항은 구체적인 숫자, 조건, 관찰 가능한 동작으로 바꾸면 테스트 가능해진다.

❌ "시스템은 사용자 친화적이어야 한다."

✅ "회원가입은 3단계 이하로 완료할 수 있어야 하고, 각 단계의 필수 입력 필드는 3개를 넘지 않아야 한다."

❌ "응답 속도가 충분히 빨라야 한다."

✅ "검색 결과는 요청 후 2초 이내에 화면에 표시되어야 한다 (95번째 백분위수 기준)."

❌ "적절한 에러 메시지를 보여준다."

✅ "입력값이 유효하지 않으면, 어떤 필드가 왜 잘못됐는지 필드 아래에 즉시 표시한다."

바뀐 문장들은 전부 **"통과/실패를 판단할 수 있는 관찰 가능한 기준"**을 담고 있다. 이게 테스트 가능성의 핵심이다.

테스트 가능성을 판단하는 질문

요구사항을 보고 아래 질문에 "예"라고 답할 수 있으면 테스트 가능하다고 볼 수 있다.

1. 이 요구사항이 충족됐는지, 서로 다른 두 사람이 같은 결론을 내릴 수 있는가?
2. 통과/실패를 가르는 구체적인 기준(숫자, 조건)이 있는가?
3. 이 요구사항을 확인할 방법(테스트 케이스, 측정 도구 등)을 상상할 수 있는가?

실무에서 왜 필요한가

테스트 불가능한 요구사항은 "완료됐다"를 아무도 확신 있게 말할 수 없게 만든다. 실무에서 이런 요구사항은 릴리즈 직전에 "이게 충분히 빠른 거 맞나요?", "이 정도면 사용자 친화적인가요?" 같은 논쟁으로 되돌아온다. 이때는 이미 개발이 끝난 뒤라 기준을 다시 정하기엔 늦다. 개발이 시작되기 전에 요구사항을 테스트 가능한 형태로 다듬는 것이 이런 논쟁 자체를 없앤다. 이건 수용 기준(다음 레슨)을 쓰는 작업과 직접 이어진다.

실습 과제

과제 1 — 테스트 가능성 판단하기 (10분)

다음 요구사항 각각이 테스트 가능한지 판단하고, 불가능하다면 왜 그런지 적는다.

1. "비밀번호는 안전해야 한다."
2. "비밀번호는 8자 이상이며 대문자·소문자·숫자·특수문자 중 3종류 이상을 포함해야 한다."
3. "관리자 페이지는 직관적으로 만든다."
4. "결제 완료 후 5초 이내에 확인 이메일이 발송된다."

과제 2 — 다시 쓰기 (15분)

다음 요구사항 두 개를 테스트 가능한 형태로 다시 써본다. 정답은 하나가 아니다 — 구체적인 숫자나 조건을 넣었는지가 중요하다.

1. "검색 기능은 빠르고 정확해야 한다."
2. "앱은 안정적으로 동작해야 한다."

자가 체크리스트

• "테스트 가능하다"의 정의를 "판단 기준의 명확성"으로 설명할 수 있다
• 모호한 형용사·측정 불가능한 표현이 왜 문제인지 예시로 설명할 수 있다
• 테스트 불가능한 요구사항을 구체적인 기준을 가진 형태로 다시 쓸 수 있다
• 테스트 가능성을 판단하는 세 가지 질문을 스스로 적용할 수 있다

흔한 실수

• "빠르다", "안전하다", "편리하다" 같은 형용사를 그대로 통과시킨다. 이런 단어가 나오면 반사적으로 "구체적으로 얼마나?"를 물어야 한다.
• 숫자만 넣으면 무조건 테스트 가능하다고 착각한다. "빨라야 한다"를 "빨라야 한다 (2초 이내)"로 바꿔도, 측정 조건(어떤 환경에서? 몇 번째 요청부터?)이 빠지면 여전히 다르게 해석될 수 있다.
• 테스트 불가능한 요구사항을 발견하고도 그냥 넘어간다. 발견한 순간이 가장 싸게 고칠 수 있는 시점이다(모듈 1). 질문으로 만들어 요구사항 작성자에게 되돌려줘야 한다.

참고 자료

• ISTQB Glossary — Testability — 테스트 가능성의 공식 정의
• Bill Wake, "INVEST in Good Stories" — 사용자 스토리 품질 기준(INVEST)의 원출처. "Testable"이 그중 한 축이다