QA가 리뷰하는 기획서 – 요구사항 분석 실전 가이드

기획서가 불친절할수록 QA는 야근합니다

---

1️⃣ 이 글은 왜 필요한가요?

“기획서에 다 써 있어요.”

 

이 말이 QA에게 공포의 문장이라는 사실, 알고 계셨나요?

요구사항이 불분명하면 QA는 알아서 테스트 케이스를 상상해야 합니다.
그 결과는? 테스트 누락, 기능 오해, 크로스 팀 충돌, 야근… 그리고 버그.

이 글에서는 QA가 실무에서 요구사항을 어떻게 리뷰하고 해석해야 하는지,
‘그 말 뜻이 이 말이냐’ 분석하는 법, 그리고 실전에서 벌어졌던 명세 문제 사례를 공유합니다.

---

2️⃣ QA는 요구사항을 해석하는 직업이다

요구사항은 단순히 “기획서에 적힌 내용”이 아닙니다.
사용자의 니즈를 기능으로 바꾼 선언문이죠.
QA는 이 선언문을 읽고 테스트 시나리오를 그려내야 하는 해석자입니다.

그런데 대부분의 기획서는 이렇습니다:

• "결제 기능 추가" (뭘 추가한 건데요?)
• "로그인 UX 개선" (어디가 어떻게 개선됐는지요?)
• "리스트 필터 정렬 기능 보완" (‘보완’이란 무슨 뜻인가요?)

기획서가 말이 되려면 QA가 반드시 다음 질문을 던져야 합니다:

항목 / 질문 예시

기능 정의	어떤 입력 → 어떤 결과?
조건	이 기능이 동작하는 조건은?
예외	어떤 상황에서 동작하지 않아야 하는가?
상태	초기 상태 / 완료 상태 정의는?
UI 요소	버튼/텍스트/알림은 어디까지 포함되는가?

---

3️⃣ 실무에서 있었던 명세 지옥 3선

1. “이벤트 기간에는 할인됩니다” – 날짜는 어디에?

할인 조건을 테스트하려는데
기획서에 “이벤트 기간 동안”이라고만 적혀있고,
시작일/종료일/시간 기준이 없음.

→ 결과: QA가 상상으로 ‘오늘부터 일주일?’ 테스트 작성
→ 실제 배포 후 월요일 오전 9시 버그 발생
→ 기획: “아, 그거 오전 10시부터였어요…”

---

2. “비회원은 접근할 수 없습니다” – 근데 접근하면 뭐가 나오는데?

기획서에

“비회원 접근 제한”

 

그래서 QA는 비회원 접근 시 로그인 화면 노출될 줄 알고 테스트.
→ 결과: “접근 금지 메시지가 떠야 맞습니다”
→ 이건 기획이 아니라 암기 과목

---

3. “유저는 설정을 바꿀 수 있습니다” – 근데 어디서?

설정은 어디에 있고,
기본값은 뭐고,
변경은 즉시 적용인가 저장 후 적용인가?

→ QA가 묻자 기획자는 “그건 UX 팀과 논의해보시고요…”
→ 2주 뒤 UX도 잘 모름
→ 테스트 설계 불가 상태 발생

---

4️⃣ 요구사항 리뷰 체크리스트

QA가 요구사항을 리뷰할 때는
다음 5가지만 체크해도 절반 이상의 품질 이슈를 예방할 수 있습니다.

항목 / 체크 내용

📌 기능 명세	입력/출력/처리 조건이 명확한가?
📌 경계 조건	최소/최대/빈 값 처리 정의되어 있는가?
📌 오류 처리	실패 시 동작(에러 메시지, fallback 등)이 명시되어 있는가?
📌 상태 흐름	초기/중간/완료 상태 정의 및 전이 조건 있는가?
📌 UI 요소	버튼/메시지/레이블 등 명확히 정의되었는가?

---

5️⃣ 애자일 QA의 요구사항 리뷰 방식

애자일 환경에서는 명세가 짧고,
Jira 티켓 하나에 모든 게 들어갑니다.
이때 QA는 다음 방식으로 요구사항을 입체적으로 해석합니다:

• AC(Acceptance Criteria)를 테스트 조건으로 바꾸어 읽기
• 기획자에게 직접 “이건 이런 케이스도 포함되나요?” 질문
• PO와 데일리 스크럼에서 예외 케이스 확인 요청
• 문서가 없으면 QA가 자체 명세화 문서를 만들어 공유

요구사항 리뷰는 일회성 확인이 아니라 팀의 기준을 맞추는 대화 과정입니다.

---

6️⃣ 기출문제 예시

Q. 다음 중 명확하지 않은 요구사항 표현으로 가장 적절한 것은?

A. “사용자는 회원가입 시 이메일을 입력해야 한다”
B. “버튼을 클릭하면 화면이 전환된다”
C. “결제 시 오류가 나면 에러 메시지를 출력한다”
D. “설정 메뉴를 통해 알림 기능을 조절할 수 있다”

 

✅ 정답: B
→ ‘어떤 화면으로 어떻게 전환되는지’가 명확하지 않음

---

✅ 마무리 요약

• 요구사항이 QA에게 명확하지 않다면, 그건 명세가 아닙니다.
• QA는 기획서를 해석하는 언어학자이자 위험 탐지기입니다.
• 요구사항 리뷰는 품질 확보의 가장 빠르고 강력한 전략입니다.
• 질문하는 QA가 야근하지 않습니다.
• 테스트는 명세가 명확할 때, 가장 아름답게 완성됩니다.

---

🔗 추천하는 글

• 정적 테스팅으로 명세 리뷰 전략을 확실히 잡고 싶다면
  → [Chapter 3 심화: 정적 테스팅과 결함 예방 – 리뷰로 품질을 만든다]
• QA 문서 자동화와 요구사항 추적 관리가 필요하다면
  → [테스트 문서 자동화 전략 – 실무에서 바로 쓰는 포맷 가이드]