04강: [QA] 요구사항 명세서 기반 완벽한 테스트 케이스(TC) 자동 생성출처

SECTION 1. IT 실무 최적화: 왜 클로드인가? (입문)
 
• 01강: 챗GPT 대신 클로드를 선택해야 하는 이유 (아티팩트 & 20만 컨텍스트)
• 02강: IT 현업을 위한 초기 세팅: 프로젝트(Projects) 기능을 통한 도메인 지식 주입
• 03강: 프롬프트 엔지니어링 기초: IT 논리 구조를 반영한 지시 기법

SECTION 2. QA & 테스터를 위한 AI 전략 (심화)
 
• 04강: [QA] 요구사항 명세서 기반 완벽한 테스트 케이스(TC) 자동 생성
• 05강: [QA] 복잡한 데이터 흐름 분석 및 경계값 테스트 시나리오 도출
• 06강: [QA] 셀레늄/플레이라이트(Playwright) 자동화 스크립트 작성 및 오류 수정

SECTION 3. 개발 & 시스템 설계를 위한 AI 활용 (심화)
 
• 07강: [Dev] 레거시 코드 리팩토링 및 신규 라이브러리 마이그레이션 가이드
• 08강: [Dev] 에러 로그 분석을 통한 근본 원인(Root Cause) 파악 및 디버깅
• 09강: [Design] 머메이드(Mermaid)를 활용한 시퀀스 다이어그램 및 DB 설계도 그리기

SECTION 4. MCP와 자동화 에이전트로 가는 길 (실전)
 
• 10강: MCP(Model Context Protocol) 개념과 IT 도구(Notion/GitHub/Jira) 연동
• 11강: Sequential Thinking(심층 사고) 모드로 복잡한 비즈니스 로직 검증하기
• 12강: 클로드 코드(Claude Code) 입문: 터미널에서 제어하는 AI 주도 개발(ADC)

 

---

 

 

QA의 일은 끝없는 '만약'의 목록을 만드는 일입니다. 그 목록을 손으로 적느라 야근하던 작업을, 명세서 기반으로 어떻게 넘기는지를 짚었습니다.

 

앞선 세 강에서 우리는 클로드에게 넓은 작업대를 깔아 주고, 도메인 지식을 심어 두고, 말 거는 법까지 익혔습니다.

 

이제 그 도구를 실제 업무 한복판으로 가져옵니다. 첫 무대는 QA, 그중에서도 테스트 케이스 만들기입니다.

 

테스트 케이스란, 출시 전에 모든 경우를 두드려 보는 점검표다

새로 나온 음료 자판기를 점검한다고 생각해 보세요.

 

"동전을 넣고 버튼을 누르면 음료가 나온다"만 확인했다면, 점검은 절반밖에 안 한 겁니다.

 

가짜 동전을 넣으면 어떻게 될까.

 

음료가 품절이면.

 

거스름돈이 없으면.

 

버튼 두 개를 동시에 누르면.

 

음료가 나오는 도중에 전원이 꺼지면.

 

이 모든 '만약'을 하나하나 적어 둔 목록이 바로 테스트 케이스입니다.

 

그리고 그 자판기가 어떻게 동작해야 하는지를 적어 둔 약속 문서가 요구사항 명세서고요.

 

QA는 명세서를 보고, 일어날 수 있는 모든 경우를 떠올려 점검표로 옮기는 사람입니다.

 

문제는 이 일이 사람에게 가혹하다는 데 있습니다.

 

정상적으로 잘 돌아가는 경우는 누구나 떠올립니다.

 

정작 사고는 늘 '잘 안 떠오르는 예외'에서 터집니다.

 

게다가 명세서 수십 페이지를 읽으며 경우의 수를 손으로 적다 보면, 집중력이 흐려지는 후반부에서 꼭 무언가가 빠집니다.

 

사람의 한계지 게으름이 아닙니다.

 

명세서를 던지기 전에, 클로드에게 '빈틈'부터 찾게 하라

여기서 많은 사람이 첫 단추를 잘못 끼웁니다.

 

명세서를 붙여넣고 다짜고짜 "테스트 케이스 만들어줘"라고 하는 것입니다.

 

그러면 명세서가 어설픈 만큼 테스트도 어설퍼집니다.

 

레시피에 '소금 약간'이라고만 적혀 있으면, 사람마다 전혀 다른 요리가 나오는 것과 같습니다.

 

잘 받아내는 사람은 순서를 한 단계 비틀어 둡니다.

 

먼저, 명세서의 빈틈부터 짚게 한다

테스트 케이스를 달라고 하기 전에, 명세서에서 모호하거나 빠진 조건부터 찾아 달라고 합니다.

 

긴 맥락을 통째로 받아들이는 클로드는 이 일을 잘합니다.

 

명세서를 끝까지 읽고, 앞쪽의 정의와 뒤쪽의 예외가 부딪히는 곳, 정의되지 않은 상태, 빠진 흐름을 짚어 줍니다.

 

너는 꼼꼼한 QA 엔지니어야.
아래 요구사항 명세서를 읽고, 테스트 케이스를 만들기 전에
모호하거나 빠진 조건부터 먼저 짚어 줘.

<명세서>
여기에 명세서 전문을 붙여넣는다
</명세서>

 

이 한 번의 질문이 점검표의 품질을 통째로 끌어올립니다.

 

빈틈을 메운 명세서 위에서 출발해야, 빈틈 없는 테스트가 나오기 때문입니다.

 

 

그다음, 역할과 형식을 정해 표 한 장으로 받아낸다

빈틈을 어떻게 메울지 정했다면, 이제 본격적으로 케이스를 받아냅니다.

 

중요한 건 경우의 수를 갈래로 나눠 달라고 콕 짚는 것입니다.

 

정상 흐름, 예외 상황, 경계에 걸친 값, 그리고 아예 잘못된 입력. 이 네 갈래로 나누라고 하면 클로드가 빠뜨림 없이 훑습니다.

 

표의 모양도 미리 못 박아 둡니다.

 

그래야 그대로 복사해 쓸 수 있습니다.

좋아, 짚어 준 빈틈은 이렇게 정한다고 치고
이제 정상·예외·경계값·잘못된 입력 네 갈래로 나눠
테스트 케이스를 표로 만들어 줘.
열은 ID, 전제조건, 테스트 단계, 입력값, 기대 결과, 우선순위로.

 

그러면 사람이라면 후반부에 흘려보냈을 케이스까지 또렷하게 떨어집니다.

 

예를 들어 로그인 기능이라면, 이런 줄이 표에 들어옵니다.

 

TC-LOGIN-007 / 전제: 가입된 계정 / 단계: 비밀번호를 5번 연속 틀리게 입력 / 기대 결과: 계정 잠금과 안내 메시지 노출 / 우선순위: 높음

 

'5번 틀리면 잠긴다' 같은 케이스는 사람이 자주 빠뜨리는 대목입니다.

 

명세서에 한 줄 적혀 있어도, 손으로 옮길 때 놓치기 쉽거든요.

 

 

아티팩트 위에서, 빠진 시나리오만 골라 채운다

1강에서 본 아티팩트가 여기서 빛을 발합니다.

 

테스트 케이스 표가 대화 옆 패널에 편집 가능한 형태로 떠오릅니다.

 

표를 훑어보다 "비밀번호 입력 도중 네트워크가 끊기는 경우가 빠졌다" 싶으면, 한마디만 더하면 됩니다.

 

그 줄만 새로 추가되고, 나머지는 그대로 유지됩니다.

 

완성된 표는 그대로 복사해 테스트 관리 도구에 옮기면 됩니다.

 

처음부터 손으로 적던 시절과는 출발선이 다릅니다.

 

 

이제 QA는 케이스를 받아 적는 사람이 아니라, 빈틈을 판단하는 사람이 된다

 

한 가지는 분명히 해두겠습니다.

 

클로드가 뽑은 표를 그대로 믿고 끝내라는 이야기가 아닙니다.

 

오히려 반대입니다.

 

단순 나열이라는 고된 작업을 덜어낸 만큼, QA의 눈은 더 중요한 곳을 향합니다.

 

이 케이스가 우리 서비스에 정말 위험한 순서로 정렬됐는지, 도메인 특유의 함정이 빠지진 않았는지, 우선순위가 현실과 맞는지를 판단하는 일입니다.

 

받아 적는 손에서 벗어나, 무엇이 빠졌는지를 가려내는 눈으로 무게 중심이 옮겨 가는 셈입니다.

 

다음 5강 예고

 

이번 글에서 네 갈래 중 하나로 슬쩍 등장했던 '경계값', 사실 여기에 사고가 가장 많이 숨어 있습니다.

 

다음 5강 「복잡한 데이터 흐름 분석 및 경계값 테스트 시나리오 도출」에서는, "8자 이상 20자 이하" 같은 조건의 진짜 위험 지점을 어떻게 캐내는지, 그리고 여러 단계를 거치는 복잡한 데이터 흐름에서 클로드가 어디를 의심해야 하는지 짚는 법을 다룹니다.

 

※ 본 강좌는 매일 1강씩 무료로 연재됩니다. 요금제별 기능과 한도는 모델·플랜에 따라 달라질 수 있으니, 실제 적용 시 최신 안내를 확인하시기 바랍니다.