모호함과 누락 찾아내기

개념

능동적 읽기(레슨 1)와 테스트 가능성 판단(레슨 2)을 실제로 적용하려면, 모호함과 누락을 유형별로 알아보는 눈이 필요하다.

모호함의 네 가지 유형

같은 문장을 팀원 세 명에게 보여주면 세 가지 다른 해석이 나올 수 있다 — 이게 모호함이 실무에서 문제가 되는 방식이다. 각자 다르게 이해한 채로 개발과 테스트가 따로 진행되면, 통합 단계(모듈 1에서 배운 "통합 테스트")에서야 불일치가 드러난다.

누락을 찾는 체크리스트

요구사항에 빠지기 쉬운 조건들은 어느 정도 정형화되어 있다. 아래 다섯 가지를 습관적으로 확인한다.

1. 예외·실패 경로: 정상 흐름만 적혀 있고, 실패하면 어떻게 되는지 없다
2. 권한·역할: "사용자"라고만 적혀 있고, 역할별 차이(비회원/일반회원/관리자)가 없다
3. 상태 전이: 어떤 상태에서 어떤 상태로 갈 수 있는지, 갈 수 없는 조합은 무엇인지 없다
4. 동시성: 같은 자원을 여러 사용자가 동시에 건드리면 어떻게 되는지 없다 (예: 마지막 재고 하나를 두 사람이 동시에 주문)
5. 비기능 조건: 성능·보안·접근성처럼 "얼마나 잘"에 대한 기준이 아예 없다

찾는 방법: "만약 ~라면?" 질문

빈 곳을 찾는 가장 실용적인 방법은 요구사항을 읽으며 계속 "만약 ~라면?"을 붙여보는 것이다.

요구사항: "사용자는 장바구니에 상품을 담을 수 있다."

• 만약 품절 상품이면?
• 만약 이미 장바구니에 있는 상품을 또 담으면?
• 만약 로그인하지 않은 상태라면?
• 만약 같은 상품을 두 창(탭)에서 동시에 담으면?

이 질문들이 곧 놓친 요구사항 후보다. 전부 다 실제로 명세에 넣어야 하는 건 아니지만, 최소한 "이건 어떻게 할지 정했나요?"라고 물어볼 재료가 된다.

실무에서 왜 필요한가

모호함과 누락은 팀원마다 "각자 다르게 이해한 채로" 작업을 진행하게 만드는 게 진짜 위험이다. 기획자는 A로 이해하고, 개발자는 B로 구현하고, QA는 C를 기준으로 테스트 케이스를 짜면, 통합 단계에서야 셋 다 다른 걸 만들었다는 게 드러난다. 이 시점이면 이미 코드도, 테스트 케이스도, 어쩌면 디자인까지 다시 손봐야 한다. 요구사항 리뷰 단계(다음다음 레슨)에서 이런 지점을 미리 짚어내는 게 QA가 상류에서 만드는 가장 큰 가치 중 하나다.

실습 과제

과제 1 — 모호함 유형 분류하기 (10분)

다음 문장에서 모호한 부분을 찾아 위 네 가지 유형(어휘적/범위/암묵적 가정/문장구조) 중 무엇에 해당하는지 적는다.

"최근 주문 내역에서 관리자는 취소된 주문을 확인할 수 있다."

과제 2 — "만약 ~라면?" 적용하기 (12분)

다음 요구사항에 "만약 ~라면?" 질문을 최소 4개 만든다.

"사용자는 게시글에 좋아요를 누를 수 있다."

자가 체크리스트

• 모호함의 네 가지 유형(어휘적, 범위, 암묵적 가정, 문장 구조)을 구분할 수 있다
• 요구사항에서 흔히 빠지는 다섯 가지 조건(예외, 권한, 상태 전이, 동시성, 비기능)을 나열할 수 있다
• "만약 ~라면?" 질문법으로 빠진 요구사항 후보를 스스로 만들 수 있다
• 모호함이 왜 통합 단계에서야 드러나는 문제로 이어지는지 설명할 수 있다

흔한 실수

• 모호함을 발견하고 스스로 판단해서 넘어간다. "아마 이런 뜻이겠지"로 혼자 해석하고 테스트 케이스를 짜면, 실제 의도와 다를 위험이 그대로 남는다. 질문으로 만들어 확인받아야 한다.
• "만약 ~라면?" 질문을 무한정 만들어 우선순위 없이 나열한다. 모든 질문이 같은 무게는 아니다. 리스크가 큰 것부터 추리는 판단(모듈 4에서 다룸)이 필요하다.
• 동시성 문제를 간과한다. "동시에 여러 명이 접근하면?"은 신입이 가장 놓치기 쉬운 누락 유형이다 — 혼자 테스트할 때는 절대 재현되지 않기 때문이다.

참고 자료

• ISTQB Foundation Level Syllabus — Requirements Reviews — 요구사항 리뷰에서 모호함·누락을 찾는 접근법
• Michael Hunter, "The Low, Low Cost of Quality" — 요구사항 단계 결함의 비용에 대한 실무 관점 아티클