테스트 케이스 프롬프트가 맡는 일은 요구사항 검토가 끝난 뒤 가장 시간을 잡아먹는 단계입니다. 기능은 모두가 이해했는데, 막상 케이스를 쓰기 시작하면 정상 흐름은 술술 써지지만 경곗값과 예외 상황이 몇 건씩 빠지고, 결국 인수 뒤 결함표에서 뒤늦게 채우게 됩니다. 아래 프롬프트는 케이스 분류, 표의 열, 기대 결과 작성 방식을 먼저 못 박아 둔 뒤 요구사항을 붙이게 되어 있어, 돌아오는 표는 그대로 실행할 수 있고 케이스 관리 도구에 넣을 수도 있습니다.
이 프롬프트가 맞는 상황
새 기능이 테스트에 넘어가기 전에 케이스를 보충할 때, 개편된 기능의 회귀 목록을 다시 만들 때, 기획자가 합격 기준을 직접 확인할 때 쓸 수 있습니다. 전제는 또렷하게 쓰인 요구사항 한 단락입니다. 프로토타입 설명, 요구사항 문서의 한 부분, 사용자 스토리 모두 됩니다. 구두로 들은 한 줄만 있다면 배경, 진입점, 규칙과 제한을 짧은 글로 먼저 정리해 붙여야 출력 품질이 크게 달라집니다.
그대로 복사해 쓰는 프롬프트
당신은 경력 8년의 소프트웨어 테스트 엔지니어입니다. 아래 요구사항을 바탕으로 그대로 실행할 수 있는 테스트 케이스를 설계해 주세요.
요구사항: {{요구사항}}
추가 정보: {{추가 정보. 관련된 화면이나 API, 계정 역할, 데이터 제한 등. 없으면 "없음"이라고 적기}}
출력 규칙:
1. 표로 출력하고, 열은 케이스 번호, 케이스 제목, 사전 조건, 수행 단계, 테스트 데이터, 기대 결과, 우선순위, 케이스 유형 순서로 한다.
2. 케이스 유형은 정상 흐름, 경곗값, 예외와 오류, 권한과 역할 네 가지를 반드시 포함하고, 유형마다 최소 3건씩 낸다.
3. 경곗값은 길이 상한, 금액 상한, 제출 횟수 상한처럼 구체적인 숫자로 적는다. "최댓값을 입력"처럼 쓰지 않는다.
4. 기대 결과는 확인할 수 있게 적는다. 화면 문구, 데이터 변화, 상태 변화를 명시하고, "정상 동작" 같은 빈말은 쓰지 않는다.
5. 표 뒤에는 "요구사항에 적혀 있지 않아 확인이 필요한 점"이라는 항목을 따로 두어 애매한 부분을 하나씩 나열한다. 빈곳을 메우려고 규칙을 지어내지 않는다.
표 먼저 출력하고 그다음 확인이 필요한 점을 낸다. 표 앞에 긴 설명은 붙이지 않는다.두 변수를 채우는 법
- {{요구사항}}: 업무 규칙, 필드 제한, 상태 변화를 포함해 요구사항 원문을 통째로 붙입니다. 구체적일수록 좋습니다. "쿠폰 기능을 만든다"라고만 쓰면 모델은 일반적인 쇼핑몰 규칙으로 추측할 수밖에 없고, 추측한 케이스는 실제 규칙과 어긋납니다.
- {{추가 정보}}: 테스트에서 실제로 쓸 수 있는 것을 적습니다. 어떤 역할의 계정이 있는지, 만들어 둔 테스트 데이터가 있는지, 기능이 앱인지 웹인지 같은 정보입니다. 역할 정보가 특히 중요한데, 권한 케이스는 전부 여기서 만들어지기 때문입니다.
채워 넣은 뒤의 모습
요구사항을 "사용자는 배송 주소를 수정할 수 있다. 주소 텍스트는 최대 100자, 시·도와 구는 필수, 저장하면 새 주소가 바로 반영된다"는 짧은 글로 바꾸면, 돌아온 표에는 이런 행이 들어갑니다.
| 번호 | 제목 | 테스트 데이터 | 기대 결과 | 유형 |
|---|---|---|---|---|
| TC-04 | 정확히 100자인 주소 저장 | 100자인 주소 | 저장에 성공하고 목록 화면에 주소 전체가 보인다 | 경곗값 |
| TC-05 | 101자인 주소 저장 | 101자인 주소 | 저장이 막히고 글자 수 초과 문구가 뜬다 | 경곗값 |
| TC-09 | 구를 고르지 않고 저장 | 시·도는 선택, 구는 비어 있음 | 구 입력란으로 이동하고 필수 항목 문구가 뜬다 | 예외 |
이렇게 구체적인 숫자가 붙은 행이 나오면 프롬프트가 제대로 먹힌 것입니다. 제목이 전부 "저장 기능 확인"투라면 출력 규칙 3번과 4번을 강조해 다시 돌리세요.
결과가 아쉬울 때 이어서 시키는 법
- 케이스가 얕을 때: "우선순위가 높은 케이스만 남기고, 각 케이스에 반대 확인을 붙여 주세요. 일부러 잘못 입력했을 때 시스템이 어떻게 막아야 하는지까지 적어 주세요."
- 중복 제출이 빠졌을 때: 추가 정보에 "같은 사용자가 저장을 연속으로 누를 수 있다"를 넣고 "반복 동작" 유형을 추가해 달라고 합니다.
- 자동화로 바꾸고 싶을 때: "우선순위가 높은 케이스를 Playwright 테스트 단계로 바꿔 주세요. 단계마다 로케이터와 단언을 붙여 주세요."
마지막으로 한 가지만 짚어 둡니다. AI가 만든 케이스는 초안과 누락 점검용으로는 좋지만, 결제, 권한, 데이터 삭제와 관련된 케이스는 배포 전에 테스터가 실제 환경에서 하나씩 직접 돌려봐야 합니다. 특히 "확인이 필요한 점"에 오른 애매한 부분은 검토 자리에서 아무도 끝까지 따지지 못했던 지점인 경우가 많습니다.
