요구사항 없이 테스터가 어떻게 일하는가: 검증된 전략
명시적인 요구사항은 작업이나 콘플루언스 페이지에 기록된 텍스트를 의미합니다. 암묵적인 요구사항은 비즈니스의 머릿속에만 존재하지만 팀에 문서화되지 않은 것입니다. 이러한 요구사항을 파악하려면 스토리지, 분석가, 개발자와 같은 이해관계자들과 적극적으로 소통해야 합니다. 목표는 모호한 논의에 빠지지 않고 누락된 세부 사항을 수집하는 것입니다.
규칙 1: 명확한 답변을 얻기 위해 닫힌 질문 사용하기
'게시물 생성 후 어디로 이동합니까?'와 같은 열린 질문은 긴 설명을 유도합니다. 대신 선택지를 제시하세요: '게시물은 사용자 피드, 커뮤니티 피드, 둘 다, 또는 둘 다 아닌가요?'
이 방식은 소통 속도를 높입니다. 답변은 즉각적인 예/아니오 또는 정해진 선택지 중 하나로 이루어집니다. 특정 시나리오(상태, 역할, 극단적 경우)에서 동작을 명확히 하기 위해 이 방법을 적용하세요.
규칙 2: 상태 전이 시각화하기
말로 설명하는 것보다 보여주는 것이 더 효과적입니다. 복잡한 워크플로우에 대해 상태 전이 표를 그려보세요. 예: 500달러 주문, 자동 게시, 20건의 불만. 어떤 일이 발생할까요? 게시물이 삭제되나요? 불만이 0건일 경우는 어떻게 되나요?
이 표는 일반적이고 드문 사건 모두를 포함합니다. 반복되는 질문을 한 번에 묶어 명확한 질문으로 만들 수 있어 모든 사람의 시간을 절약합니다.
예시: 소음이 많은 게스트(체크금액 200달러 미만)에 대한 표:
| 이벤트 | 조치 |
|--------|------|
| 체크금액 200달러 미만의 게스트로부터 소음 발생 | 알림 \| 무시 |
| 불만 건수 > 5 | 경고 \| 대피 |
규칙 3: CRUD 매트릭스로 완전한 커버리지 확보하기
백엔드 작업에서는 역할과 조건별로 CRUD 연산 매트릭스를 구성하세요. 개발자는 핵심 흐름(다른 사용자의 콘텐츠 삭제 차단, SQL 인젝션 보호 등)을 처리하지만, 예외 사례는 QA의 영역입니다.
이 매트릭스는 테스트뿐 아니라 코드 최적화에도 도움이 됩니다. 스프린트 시작 전 백엔드 팀과 공유하세요: '이 부분은 커버되었나요? 아니면 추가해야 할까요?'
예시: 게시물에 대한 CRUD 매트릭스:
| 역할 | 생성 | 조회 | 수정 | 삭제 | 조건 |
|------|------|------|------|------|------|
| 사용자 | 200 - 자신의 것<br>400 - 타인의 것 | 200 - 자신의 것<br>200 - 타인의 것 | 200 - 자신의 것<br>400 - 타인의 것 | 200 - 자신의 것<br>400 - 타인의 것 | 자신이 작성한 게시물만 |
| 모더레이터 | 403 | 200 | 200 | 200 | 불만이 존재할 경우 |
| 관리자 | 200 | 200 | 200 | 200 | 제한 없음 |
- 생성: 역할 기반 접근 권한 및 제한 확인
- 조회: 필터, 페이징, 캐싱 검사
- 수정/삭제: 원자성, 연쇄 효과 확인
2~3번의 반복 후 백엔드 팀은 작업 계획 단계에서 이러한 체크리스트를 요청하기 시작합니다.
핵심 요약
- 닫힌 질문은 정보 과잉을 줄이고 핵심 사항에 집중합니다.
- 상태 전이 표와 CRUD 매트릭스는 암묵적 요구사항의 80%를 시각적으로 드러냅니다.
- 개발자와 체크리스트를 공유하면 작업 → 테스트 사이클이 빨라집니다.
- 암묵적 요구사항은 자연스러운 현상이며, 이를 수집하는 것은 QA 엔지니어의 본분입니다.
- 요구사항 수정은 분석가에게 위임하세요. 그들은 기능의 전체 맥락을 책임집니다.
결론: 수정은 분석가에게 위임하세요
누락된 요구사항은 문제가 아닙니다. 오히려 일반적인 상황입니다. 이 세 가지 규칙은 혼란을 체계적인 구조로 바꿉니다. 마지막 조언: 요구사항을 직접 작성하지 마세요. 분석가에게 넘기세요. 그들은 기능 소유권을 관리하며 항상 맥락에 머물러 있습니다. 이렇게 하면 팀의 일관성과 효율성이 유지됩니다.
— Editorial Team
아직 댓글이 없습니다.