개념
AI는 테스트 케이스를 "그럴듯하게" 만든다
모듈 3에서 배운 동등분할·경계값분석 같은 기법으로 사람이 직접 테스트 케이스를 설계하는 데는 시간이 걸린다. AI에게 요구사항을 주고 테스트 케이스를 만들어달라고 하면, 놀랍도록 빠르게 그럴듯한 목록이 나온다. 문제는 "그럴듯하다"와 "정확하다"는 다르다는 것이다 — 이건 이 모듈 전체, 그리고 모듈 18c에서 계속 다룰 핵심 경계선이다.
좋은 프롬프트가 좋은 결과를 만든다
모호한 프롬프트는 모호한 결과를 낳는다.
나쁜 프롬프트: "로그인 기능 테스트 케이스 만들어줘"
좋은 프롬프트:
"다음 로그인 기능에 대한 테스트 케이스를 모듈 3에서 배운
동등분할·경계값분석 기법으로 만들어줘.
기능 명세:
- 이메일은 5~50자, 비밀번호는 8~20자
- 비밀번호는 5회 연속 실패 시 10분간 잠금
- 이메일 형식이 아니면 즉시 오류 표시
각 케이스에 사전조건, 절차, 기대 결과를 포함해줘."좋은 프롬프트는 명확한 명세, 원하는 기법, 원하는 출력 형식을 구체적으로 지정한다. 모듈 2(레슨 1)에서 배운 "요구사항을 능동적으로 읽는" 능력이, 여기서는 "AI에게 명확한 요구사항을 전달하는" 능력으로 이어진다.
AI가 놓치기 쉬운 것들
AI가 생성한 테스트 케이스를 검토하다 보면 반복되는 빈틈이 보인다.
- 경계값을 정확히 짚지 못하고 대략적인 값만 쓴다(예: "긴 문자열
입력" — 정확히 51자인지는 안 밝힘)
- 명세에 없는 내용을 그럴듯하게 지어낸다(환각, Hallucination)
- 모듈 3(레슨 8~9)에서 배운 악성 입력이나 동시성 문제 같은,
"누가 시키지 않으면 잘 안 떠오르는" 케이스를 빠뜨린다
- 같은 조건을 표현만 바꿔 중복으로 여러 번 생성한다생성된 결과를 검증하는 절차
1. 명세와 대조한다 — 실제 요구사항에 있는 조건만 반영됐는가?
2. 경계값을 확인한다 — 애매한 표현("긴 값") 대신 정확한 값이 있는가?
3. 빠진 케이스를 찾는다 — 모듈 3의 설계 기법 체크리스트로 스스로 비교해본다
4. 중복을 제거한다이 절차는 모듈 18c(AI 교차검증)에서 훨씬 깊게 다룰 내용의 첫걸음이다 — AI가 만든 것을 사람이 검증하는 습관은 이 모듈 하나로 끝나는 게 아니라 스테이지 6 전체를 관통하는 태도다.
BYOK 원칙 — 이 강의의 AI 활용은 항상 이 전제 위에 있다
이 강의(그리고 여러분이 QA로 일할 실무 환경)에서 AI 도구를 쓸 때, 회사나 서비스의 API 키를 몰래 활용하는 게 아니라 각자 자신의 API 키로 AI를 호출하는 것이 원칙이어야 한다. 이건 비용·보안 책임 소재를 명확히 하는 문제이자, "AI가 알아서 다 해준다"가 아니라 "내가 도구로써 AI를 쓴다"는 태도를 유지하는 것과도 맞닿아 있다.
실무에서 왜 필요한가
"AI로 테스트 케이스 30개를 5분 만에 만들었어요"라는 성과는, 그 30개를 사람이 검증하지 않으면 오히려 위험하다 — 틀린 테스트 케이스가 실제 결함을 놓치게 만들 수 있다. 좋은 프롬프트를 설계하고 결과를 체계적으로 검증하는 QA는, AI를 "속도를 내는 도구"로 안전하게 쓸 수 있다.