테스트 케이스 작성법 2026 — 검수 확인서·통합 테스트와 기능 ID 연결 7단계

# 테스트 케이스 작성법 2026 — 검수 확인서·통합 테스트와 기능 ID 연결 7단계

테스트 케이스는 "검수의 기준"이다

외주 개발에서 가장 흔한 분쟁은 "이게 완성인가" 를 두고 벌어진다.

개발사는 "요청하신 기능 다 넣었습니다"라고 하고, 발주처는 "이게 되는 게 아닌데요"라고 한다. 둘 다 거짓말이 아니다. 완성의 정의가 문서로 없었을 뿐이다.

테스트 케이스가 그 정의다. 「이 조건에서 이렇게 하면 이런 결과가 나온다」를 미리 적어두면, 검수는 판단이 아니라 대조가 된다.

문서 전체 지도는 요구사항 정의서 작성법 — 외주 문서 7단계에 정리했다.

테스트 케이스와 테스트 시나리오는 다르다

이름이 비슷해 자주 섞여 쓰이는데, 보는 단위가 다르다.

둘 다 필요하다. 케이스만 있으면 개별 기능은 되는데 이어 붙이면 안 되는 상태를 못 잡고, 시나리오만 있으면 예외 처리가 통째로 빠진다.

⚠️ 시나리오는 발주처가 반드시 손대야 한다. 실제 업무 흐름을 아는 쪽이 발주처이기 때문이다. 개발사가 상상해서 만든 시나리오는 현장에서 안 쓰는 경로만 검증한다.

테스트 케이스 한 줄에 들어갈 6가지

케이스 ID를 기능 ID에서 파생시킨다

```

MEM-F-003 회원 검색 (기능 정의서)

├─ MEM-F-003-TC-01 이름으로 검색 → 일치 항목만

├─ MEM-F-003-TC-02 공백만 입력 → 전체 목록

├─ MEM-F-003-TC-03 없는 이름 검색 → "결과 없음" 안내

└─ MEM-F-003-TC-04 탈퇴 회원 검색 → 제외되어야 함

```

이렇게 붙여두면 검수 때 "어느 기능이 몇 % 검증됐나"가 바로 나온다. 기능 정의서에 ID를 부여하라는 이유가 여기서 회수된다.

기능 ID 부여 규칙은 기능 정의서 작성법에, 화면별 입력 규칙은 화면설계서 작성법에 정리했다.

예외 케이스가 절반이어야 한다

정상 흐름만 적은 테스트 케이스는 사실상 없는 것과 같다. 실무 사고는 전부 예외에서 난다.

기능마다 아래 다섯 축을 기계적으로 돌려보면 예외가 나온다.

⚠️ 권한 축을 빠뜨리면 보안 구멍이 남는다. 화면에서 버튼만 숨기고 서버에서 안 막은 경우가 흔한데, 테스트 케이스에 "조회 전용으로 삭제 요청 → 거부" 가 있어야 그게 잡힌다.

통합 테스트 — 어디까지가 범위인가

기능 하나하나는 되는데 이어 붙이면 깨지는 지점을 잡는 단계다. 범위를 미리 정하지 않으면 "그건 우리 범위가 아니다"로 흘러간다.

외부 연동은 반드시 실패 케이스를 넣는다. 결제가 성공하는 경우만 테스트하고 넘기면, 타임아웃이나 취소 응답에서 주문이 붕 뜬다.

검수 확인서 — 미완료를 적는 것이 핵심이다

검수 확인서는 "다 됐다"에 서명하는 문서가 아니라, 무엇이 됐고 무엇이 안 됐는지를 남기는 문서다.

반드시 들어갈 세 가지:

1. 케이스별 판정 결과 — Pass / Fail / 보류 개수
2. 미완료 항목과 처리 일정 — 누가 언제까지
3. 검수 이후 발견분의 처리 기준 — 하자보수인가 추가 개발인가

⚠️ "일단 검수해 주시고 나머지는 곧 해드릴게요"에 그냥 서명하면 그 나머지는 대체로 오지 않는다. 미완료 항목을 문서에 남기는 것이 유일한 안전장치다. 잔금 지급 조건과 연결해두면 더 확실하다.

하자보수와 추가 개발의 경계

이 경계가 검수 확인서에서 갈린다.

테스트 케이스가 곧 하자의 정의다. 케이스가 부실하면 경계가 흐려지고, 흐려지면 분쟁이 된다.

발주처가 직접 추가해야 할 케이스

개발사가 만든 케이스는 대체로 기능 명세를 따라간다. 실제 업무에서 벌어지는 상황은 발주처만 안다.

아래 유형을 직접 넣는다.

• 우리 현장에서 실제로 있었던 이상 데이터 — 이름이 한 글자, 연락처가 없는 거래처
• 바쁜 시간대의 사용 방식 — 여러 명이 동시에, 빠르게 연속 입력
• 잘못 눌렀을 때 — 저장 두 번 클릭, 뒤로 가기 후 다시 저장
• 기존 시스템과 병행하는 기간 — 엑셀과 새 시스템에 같은 건을 입력

이 네 가지가 오픈 직후 사고의 대부분을 차지한다.

흔한 실수 4가지

① 개발이 끝난 뒤에 케이스를 만든다

그러면 만들어진 것을 기준으로 케이스가 나온다. 케이스는 개발 전이나 병행해서 만들어야 검증 기능을 한다.

② 정상 흐름만 적는다

가장 흔하다. 예외가 절반이 안 되면 다시 본다.

③ 실사용자가 검수에 참여하지 않는다

결재자만 참여한 검수는 화면이 뜨는지만 확인하고 끝난다.

④ 미완료 항목을 구두로 합의한다

문서에 없으면 없는 일이 된다. 잔금과 연결해 둔다.

테스트 케이스 준비 7단계

```

[ ] 1. 기능 정의서에서 기능 ID 목록 확보

[ ] 2. 기능당 정상 케이스 1~2개 작성 (개발사)

[ ] 3. 다섯 축(값없음·경계·형식·중복·권한)으로 예외 확장

[ ] 4. 업무 흐름 단위 시나리오 작성 — 발주처가 실제 흐름 제공

[ ] 5. 외부 연동 실패 케이스 별도 추가

[ ] 6. 실사용자가 직접 실행 → Pass/Fail 기록

[ ] 7. 검수 확인서에 미완료 항목·일정 명시 후 서명

```

AI-Native 팀이 테스트를 다루는 방식

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 테스트에서 어려운 것은 케이스를 쓰는 일이 아니라 빠진 예외를 찾는 일이다.

• 예외 케이스 확장 — 화면설계서의 입력 규칙과 기능 정의서의 상태 전이에서 값없음·경계·중복·권한 조합을 뽑아 누락된 케이스를 채운다
• 권한 누수 검증 — 화면에서 숨긴 기능이 서버에서도 막히는지 역할별로 반복 확인한다
• 문서와 구현 대조 — 케이스가 기대하는 결과와 실제 응답이 갈라지는 지점을 찾아 문서만 남는 상태를 막는다

테스트 케이스의 가치는 개수가 아니라 오픈 후 "이건 검수 때 몰랐다"가 안 나오는가로 판가름난다. 반복 검증을 자동화해 사람이 업무 상황 발굴에 집중하게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

테스트 케이스는 누가 작성하나요?

개발사가 작성하고 발주처가 검토·보완한다. 다만 업무 흐름 시나리오와 실제 이상 데이터는 발주처가 직접 넣어야 쓸모가 있다.

몇 개나 있어야 충분한가요?

개수 기준은 없다. 기능마다 예외가 정상보다 많은가로 본다. 예외가 절반이 안 되면 부족한 것이다.

검수를 미루면 어떻게 되나요?

계약서에 "며칠 내 이의 없으면 검수 완료로 간주" 조항이 있는 경우가 많다. 미룰수록 불리하니 기간과 기준을 먼저 확인한다.

하자보수 기간에 뭐든 고쳐주나요?

아니다. 문서에 적힌 대로 동작하지 않는 것만 무상이다. 그래서 테스트 케이스가 곧 하자의 정의가 된다.

자동화 테스트를 요구해야 하나요?

장기 운영하거나 기능 추가가 계속될 계획이면 요구할 만하다. 한 번 만들고 끝나는 프로젝트라면 비용 대비 효과가 낮다.

정리

테스트 케이스는 검수를 판단에서 대조로 바꾸는 문서다.

실무에서 결과를 가르는 지점은 셋이다.

1. 예외가 정상보다 많은가 — 사고는 전부 예외에서 난다
2. 기능 ID와 연결됐는가 — 검수 진척과 하자 판정이 여기 걸린다
3. 미완료 항목을 문서에 남겼는가 — 구두 합의는 없는 일이 된다

이 셋만 챙겨도 "이게 완성인가"를 두고 다툴 일이 거의 없어진다.