요구사항과 테스트의 연결

학습 목표

이 모듈 한 줄 요약 — "만들기 전에 묻는 법". 모듈 1이 "테스트가 무엇인가" 였다면 여기서는 무엇을 만들기로 했는지 적어 둔 글(요구사항)을 다룬다. 그 글은 거의 언제나 불완전하고, 빠진 자리에서 결함이 난다. 코드가 한 줄도 없을 때 질문 하나를 던지는 것이 다 만든 뒤 결함 열 개를 찾는 것보다 싸다 — 모듈 1에서 본 그 이야기를 실제로 하는 방법이 이 모듈이다.

이 모듈을 마치면 요구사항 문서(또는 문서화되지 않은 요구사항)를 수동적으로 받아들이지 않고 능동적으로 읽어, 테스트 가능한 형태인지 판단하고, 모호함과 누락을 스스로 찾아 질문으로 만들 수 있다. 요구사항이 바뀌었을 때 어디까지 영향이 퍼지는지 추적하는 법과, 요구사항 리뷰 회의에서 실제로 쓸모 있는 질문을 던지는 법도 함께 다룬다.

완료 후 할 수 있는 것

• 요구사항 문서를 읽으며 "누가·무엇을·언제·예외는"을 스스로 채워 넣을 수 있다
• 어떤 요구사항이 "테스트 가능한지"를 판단하는 기준을 적용할 수 있다
• 모호한 표현과 빠진 조건을 요구사항에서 찾아낼 수 있다
• 수용 기준(Acceptance Criteria)이 요구사항과 어떻게 다르고 어떻게 이어지는지 설명할 수 있다
• 요구사항이 변경됐을 때 영향 범위를 추적성(Traceability) 관점에서 분석할 수 있다
• 요구사항 리뷰 회의에서 개발 착수 전에 리스크를 줄이는 질문을 만들 수 있다

채용시장에서의 위치

"요구사항 분석 경험"은 주니어와 시니어 QA를 가르는 기준 중 하나로 자주 언급된다. 주니어는 이미 확정된 요구사항으로 테스트 케이스를 만드는 데 집중하지만, 시니어는 요구사항이 만들어지는 단계부터 참여해 모호함을 미리 걸러낸다. 이 모듈의 능력은 비즈니스 분석가(BA)나 프로덕트 매니저와 협업이 잦은 조직일수록 더 직접적으로 평가받는다 — 면접에서 "요구사항이 불명확할 때 어떻게 하시나요?"라는 질문으로 자주 등장한다.