테스트 케이스 작성법 2026 — 단위·통합·인수(UAT) 구분과 결함 리포트·검수 확인서 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 부여 규칙은 기능 정의서 작성법에, 화면별 입력 규칙은 화면설계서 작성법에 정리했다.

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

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

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

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

단위·통합·인수(UAT) — 누가 어디까지 하나

테스트를 「한 번 다 돌려보는 일」로 생각하면 검수가 어긋난다. 실무에서는 세 단계이고 단계마다 하는 사람과 잡는 문제가 다르다.

UAT(User Acceptance Testing, 사용자 인수 테스트)는 발주처가 주체인 유일한 단계다. 개발사가 대신 해 줄 수 없다 — 업무가 실제로 되는지 판단할 수 있는 사람이 발주처뿐이기 때문이다.

세 단계를 구분해 두는 실질적인 이유가 있다.

• 일정이 겹치지 않는다. UAT 를 개발 마지막 주에 며칠로 잡으면 발견된 결함을 고칠 시간이 없다. UAT 기간과 그 뒤의 수정 기간을 따로 잡는다.
• 결함의 책임이 갈린다. 단위·통합에서 잡혀야 할 것이 UAT 에서 나오면 개발사의 품질 문제이고, UAT 에서만 나올 수 있는 것(업무 맥락)은 정상이다.
• 인수테스트 결과가 검수의 근거가 된다. 계약서에 「UAT 통과」를 완료 조건으로 적어 두면 「기능은 다 넣었다」로 끝나지 않는다.

⚠️ UAT 참여자를 결재자가 아니라 실사용자로 지정한다. 결재자만 참여한 UAT 는 화면이 뜨는지만 확인하고 끝난다. 계약서나 착수 회의록에 부서·인원수·투입 일수를 적어 두는 편이 안전하다 — 막상 그 주가 되면 「현업이 바빠서」로 밀린다.

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

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

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

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

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

반드시 들어갈 세 가지:

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

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

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

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

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

결함을 발견하면 어떻게 적나

UAT 에서 결함을 찾는 것보다 고쳐지게 적는 것이 어렵다. 「안 돼요」라고 적힌 결함은 대개 「재현 안 됨」으로 돌아온다.

결함 하나에 이 다섯 개가 있으면 개발사가 바로 재현한다.

연결 케이스 ID 가 있으면 하자보수 여부가 그 자리에서 결정된다. 케이스에 있던 것이면 무상이고, 없던 것이면 변경 요청이다. 이게 없으면 매번 협의가 된다.

심각도도 같이 적는다. 등급이 없으면 전부 급한 일이 되고, 전부 급하면 우선순위가 사라진다.

⚠️ 「치명」을 남발하면 등급이 무의미해진다. 기준은 하나다 — 그 상태로 오픈했을 때 업무를 못 하거나 데이터를 되돌릴 수 없으면 치명이고, 나머지는 아니다.

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

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

아래 유형을 직접 넣는다.

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

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

모으는 방법은 회의가 아니라 기억이다. 「지난 1년에 시스템 때문에 곤란했던 일」을 담당자별로 세 개씩만 적게 하면 대개 여기서 다 나온다. 문서로 정리할 필요도 없고 메신저에 적힌 문장 그대로 개발사에 넘기면 된다 — 케이스로 옮기는 것은 개발사의 일이고, 상황을 아는 것은 발주처의 일이다.

흔한 실수 4가지

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

② 정상 흐름만 적는다 가장 흔하다. 예외가 절반이 안 되면 다시 본다.

③ 실사용자가 검수에 참여하지 않는다 결재자만 참여한 검수는 화면이 뜨는지만 확인하고 끝난다.

④ 미완료 항목을 구두로 합의한다 문서에 없으면 없는 일이 된다. 잔금과 연결해 둔다.

⑤ UAT 를 납기 마지막 주에 붙인다 결함을 찾아도 고칠 시간이 없다. 찾은 것이 전부 「오픈 후 처리」로 넘어가면 UAT 를 한 의미가 없다. UAT 기간 + 수정 기간 + 재확인까지 일정에 넣는다.

테스트 케이스 준비 7단계

[ ] 1. 기능 정의서에서 기능 ID 목록 확보
[ ] 2. 기능당 정상 케이스 1~2개 작성 (개발사)
[ ] 3. 다섯 축(값없음·경계·형식·중복·권한)으로 예외 확장
[ ] 4. 업무 흐름 단위 시나리오 작성 — 발주처가 실제 흐름 제공
[ ] 5. 외부 연동 실패 케이스 별도 추가
[ ] 6. 실사용자가 직접 실행 → Pass/Fail 기록
[ ] 7. 검수 확인서에 미완료 항목·일정 명시 후 서명

막히는 지점은 4번과 6번이다.

4번(업무 흐름 제공) 을 개발사에 맡기면 현장에서 안 쓰는 경로만 검증된다. 발주처가 내야 할 것은 문서가 아니라 말이어도 된다 — 「아침에 어제 주문을 일괄로 확정하고, 그중 결제 실패한 건을 따로 뽑아 전화한다」 한 문단이면 개발사가 시나리오로 옮긴다.

6번(실사용자 실행) 이 일정에서 가장 먼저 희생된다. 개발이 밀리면 UAT 기간이 줄고, 줄어든 UAT 는 화면 확인으로 끝난다. 착수 시점에 UAT 를 캘린더에 박아 두고 그 뒤에 수정 기간을 붙인다. UAT 를 납기 마지막 주에 붙이면 결함을 찾아도 고칠 시간이 없어서 「오픈 후 처리」로 넘어간다.

3번(예외 확장)은 기계적으로 돌리면 되므로 어렵지 않지만, 다 돌렸는지 확인할 방법을 만들어 둔다 — 기능 ID 별로 다섯 축이 몇 개씩 있는지 세는 표 하나면 충분하다.

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

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

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

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

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

자주 묻는 질문

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

UAT 는 며칠이면 되나요? 기능 규모에 따르지만 실사용자가 실제 업무를 한 바퀴 돌릴 수 있는 기간이 하한이다. 월 마감이 있는 업무라면 마감을 한 번 넘겨봐야 하므로 최소 2주를 잡는다. 화면만 확인하는 UAT 는 2일이면 끝나지만 그건 UAT 가 아니다.

단위 테스트 결과도 받아야 하나요? 받아도 발주처가 판단할 수 없는 문서다. 대신 통합 테스트 결과와 UAT 결과를 산출물로 명시하면 충분하다. 단위 테스트는 개발사 내부 품질 관리 영역이다.

몇 개나 있어야 충분한가요? 개수 기준은 없다. 기능마다 예외가 정상보다 많은가로 본다. 예외가 절반이 안 되면 부족한 것이다.

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

하자보수 기간에 뭐든 고쳐주나요? 아니다. 문서에 적힌 대로 동작하지 않는 것만 무상이다. 그래서 테스트 케이스가 곧 하자의 정의가 된다.

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

정리

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

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

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

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