개념
수동적 읽기 vs 능동적 읽기
수동적 읽기는 문장을 있는 그대로 받아들인다. "사용자가 프로필 사진을 업로드할 수 있다"를 읽고 "업로드 기능을 만들면 되는구나"로 끝낸다.
능동적 읽기는 문장을 읽으면서 계속 질문을 던진다. 같은 문장을 능동적으로 읽으면 이런 질문들이 나온다.
- 파일 형식은 무엇을 허용하는가? (JPG만? PNG도? GIF는?)
- 파일 크기 제한이 있는가?
- 업로드 중 실패하면 어떻게 되는가?
- 이미 사진이 있는 상태에서 다시 업로드하면 기존 사진은 어떻게 되는가?
- 업로드 권한은 누구에게 있는가? (본인만? 관리자도 가능한가?)
이 질문들은 요구사항 문서 어디에도 안 적혀 있을 수 있다. 적혀 있지 않다는 것이 "신경 안 써도 된다"는 뜻이 아니다 — 개발자가 임의로 결정하게 되거나, 아무도 결정하지 않은 채 구현이 끝나버릴 수 있다는 뜻이다.
다섯 가지 질문 틀
모든 요구사항 문장에 아래 다섯 질문을 습관적으로 던지면 빠진 부분이 잘 보인다.
| 질문 | 무엇을 찾는가 |
|---|---|
| 누가 하는가? | 권한, 역할별 차이 |
| 무엇을 하는가? | 정확한 동작, 입력과 출력 |
| 언제 하는가? | 조건, 트리거, 타이밍 |
| 어떻게 하는가? | 구체적인 흐름, UI/API 형태 |
| 예외는 무엇인가? | 실패 시나리오, 경계 상황 |
요구사항은 문서 한 종류가 아니다
실무에서 요구사항은 깔끔한 명세서 한 장으로 오지 않는다. PRD(제품 요구사항 문서), 사용자 스토리("~로서, ~하고 싶다, 그래야 ~할 수 있다"), 디자인 목업(Figma), 슬랙 스레드에서 나온 구두 합의, 심지어 회의 중 지나가듯 나온 말까지 전부 요구사항의 일부가 될 수 있다. 능동적 읽기는 문서화된 요구사항뿐 아니라 이 모든 흩어진 정보를 하나로 모으는 습관이기도 하다.
실무에서 왜 필요한가
PM이나 기획자는 대부분 "정상적으로 잘 되는 경우(해피 패스)"를 기준으로 요구사항을 쓴다. 실패 상황, 권한 예외, 경계 조건은 의도적으로 빠뜨리는 게 아니라 쓰는 사람이 미처 생각하지 못해서 빠진다. 이걸 개발이 시작되기 전에 능동적으로 읽어 질문으로 만들어내는 것이 QA가 상류에서 할 수 있는 가장 저비용 고효율 활동이다 — 모듈 1에서 배운 "일찍 찾을수록 싸다"가 바로 여기서 실현된다.
실습 과제
과제 1 — 다섯 질문 적용하기 (10분)
다음 요구사항 문장에 다섯 가지 질문(누가/무엇을/언제/어떻게/예외는)을 각각 적용해 최소 5개의 질문을 만들어본다.
"사용자는 게시글에 댓글을 작성할 수 있다."
과제 2 — 흩어진 요구사항 모으기 (10분)
최근에 참여했던(또는 최근에 써본) 서비스의 기능 하나를 골라, 그 기능의 요구사항이 어디에 흩어져 있었을지 상상해본다. (예: 기획 문서, 디자인 목업, 개발자와의 대화) 각각에서 어떤 정보가 나왔을지 한 줄씩 추측해 적는다.
자가 체크리스트
- 수동적 읽기와 능동적 읽기의 차이를 예시로 설명할 수 있다
- 다섯 가지 질문 틀(누가/무엇을/언제/어떻게/예외는)을 요구사항 문장에 적용할 수 있다
- 요구사항이 문서 한 종류로만 오지 않는다는 것을 안다
- "적혀 있지 않다"가 "신경 안 써도 된다"는 뜻이 아닌 이유를 설명할 수 있다
흔한 실수
- 요구사항을 한 번 훑어보고 바로 테스트 케이스 작성으로 넘어간다. 질문을 만드는 단계를 생략하면, 나중에야 빠진 조건을 발견해 재작업이 생긴다.
- 질문을 마음속으로만 하고 기록하지 않는다. 능동적 읽기의 결과물은 질문 목록이어야 한다 — 이게 다음 레슨(요구사항 리뷰 회의)에서 쓸 재료가 된다.
- 모든 질문을 한 번에 PM에게 쏟아낸다. 질문이 너무 많으면 무엇이 정말 중요한지 묻힌다. 리스크가 큰 질문부터 추리는 법은 모듈 4(리스크 기반 테스트)와 연결된다.
참고 자료
- ISTQB Foundation Level Syllabus — Requirements Analysis — 요구사항 분석에서 테스터의 역할
- Gojko Adzic, Specification by Example — 요구사항을 구체적 예시로 바꿔 모호함을 줄이는 접근법의 대표 저작