rastalion.dev
⌘K
NOTES

IT 제품 개발 테스트 용어와 일반적인 진행 순서

2026-11-04updated 11-04 18 MIN

“E2E는 돌렸어요”, “스모크만 보고 배포했어요”, “회귀는 다음 스프린트에 하죠” 같은 말은 개발 회의에서 자주 나옵니다. 그런데 같은 단어를 사람마다 다른 범위로 쓰는 일이 많습니다. 한 사람은 E2E(end-to-end, 종단 간)를 브라우저 자동화 테스트로, 다른 사람은 실제 결제까지 거치는 업무 흐름 검사로 이해하면, “E2E는 통과했다”는 말이 무엇을 확인했다는 뜻인지 알 수 없습니다.

이 글은 테스트 용어를 웹·앱·API 기반 IT 제품을 만드는 개발자, 품질 보증(QA) 담당자, 기획자, 제품 담당자가 공통 언어로 쓸 수 있도록 정리합니다. 용어의 정의는 국제 소프트웨어 테스팅 자격 위원회(ISTQB)의 Foundation Level 실라버스와 용어집, 그리고 각 도구의 공식 문서를 기준으로 했습니다. 진행 순서는 일반적인 웹·API 제품을 위한 실무 예시입니다. 제품의 위험과 변경 규모에 맞춰 조정해서 씁니다.

이 글에서 알 수 있는 것

  • 테스트 용어를 범위·목적·변경·부하·수행 방식으로 나눠 읽는 기준
  • 단위부터 인수까지 테스트 수준, 기능·비기능, 회귀·재확인, 스모크, 성능 테스트 계열의 뜻과 서로 다른 점
  • 경계값 분석·동등 분할·상태 전이 같은 테스트 설계 기법과 테스트 코드 용어(픽스처, 스텁, 목, 커버리지, 불안정 테스트)
  • 일반적인 웹·API 제품에서 테스트를 진행하는 순서와 단계마다 확인할 것, 단계를 넘어가는 기준(진입·종료 기준)
  • 테스트 피라미드로 본 수준별 테스트의 비중
  • 할인 쿠폰 기능에 적용한 예, 결함 보고서에 남길 항목, 출시 전 체크리스트

이 글의 문서 조사 기준일은 2026년 11월 4일입니다. ISTQB Certified Tester Foundation Level(CTFL) 실라버스는 v4.0.1, ISTQB 용어집은 4.8.1을 기준으로 합니다. 예시에 쓴 사용자 수·시간·수치는 설명을 위해 정한 값이고 제품의 합격 기준은 따로 정해야 합니다.

1. 테스트 용어는 어떤 기준으로 읽을까요

테스트 이름 하나에는 여러 기준이 섞여 있습니다. 다음 표처럼 기준을 나눠 보면 용어가 서로 겹치는 이유가 드러납니다.

구분 기준 답하려는 질문 대표 용어
범위·수준 어디까지 연결해서 확인하는가? 단위(컴포넌트), 통합, 시스템, 인수
목적·유형 어떤 동작이나 품질을 확인하는가? 기능, 비기능(성능·보안·사용성 등), E2E
변경 후 확인 이번 변경이 어떤 문제를 만들었는가? 재확인, 회귀
입력·부하 조건 어떤 입력을 얼마나 많이, 얼마나 오래 주는가? 경계값, 부하, 스트레스, 스파이크, 장시간 지속
수행 방식 누가, 무엇을 기준으로 확인하는가? 수동·자동화, 탐색적, 블랙박스·화이트박스
실행·배포 방식 실제 적용 전에 무엇을 확인하는가? dry-run, 배포 리허설

ISTQB 실라버스는 테스트 수준을 함께 조직하고 관리하는 테스트 활동의 묶음으로, 테스트 유형을 특정 품질 특성과 관련된 테스트 활동의 묶음으로 정의합니다. 각 테스트 유형에 속한 테스트 활동은 대부분 모든 테스트 수준에서 수행할 수 있습니다.1 그래서 테스트 이름은 기준을 겹쳐서 붙는 경우가 많습니다.

예를 들어 “자동화된 E2E 기능 회귀 테스트”는 업무 흐름을 처음부터 끝까지 자동으로 실행하면서 변경 뒤에도 기존 기능이 요구대로 동작하는지 확인한다는 뜻입니다. 이 이름에는 성능이나 보안을 본다는 말이 없습니다. E2E라는 이름이 붙었다고 해서 성능·보안까지 확인했다고 볼 수는 없습니다.

E2E의 위치는 자료마다 조금 다릅니다. ISTQB 실라버스는 테스트 수준을 컴포넌트(단위)·컴포넌트 통합·시스템·시스템 통합·인수 다섯 가지로 나누고, 시스템 테스트에 업무 흐름 전체(end-to-end tasks)의 기능 테스트가 흔히 포함된다고 설명합니다.1 ISTQB 용어집은 E2E 테스트를 테스트 수준이 아니라 테스트 유형으로 정의합니다.2

정적 검사와 동적 테스트

정적 테스트(static testing)는 소프트웨어를 실행하지 않고 요구사항·설계·코드 같은 작업 산출물을 평가하는 것입니다. 사람이 검토하는 리뷰와 도구로 분석하는 정적 분석이 여기에 속합니다. 동적 테스트(dynamic testing)는 소프트웨어를 실행해 동작을 확인합니다.3 코드 리뷰, 요구사항 리뷰, 린터나 타입 검사 같은 정적 분석은 정적 테스트이고, 이 글에서 다루는 나머지 테스트는 대부분 동적 테스트입니다.

정적 테스트는 개발 초기에 결함을 찾을 수 있고 실행으로는 찾기 어려운 결함도 찾습니다. 실라버스는 요구사항의 모순·모호함·누락, 인터페이스 명세의 불일치, 수용 기준에 대한 테스트 누락 등을 정적 테스트로 더 쉽거나 싸게 찾는 결함의 예로 듭니다.3

수동 테스트와 자동화 테스트

수동 테스트(manual testing)는 사람이 절차를 수행하고 결과를 판단하는 방식이고 자동화 테스트(automated testing)는 도구나 코드로 실행과 판정을 자동화하는 방식입니다. 둘 중 하나만 고르는 문제가 아닙니다. DORA(DevOps Research and Assessment)는 자동화 테스트와 수동 테스트를 전달 과정 내내 함께 수행해야 한다고 설명하고, 수동 활동의 예로 탐색적 테스트·사용성 테스트·인수 테스트를 듭니다.4

블랙박스와 화이트박스

블랙박스(black-box) 기법은 테스트 대상의 내부 구조를 보지 않고 명세된 동작을 분석해 테스트를 설계합니다. 구현이 바뀌어도 요구 동작이 같으면 테스트를 그대로 쓸 수 있습니다. 화이트박스(white-box) 기법은 코드·아키텍처·데이터 흐름 같은 내부 구조와 처리를 분석해 테스트를 설계합니다.5,6 블랙박스·화이트박스 테스트는 모든 테스트 수준에 적용할 수 있고 수준마다 초점은 다릅니다.6

실라버스는 여기에 테스터의 지식과 경험을 활용하는 경험 기반 기법을 더해 세 가지로 나눕니다.5 2.2절에서 다루는 탐색적 테스트가 경험 기반 기법입니다.7

2. 테스트 용어집

2.1 범위와 구성요소 연결

용어 의미 제품 개발 예시
Unit test — 단위 테스트 함수·클래스처럼 따로 떼어 시험할 수 있는 작은 단위의 동작을 확인합니다. ISTQB 실라버스에서는 컴포넌트 테스트의 다른 이름입니다. 할인 계산 함수에 입력을 넣어 결과를 검사합니다.
Component test — 컴포넌트 테스트 구성요소를 따로 떼어 확인합니다. Cypress 같은 프런트엔드 도구에서는 UI 컴포넌트를 앱 없이 단독으로 띄워 시험하는 것을 말합니다. 주문 폼을 단독으로 띄워 입력과 오류 표시를 검사합니다.
Integration test — 통합 테스트 구성요소나 시스템 사이의 인터페이스와 상호작용을 확인합니다. 주문 서비스가 DB에 저장하고 메시지를 발행하는지 검사합니다.
System test — 시스템 테스트 통합된 시스템 전체의 동작과 기능을 확인합니다. 업무 흐름 전체의 기능 테스트와 품질 특성의 비기능 테스트를 흔히 포함합니다. 배포된 제품의 주문 기능과 접근 제어를 검사합니다.
E2E test — 종단 간 테스트 업무 흐름을 운영과 비슷한 조건에서 시작부터 끝까지 확인합니다. 로그인 → 상품 선택 → 주문 → 주문 내역 표시를 검사합니다.
Contract test — 계약 테스트 통신하는 두 애플리케이션을 각각 따로 실행해, 주고받는 요청·응답이나 메시지가 양쪽이 공유한 계약과 맞는지 확인합니다. 주문 API 응답에 소비 측이 쓰는 필드가 기대한 형식으로 있는지 검사합니다.

ISTQB 실라버스는 컴포넌트 테스트를 “단위 테스트라고도 부른다”고 적고, 구성요소(컴포넌트)를 따로 떼어 시험하는 수준으로 설명합니다. 통합 테스트는 구성요소 사이를 보는 컴포넌트 통합 테스트와, 다른 시스템·외부 서비스와의 인터페이스를 보는 시스템 통합 테스트로 나눕니다.1 Cypress는 컴포넌트를 앱 전체가 아니라 단독으로 마운트해 시험하는 방식을 컴포넌트 테스트라고 부릅니다.8 Cypress는 E2E 테스트를 웹 브라우저에서 백엔드와 외부 API·서비스 연동까지 거치는 테스트로 설명합니다.8 같은 단어라도 실라버스와 도구가 가리키는 범위가 다릅니다.

그래서 테스트 이름만 적지 말고 검사 대상, 실제로 연결한 의존성, 대역으로 바꾼 의존성을 함께 기록하면 범위가 분명해집니다. 대역은 2.6절에서 다룹니다.

계약 테스트는 ISTQB 용어집에서 인터페이스가 계약에 명시된 대로 쓰이는지 확인하는 통합 테스트의 한 종류입니다.9 계약 테스트 도구 Pact는 HTTP로 통신하면 요청과 응답이, 큐를 쓰면 큐에 올라가는 메시지가 확인 대상이라고 설명합니다.10 Pact FAQ는 시스템 통합 테스트 가운데 API를 올바르게 쓰는지와 API가 기대대로 응답하는지를 확인하는 부류는 계약 테스트가 대신할 수 있다고 적습니다.11 다만 서비스의 핵심 업무 로직이 동작하는지 확인하는 테스트는 대신하지 않는다고 덧붙입니다.11 성능·부하 테스트와 제공 측의 기능 테스트도 Pact가 맡지 않는 범위로 밝힙니다.12

2.2 기능, 인수, 변경 후 확인

용어 의미 제품 개발 예시
Functional test — 기능 테스트 제품이 해야 할 기능, 즉 “무엇을 하는가”를 확인합니다. 올바른 비밀번호는 허용하고 틀린 비밀번호는 거절합니다.
Non-functional test — 비기능 테스트 기능 외의 품질 특성, 즉 “얼마나 잘 동작하는가”를 확인합니다. 응답 시간, 장애 복구, 사용성을 검사합니다.
Acceptance test — 인수 테스트 시스템이 사용자의 업무 요구를 충족해 배포할 준비가 됐는지 확인하는 테스트 수준입니다. “취소하면 주문 상태와 재고가 복원된다”는 기준을 검사합니다.
UAT — User Acceptance Testing, 사용자 인수 테스트 시스템을 쓰기로 한 사용자가 그 시스템을 받아들이는지 확인하는 인수 테스트의 한 형태입니다. 운영 담당자가 실제 업무에 가까운 주문·환불 과정을 확인합니다.
Regression test — 회귀 테스트 변경 때문에 바꾸지 않은 부분에 결함이 생기거나 드러나지 않았는지 확인합니다. 할인 변경 후 결제·취소·환불을 다시 검사합니다.
Confirmation test / Retest — 재확인 테스트 결함을 고친 뒤 그 결함이 일으킨 실패가 다시 나지 않는지 확인합니다. 오류를 일으켰던 입력을 수정 후 다시 실행합니다.
Smoke test — 스모크 테스트 계획한 테스트를 진행해도 될 만큼 테스트 대상이 준비됐는지 빠르게 확인합니다. 배포 직후 접속, 로그인, 핵심 API 응답을 확인합니다.
Sanity test — 새니티 테스트 주요 기능이 대체로 동작해 더 깊은 검사를 진행해도 되는지 확인하는 뜻으로 씁니다. 자료마다 범위가 달라 팀에서 따로 정해 두는 편이 좋습니다. 수정한 검색 기능의 기본 동작을 짧게 확인합니다.
Exploratory test — 탐색적 테스트 테스트 대상을 배우면서 테스트를 동시에 설계·실행·평가합니다. 주문 중 새로고침, 뒤로 가기, 중복 클릭 같은 흐름을 탐색합니다.

ISTQB 실라버스는 기능 테스트를 대상이 “무엇을” 해야 하는지, 비기능 테스트를 “얼마나 잘” 동작하는지 확인하는 것으로 구분합니다. 비기능 품질 특성은 ISO/IEC 25010 분류를 따르며 성능 효율성·호환성·사용성·신뢰성·보안·유지보수성·이식성·안전성이 들어갑니다.6

재확인은 “그 결함이 고쳐졌는가”, 회귀는 “변경으로 다른 곳이 망가지지 않았는가”를 확인합니다. 회귀의 영향은 변경한 구성요소뿐 아니라 같은 시스템의 다른 구성요소나 연결된 다른 시스템에도 미칠 수 있습니다. 실라버스는 회귀 범위를 정하기 전에 영향 분석으로 어디가 영향을 받을 수 있는지 먼저 파악하라고 권합니다.13,14 또 회귀 테스트는 반복 실행되고 점점 늘어나므로 자동화하기 좋은 대상이라고 설명합니다.13,14

인수 테스트와 UAT는 같은 말이 아닙니다. 실라버스는 인수 테스트의 주요 형태로 사용자 인수 테스트(UAT), 운영 인수 테스트, 계약 인수 테스트, 규제 인수 테스트, 알파·베타 테스트를 듭니다.1 인수 테스트 주도 개발(ATDD)처럼 수용 기준에서 테스트 케이스를 먼저 만드는 방식에서는 그 테스트를 수동으로 실행할 수도, 자동화할 수도 있습니다.15

탐색적 테스트는 목적 없이 이것저것 눌러 보는 활동이 아닙니다. 실라버스는 탐색적 테스트를 정해진 시간 안에 테스트 목적을 담은 차터(charter)를 따라 진행하고, 수행한 단계와 발견한 내용을 세션 기록지에 남기는 세션 기반 방식으로 구조화할 수 있다고 설명합니다. 탐색적 테스트는 대상을 더 깊이 이해하고 아직 테스트하지 않은 영역의 테스트를 만드는 데 씁니다.7

스모크와 새니티는 자료마다 정의가 갈립니다. ISTQB 용어집은 스모크 테스트를 계획한 테스트를 진행해도 될 만큼 대상이 준비됐다는 확신을 얻는 테스트 유형으로 정의합니다.16 새니티 테스트는 ISTQB 용어집에 항목이 없습니다. Microsoft Learn의 교육 자료는 새니티를 주요 구성요소를 하나씩 확인하는 검사로, 스모크보다 넓고 회귀보다 얕은 검사로 설명했습니다.17 Grafana의 부하 테스트 분류에서 smoke는 아주 작은 부하로 테스트 스크립트와 기본 동작을 확인하는 테스트를 뜻합니다.18 팀에서 두 용어를 함께 쓴다면 각각 어떤 검사를 포함하는지 목록으로 합의해 두는 편이 안전합니다.

2.3 성능과 장시간 안정성

용어 의미 제품 개발 예시
Performance test — 성능 테스트 정한 조건에서 응답 시간·처리량·오류·자원 사용량을 확인하는 포괄적 용어입니다. 예상 트래픽에서 주문 API의 지연과 오류율을 측정합니다.
Load test — 부하 테스트 평소부터 최대까지 예상되는 부하에서 동작과 성능을 확인합니다. 부하 기반 테스트 전체를 가리키는 상위 용어로도 씁니다. 예상 동시 사용자 1,000명으로 주요 흐름을 실행합니다.
Stress test — 스트레스 테스트 예상하거나 정한 부하의 한계 또는 그 이상에서, 또는 메모리·서버 같은 자원이 줄어든 상태에서 동작을 확인합니다. 평소보다 많은 요청을 주고 오류와 처리 지연을 관찰합니다.
Spike test — 스파이크 테스트 갑작스러운 부하 급증을 버티고 안정 상태로 돌아오는지 확인합니다. 이벤트 시작 직후 요청량이 급증하는 상황을 만듭니다.
Soak test / Endurance test — 장시간 지속 테스트 상당한 부하를 오래 유지해 시간이 지나며 나타나는 문제를 찾습니다. 24시간 동안 메모리 증가, 연결 고갈, 지연 악화를 관찰합니다.

ISTQB 용어집은 부하 테스트를 보통 낮은 사용량부터 평소·최대 사용량까지 예상되는 범위의 다양한 부하에서 동작을 평가하는 성능 테스트로 정의합니다.19 용어집은 스트레스 테스트를 예상·명세된 부하의 한계 또는 그 이상이나 자원이 줄어든 상태에서 평가하는 성능 테스트로 정의합니다.19 스파이크 테스트는 갑작스러운 최대 부하에서 회복해 안정 상태로 돌아오는 능력을, 지속(endurance) 테스트는 상당한 부하를 상당한 시간 동안 유지할 때의 안정성을 확인합니다.19

Grafana는 부하 테스트(load testing)를 상위 용어로 쓰고 그 아래에 smoke·average-load·stress·spike·breakpoint·soak 여섯 유형을 둡니다. 평소 수준의 부하를 주는 테스트는 average-load라고 부르고, soak는 average-load의 지속 시간을 몇 시간에서 며칠로 늘린 변형이며 endurance 테스트라고도 부릅니다. Grafana는 부하 테스트 유형의 이름조차 합의가 없다고 덧붙입니다.18 비교해서 기억할 때는 예상 부하 → load(average-load), 높은 부하 → stress, 갑작스러운 부하 → spike, 오래 지속 → soak로 정리하면 됩니다.

성능 결과에는 다음 조건을 함께 기록합니다.

  • 부하: 동시 사용자 수와 초당 요청 수를 구별하고, 늘리는 방식(ramp-up)과 유지 시간을 적습니다.
  • 업무: 로그인·조회·주문 같은 요청의 비율과 테스트 데이터 규모를 적습니다.
  • 환경: 서버 자원, DB 상태, 캐시, 외부 연동과 대역 사용 범위를 적습니다.
  • 판정: 응답 시간의 백분위수(p95·p99, 95%·99% 지점의 값), 처리량, 오류율, 자원 사용량 기준을 적습니다.

p95는 95번째 백분위수입니다. 응답 시간을 빠른 순서로 늘어놓았을 때 95% 지점에 있는 값입니다. Grafana k6는 합격 기준(threshold)을 p(95)<200처럼 쓰고 이를 “요청의 95%가 200ms 미만이어야 한다”는 뜻으로 설명합니다. 기준식이 테스트 끝에 거짓이 되면 테스트 전체를 실패로 봅니다.20 같은 방식으로 p(95)<500은 요청의 95%가 500ms 미만이어야 한다는 기준입니다.

2.4 결과 비교와 입력·상태 설계

용어 의미 제품 개발 예시
동등성 테스트 — 구현 결과 비교 이 글에서는 같은 조건과 입력에서 기존·신규 구현의 결과나 관찰 가능한 동작을 비교하는 뜻으로 씁니다. 차분 테스트(differential testing)라고도 부릅니다. 기존 SQL과 최적화한 SQL의 결과를 비교합니다.
Equivalence partitioning — 동등 분할 테스트 대상이 같은 방식으로 처리할 것으로 예상하는 값끼리 분할을 나누고, 분할마다 대표값을 검사합니다. 허용 나이 18~65세를 기준으로 미만·범위 내·초과 분할에서 값을 하나씩 고릅니다.
Boundary value analysis — 경계값 분석 순서가 있는 분할의 경계값과 그 이웃을 검사합니다. 허용 수량 1~100을 2값 방식으로 시험한다면 0, 1, 100, 101을 검사합니다.
Valid / Invalid input — 정상·오류 조건 테스트 허용되는 값의 정상 처리와, 허용되지 않는 값·실패 조건의 적절한 처리를 확인합니다. 정상 주문 생성과 재고 부족·잘못된 수량의 거절을 확인합니다.
State transition testing — 상태 전이 테스트 상태 변경 규칙에 따라 허용된 전이와 허용되지 않은 전이를 검사합니다. 취소된 주문이 배송 상태로 바뀌지 못하는지 확인합니다.

동등성 테스트(구현 결과 비교)와 동등 분할은 다른 개념입니다. 구현 결과 비교는 같아야 할 두 시스템이나 같은 시스템의 두 버전에 같은 입력을 넣어 결과를 비교합니다. 출력이 다르면 적어도 한쪽 구현이 틀렸을 가능성이 높습니다.21 반대로 두 구현이 같은 결과를 내도 둘 다 같은 방식으로 틀렸을 수 있으므로 요구사항을 기준으로 한 검증을 함께 합니다. 비교할 때는 정확히 같아야 하는 항목, 허용 오차를 둘 항목, 순서·생성 시각처럼 비교 전에 정규화할 항목을 미리 정합니다.

동등 분할은 한 분할 안의 값이 모두 같은 출력을 낸다는 뜻이 아닙니다. 분할마다 값을 하나씩 시험합니다. 같은 분할의 값 하나로 결함이 드러난다면 그 분할의 다른 값으로도 드러날 것이라고 가정하기 때문입니다. 허용값으로 이뤄진 분할을 유효 분할, 허용되지 않는 값의 분할을 무효 분할이라고 부르고, 분할을 모두 다루려면 무효 분할도 시험해야 합니다.22

표의 “정상·오류 조건 테스트”는 positive/negative 테스트라고도 부릅니다. 실라버스는 ATDD 절에서 보통 첫 테스트 케이스는 예외나 오류 없이 정상 동작을 확인하는 positive 케이스라고 설명합니다.15 이를 마친 뒤에는 negative 테스트를 해야 한다고 덧붙입니다.15 테스트 설계 기법으로 옮기면 유효·무효 분할을 시험하는 것에 가깝습니다.

경계값 분석에는 두 방식이 있습니다. 2값 방식은 경계값마다 그 값과 이웃 분할의 가장 가까운 값을, 3값 방식은 경계값과 양쪽 이웃을 시험합니다.23 실라버스는 분할의 최솟값과 최댓값을 경계값으로 정의하므로 허용 수량 1~100이라면 이웃한 무효 분할의 0과 101도 경계값입니다.23

분할        무효(≤0)   유효(1~100)   무효(≥101)
경계값      0          1, 100        101

2값 방식    0, 1, 100, 101
3값 방식    -1, 0, 1, 2, 99, 100, 101, 102

3값 방식은 2값 방식이 놓칠 수 있는 결함을 찾을 수 있습니다. 실라버스는 x ≤ 10이어야 할 조건을 x = 10으로 잘못 구현한 예를 듭니다. 2값 방식의 값 10과 11로는 이 결함이 드러나지 않지만 3값 방식의 9로는 드러날 가능성이 높습니다.23

상태 전이 테스트에서 상태 표는 상태 다이어그램과 달리 허용되지 않는 전이를 빈칸으로 드러냅니다. 가장 널리 쓰는 기준은 허용된 전이를 모두 한 번씩 시험하는 것이고 모든 전이 기준은 허용되지 않은 전이까지 시도합니다. 허용되지 않은 전이를 테스트 케이스 하나에 하나씩만 넣으면 한 결함이 다른 결함을 가리는 일을 피하는 데 도움이 됩니다.24

2.5 제품의 품질과 위험

용어 의미 제품 개발 예시
Security test — 보안 테스트 인증·권한·입력 처리·정보 보호 같은 보안 요구를 확인합니다. 다른 사용자의 주문을 조회·수정할 수 없는지 검사합니다.
Accessibility test — 접근성 테스트 장애가 있는 사용자를 포함해 제품을 사용할 수 있는지 확인합니다. 키보드 조작, 포커스 이동, 화면 낭독기 안내를 확인합니다.
Compatibility test — 호환성 테스트 지원하는 브라우저·운영체제·기기·버전에서 동작하는지 확인합니다. 지원 대상 모바일 브라우저에서 주문 화면을 검사합니다.
Recovery test — 복구 테스트 장애 뒤 서비스와 데이터가 정한 기준대로 복구되는지 확인합니다. 서버 재시작이나 백업 복원 후 주문 누락·중복을 검사합니다.

보안과 접근성은 출시 직전에 몰아서 확인하기보다 설계와 개발 중에도 살핍니다. OWASP 웹 보안 테스트 가이드는 결함을 개발 수명주기 초기에 찾을수록 더 빠르고 싸게 고칠 수 있다며 일찍, 자주 테스트하라고 권합니다.25 W3C WAI도 웹사이트나 웹 애플리케이션을 만들 때 접근성을 초기부터 개발 과정 내내 평가하라고 안내합니다. 평가를 돕는 도구는 있지만 도구만으로는 사이트가 접근성 표준을 충족하는지 판단할 수 없고, 지식을 갖춘 사람의 평가가 필요하다고 적습니다.26

복구 검사에서는 화면이 다시 열리는지만 보지 말고 데이터가 정확한지, 복구에 얼마나 걸렸는지도 확인합니다.

2.6 테스트 코드와 결과 해석

용어 의미 제품 개발 예시
Test case — 테스트 케이스 사전 조건, 입력, 동작, 기대 결과, 사후 조건을 갖춘 개별 검사입니다. “재고 0인 상품은 주문할 수 없다”는 검사 한 건
Test suite — 테스트 모음 한 번의 테스트 실행에서 함께 실행할 테스트 묶음입니다. 주문 생성·취소·환불 테스트 모음
Fixture — 픽스처 테스트에 필요한 데이터·객체·환경을 일정하게 준비하는 구성입니다. 끝난 뒤 정리하는 작업을 포함할 수 있습니다. 테스트 사용자·상품을 만들고 종료 시 지웁니다.
Test double — 테스트 대역 테스트를 위해 실제 객체를 대신하는 대상의 총칭입니다. 실제 결제 서비스 대신 테스트용 결제 객체를 씁니다.
Stub — 스텁 테스트 중 호출에 미리 정해 둔 응답을 돌려주는 대역입니다. 결제 성공이나 실패 응답을 정해 반환합니다.
Mock — 목 받을 호출에 대한 기대를 미리 정해 두고, 그 호출을 모두 받았는지 검증하는 대역입니다. 결제 요청이 정확한 금액으로 한 번 호출됐는지 검사합니다.
Assertion — 검증문 실제 결과가 기대 조건을 만족하는지 판정합니다. 주문 금액이 기대값과 같은지 검사합니다.
Coverage — 커버리지 정한 대상(실행문·분기·요구사항 등)을 테스트가 얼마나 다뤘는지 백분율로 나타낸 값입니다. 측정 대상을 함께 적습니다. 실행문 커버리지 80%, 분기 커버리지 65%
Flaky test — 불안정 테스트 같은 코드에서 반복 실행할 때 통과와 실패가 간헐적으로 바뀌는 테스트입니다. 첫 실행은 실패하지만 재실행에서는 통과합니다.

테스트 케이스와 테스트 모음, 커버리지의 정의는 ISTQB 용어집을 따랐습니다.27 픽스처는 pytest 문서가 설명하듯 테스트에 정해진, 믿을 수 있고 일관된 맥락을 제공하는 것으로, 테스트 준비(arrange) 단계를 구성하는 절차와 데이터를 정의합니다. pytest의 픽스처는 끝난 뒤 스스로 정리하는 단계도 정의할 수 있습니다.28 검증문은 pytest에서 파이썬 표준 assert 문으로 씁니다.29

테스트 대역의 분류는 Martin Fowler가 소개한 Gerard Meszaros의 분류를 따랐습니다. 대역에는 더미(dummy), 페이크(fake), 스텁, 스파이(spy), 목이 있고, 스파이는 호출된 방식을 기록해 두는 스텁입니다.30 스텁·목은 대역의 종류이고 픽스처는 테스트 준비에 관한 용어라서 서로 다른 층위입니다. 이 분류는 역할을 기준으로 합니다. 라이브러리의 mock이라는 이름의 객체가 정해 둔 응답만 돌려주고 호출을 검증하지 않는다면 역할 기준 분류에서는 스텁에 해당합니다.

커버리지 100%는 결함이 없다는 뜻이 아닙니다. 실행문 커버리지 100%는 실행 가능한 실행문이 모두 한 번 이상 실행됐다는 뜻입니다. 그래도 분모가 0일 때만 실패하는 나눗셈처럼 특정 데이터에서만 드러나는 결함은 찾지 못할 수 있고, 모든 분기를 시험했다는 보장도 없습니다. 분기 커버리지 100%는 실행문 커버리지 100%를 포함하지만 그 반대는 성립하지 않습니다. 구현이 요구사항 일부를 빠뜨렸다면 화이트박스 테스트로는 그 누락을 찾지 못할 수도 있습니다.31

불안정 테스트를 재시도 통과로 끝내지 않습니다. Playwright는 첫 실행에서 실패했다가 재시도에서 통과한 테스트를 첫 실행에 통과한 테스트(passed)와 구별해 flaky로 분류합니다.32 DORA는 테스트 실패가 실제 결함을 뜻해야 한다며 불안정 테스트를 용인하지 말라고 권합니다.4 원인은 시간에 의존하는 코드, 테스트끼리 공유하는 상태, 네트워크, 실행 환경의 차이 등에서 찾을 수 있습니다. 재시도 설정으로 가리지 말고 원인을 찾아 고칩니다.

2.7 실행 전 확인과 리허설

용어 의미 제품 개발 예시
Dry-run — 시험 실행 도구가 제공하는 방식으로 실제 변경을 적용하기 전에 예정된 작업·대상·계획을 확인합니다. 무엇을 실행하고 무엇을 건너뛰는지는 도구마다 다릅니다. 인프라 생성·수정·삭제 계획이나 배치 처리 대상을 확인합니다.
Deployment rehearsal — 배포 리허설 테스트 환경에서 실제 배포·마이그레이션·검증·복구 절차를 연습합니다. DB 변경을 적용하고 구버전·신버전 호환성과 복구 절차를 확인합니다.

dry-run이 아무것도 실행하지 않는다는 뜻은 아닙니다. Terraform의 terraform plan은 제안한 변경을 실제로 적용하지는 않습니다. 다만 기본 동작으로 Terraform state가 최신인지 맞춰 보기 위해 이미 있는 원격 객체의 현재 상태를 읽은 뒤 계획을 만듭니다. 이 동작은 -refresh=false로 끌 수 있습니다. 계획을 만든 뒤에도 대상 시스템이 바뀌면 실제 적용 결과가 계획과 달라질 수 있으므로, 문서는 적용 전에 최종 계획을 다시 확인하라고 권합니다.33

계획 확인만으로 실제 적용이 성공할지, 얼마나 걸릴지, 데이터가 맞을지까지 알 수는 없습니다. 그래서 필요한 경우 실제 리허설을 이어서 합니다. Azure Well-Architected 가이드는 변경을 운영 환경과 같은 스테이징 환경에 먼저 배포하고 연습 환경에서 통제된 상태로 변경을 시험하라고 권합니다.34

3. 테스트는 어떤 순서로 진행할까요

3.1~3.5절은 일반적인 웹·API 제품의 개발·출시 흐름을 정리한 권장 예시입니다. 표준이 정한 고정 절차는 아닙니다. 빠른 검사는 개발 중에 자주 반복하고, 범위가 넓고 비용이 큰 검사는 변경의 영향과 위험에 맞춰 고릅니다.

이 순서의 바탕에는 두 원칙이 있습니다. 하나는 테스트를 일찍 시작하는 것입니다. ISTQB 실라버스는 이를 시프트 레프트(shift left)라고 부르며, 코드가 다 만들어지기를 기다리지 말고 명세 리뷰, 코드보다 먼저 쓰는 테스트, 지속적 통합(CI)의 자동 컴포넌트 테스트, 동적 테스트 전 정적 분석 등으로 테스트를 앞당기라고 설명합니다. 다만 나중 단계의 테스트를 소홀히 해도 된다는 뜻은 아니라고 덧붙입니다.35

다른 하나는 빠른 피드백입니다. DORA는 개발자가 로컬과 CI 모두에서 10분 안에 자동화 테스트 결과를 받을 수 있게 하라고 권합니다.4 또 빠른 단위 테스트를 느린 인수 테스트보다 먼저, 둘 다 수동 테스트보다 먼저 실행하라고 권합니다.4

3.1 전체 흐름

요구사항·위험·수용 기준 정리
  → 개발 중 정적 검사·단위/컴포넌트 테스트
  → 통합/계약 테스트·영향 범위 회귀 검사
  → 테스트 환경 배포·스모크 테스트
  → 기능/E2E/회귀/탐색적 검사
  → 위험에 따른 성능·보안·접근성·호환성·복구 검사
  → 인수·출시 판단
  → 운영 배포·스모크·관찰

결함 발견 → 수정 → 해당 결함 재확인 → 영향 범위 회귀 검사
                                      → 필요한 검증 단계로 복귀
테스트 진행 순서 A workflow diagram generated by Archify. 01 / 준비·개발 02 / 테스트 환경 03 / 출시·운영 EX / 결함 처리 5·6단계는 병렬 진행 가능 1. 요구와 기준 정리 · 요구사항·위험·수용 기준 · 준비·개발 1. 요구와 기준 정리 요구사항·위험·수용 기준 2. 개발 중 빠른 검사 · 정적 검사·단위/컴포넌트 · 준비·개발 2. 개발 중 빠른 검사 정적 검사·단위/컴포넌트 3. 구성요소 연결 검사 · 통합/계약·영향 범위 회귀 · 준비·개발 3. 구성요소 연결 검사 통합/계약·영향 범위 회귀 4. 테스트 환경 준비 · 배포·스모크 · 테스트 환경 4. 테스트 환경 준비 배포·스모크 5. 제품 동작 검사 · 기능/E2E/회귀/탐색적 · 테스트 환경 › 5·6단계는 병렬 진행 가능 5. 제품 동작 검사 기능/E2E/회귀/탐색적 6. 변경 위험 검사 · 성능·보안·접근성·호환성·복구 · 테스트 환경 › 5·6단계는 병렬 진행 가능 6. 변경 위험 검사 성능·보안·접근성·호환성·복구 7. 인수·출시 판단 · 수용 기준·UAT·알려진 문제 · 출시·운영 7. 인수·출시 판단 수용 기준·UAT·알려진 문제 8. 운영 배포·확인 · 스모크·관찰 · 출시·운영 8. 운영 배포·확인 스모크·관찰 결함 발견·수정 · 결함 처리 결함 발견·수정 해당 결함 재확인 · 결함 처리 해당 결함 재확인 영향 범위 회귀 검사 · 결함 처리 영향 범위 회귀 검사 필요한 검증 단계로 복귀 · 결함 처리 필요한 검증 단계로 복귀 범례 검사 단계 기준·판단 배포·확인 결함 처리
개발 중 빠른 검사부터 운영 확인까지, 결함이 나오면 관련 단계로 돌아갑니다

3.2 단계별 확인 사항

단계 주요 활동 다음 단계로 가기 전에 확인할 것
1. 요구와 기준 정리 핵심 사용자 흐름, 수용 기준, 실패했을 때의 영향, 지원 환경, 성능 목표를 정합니다. 기대 결과와 합격·중단 기준이 구체적인가?
2. 개발 중 빠른 검사 코드 리뷰·정적 분석, 단위·컴포넌트 테스트, 경계값·오류 조건 검사를 합니다. 변경한 작은 단위가 요구대로 동작하는가?
3. 구성요소 연결 검사 통합·계약 테스트와 영향 범위의 회귀 검사를 합니다. DB·API·메시지 같은 연결과 기존 동작이 유지되는가?
4. 테스트 환경 준비 운영을 대표하는 테스트 환경에 배포하고 스모크 테스트를 합니다. 버전·설정·데이터·연결이 검사에 맞는가?
5. 제품 동작 검사 기능·E2E·회귀·탐색적 검사를 합니다. 핵심 사용자 흐름과 정상·오류 조건이 기대대로인가?
6. 변경 위험 검사 관련된 성능·보안·접근성·호환성·복구 검사를 합니다. DB 변경이 있으면 마이그레이션도 검사합니다. 이 변경에서 중요한 위험과 실패 조건을 확인했는가?
7. 인수·출시 판단 수용 기준이나 UAT 결과, 알려진 문제, 운영 준비 상태를 검토합니다. 출시를 막는 결함이 없고, 남은 위험을 이해하고 있는가?
8. 운영 배포·확인 배포 후 스모크와 오류·지연·업무 지표 관찰을 합니다. 가능하면 노출 범위를 단계적으로 늘립니다. 배포를 계속해도 되는가? 중단·복구 조건에 걸리지 않았는가?

표의 오른쪽 칸처럼 다음 단계로 넘어가기 전에 확인할 것을 미리 정해 두는 것이 진입 기준(entry criteria)과 종료 기준(exit criteria)입니다. ISTQB 실라버스는 진입 기준을 어떤 활동을 시작하기 위한 전제 조건으로, 종료 기준을 그 활동을 끝났다고 선언하려면 달성해야 하는 것으로 정의합니다. 진입 기준을 충족하지 못한 채 시작하면 그 활동이 더 어렵고 오래 걸리며 비용과 위험도 커질 가능성이 높습니다. 두 기준은 테스트 수준마다 정하고 테스트 목적에 따라 달라집니다.36

구분 실라버스가 드는 전형적인 예 쿠폰 기능에 적용한 예
진입 기준 자원 확보(사람·도구·환경·테스트 데이터·예산·시간), 테스트 자료 확보(테스트 근거·테스트 가능한 요구사항·사용자 스토리·테스트 케이스), 대상의 초기 품질(예: 스모크 테스트가 모두 통과) 테스트 환경에 쿠폰·주문 테스트 데이터가 준비됐고 쿠폰 규칙의 수용 기준이 정해졌고 배포 직후 스모크 테스트가 통과했다.
종료 기준: 철저함의 측정값 달성한 커버리지, 해결되지 않은 결함 수, 결함 밀도, 실패한 테스트 케이스 수 쿠폰 관련 테스트 케이스의 실패가 0건이고, 출시를 막는 미해결 결함이 0건이다.
종료 기준: 예·아니요로 판단 계획한 테스트 실행, 정적 테스트 수행, 발견한 결함 모두 보고, 회귀 테스트 모두 자동화 4절 사례 표의 검사를 모두 실행했고, 발견한 결함은 모두 보고했다.

실라버스는 시간이나 예산이 바닥난 것도 정당한 종료 기준으로 볼 수 있다고 적습니다. 이런 경우에는 다른 종료 기준을 채우지 못했더라도, 이해관계자가 추가 테스트 없이 출시하는 위험을 검토하고 받아들였다면 테스트를 끝낼 수 있다는 것입니다. 애자일 개발에서는 종료 기준을 흔히 완료 정의(Definition of Done)라고 부릅니다. 완료 정의는 출시할 수 있는 항목에 대한 팀의 객관적 지표를 정합니다. 또 사용자 스토리가 개발이나 테스트를 시작하려면 갖춰야 하는 진입 기준은 준비 정의(Definition of Ready)라고 부릅니다.36 7단계 인수·출시 판단에서 남은 위험을 검토하는 일이 이런 판단에 해당합니다.

8단계의 노출 범위 조절도 출시 준비에 들어갑니다. Azure Well-Architected 가이드는 점진적 노출을 권합니다.34 점진적 노출은 새 기능을 작은 사용자 집단에 먼저 배포하고 문제가 없으면 점점 더 큰 집단으로 넓히는 방식이고, 가이드가 드는 대표 예는 카나리 배포(canary deployment)입니다.34 배포 중 최종 사용자에게 영향을 주는 상태 변화 경보가 오면 배포를 즉시 멈추고, 단계 사이에 상태 지표를 관찰할 시간을 충분히 두라고 설명합니다.34 카나리 배포는 배포 방식이지 테스트 종류가 아닙니다.

3.3 순서를 적용할 때의 원칙

  • 개발 전에도 검사합니다. 요구사항과 사용자 스토리, 수용 기준을 리뷰해 빈틈을 찾는 것도 정적 테스트입니다.3
  • 변경 뒤에는 재확인과 회귀를 이어서 합니다. 결함을 고쳤다면 재확인 다음에 영향 범위의 회귀 검사를 합니다.13
  • 비기능 피드백도 일찍 받습니다. 실라버스는 비기능 테스트를 가능하면 컴포넌트 수준부터 시작하는 것을 시프트 레프트의 한 방법으로 듭니다.35 5단계와 6단계는 병렬로 진행해도 됩니다.
  • 변경에 맞춰 범위를 고릅니다. 회귀 범위는 영향 분석으로 정합니다.13 문구 하나를 바꾸는 데 장시간 지속(soak) 테스트를 요구하거나, 권한을 바꾸면서 보안 검사를 빼는 식으로 적용하지 않습니다.
  • 실패하면 관련 단계로 돌아갑니다. 재실행으로 통과시키기보다 원인을 고치고 결과를 다시 확인합니다.
  • 운영 배포 뒤에도 확인합니다. 테스트 환경을 통과한 것과 운영에서 정상인 것은 따로 확인할 대상입니다.

3.4 성능 테스트의 내부 순서

목표·부하 모델·환경·측정 지표 정의
  → 최소 부하로 스크립트와 기본 동작 확인
  → 예상 부하로 load test
  → 위험에 따라 stress / spike / soak 선택
  → 결과 분석·수정
  → 필요한 조건에서 재측정

Grafana는 smoke 테스트로 시작해 더 높은 부하와 더 긴 시간으로 넓혀 가고 stress 테스트는 average-load 테스트를 먼저 돌린 뒤에 하라고 권합니다.18 stress·spike·soak를 매번 순서대로 모두 실행할 필요는 없습니다. Grafana는 시스템의 위험 특성이 어떤 유형에 무게를 둘지 정한다고 설명합니다.18 오래 쓰는 데 위험이 큰 시스템이면 soak를, 집중적인 사용에 위험이 큰 시스템이면 stress를 우선하라고 합니다.18

3.5 마이그레이션·배치·배포 작업의 확인 순서

대상·예상 변경·실패 영향 확인
  → 지원하는 경우 dry-run으로 계획 확인
  → 테스트 환경에서 실제 실행 리허설
  → 처리 결과·정합성·소요 시간·호환성 확인
  → 실패 감지·중단·복구 절차 확인
  → 운영 적용
  → 적용 후 결과 검증·관찰

DB 변경이 있다면 3.2절의 4단계, 즉 테스트 환경에 배포하는 시점부터 실제 실행 결과를 확인합니다. 출시 직전에는 복구할 수 있는지와 그 절차를 다시 검토합니다.

애플리케이션을 이전 버전으로 되돌려도 이미 바뀐 스키마나 데이터는 그대로 남을 수 있습니다. Azure Well-Architected 가이드는 데이터베이스·스키마처럼 상태가 있는 구성요소의 변경을 되돌리는 일은 복잡할 수 있다며 배포 지침에 데이터 변경을 다루는 방법을 분명히 적어 두라고 권합니다. 이 가이드는 대응 방법으로 (1) 변경을 되돌리는 롤백, (2) 배포 중에 문제를 고쳐 나아가는 롤포워드, (3) 정상으로 확인된 마지막 구성으로 새 인프라를 배포하는 방법을 듭니다.34 많은 Azure 데이터베이스 서비스가 특정 시점 복원(point-in-time restore)을 제공한다는 점도 적습니다.34 변경의 성격에 따라 어느 대응을 쓸지 미리 정해 둡니다.

3.6 테스트 피라미드: 수준별로 테스트를 얼마나 둘까

진행 순서와 함께 정할 것이 테스트 수준마다 테스트를 얼마나 둘지입니다. ISTQB 실라버스는 이를 테스트 피라미드로 설명합니다. 테스트 피라미드는 테스트마다 다루는 단위의 크기가 다를 수 있다는 것을 보여 주는 모델입니다. 이 모델은 팀이 테스트를 자동화하고 테스트 노력을 나눌 때 도움이 됩니다. 위층으로 갈수록 테스트 하나가 다루는 범위가 커지고, 시스템의 다른 요소에 기대는 정도도 커지며, 실행 시간이 길어집니다. 아래층의 테스트는 작고 빠르며 시스템의 다른 요소에서 떨어져 있고(격리) 작은 기능 하나를 확인합니다. 그래서 적절한 커버리지를 얻으려면 보통 많이 필요합니다. 맨 위층은 복잡한 고수준 E2E 테스트입니다. 아래층보다 대체로 느리지만 큰 기능을 확인하므로 보통 몇 개만 있어도 됩니다.37

             /\          E2E             적게 · 느림 · 넓은 범위
            /  \
           /----\        통합
          /      \
         /--------\      단위(컴포넌트)   많이 · 빠름 · 좁은 범위

층의 수와 이름은 모델마다 다릅니다. Mike Cohn이 2009년 책 『Succeeding with Agile』에서 소개한 처음 모델은 단위 테스트·서비스 테스트·UI 테스트의 세 층입니다. 단위(컴포넌트)·통합(컴포넌트 통합)·E2E로 나누는 모델도 널리 씁니다.37

Martin Fowler는 테스트 피라미드의 요점을 GUI를 거치는 고수준 테스트보다 저수준 단위 테스트를 훨씬 많이 두라는 것으로 정리합니다. UI를 통해 끝에서 끝까지 실행하는 테스트는 깨지기 쉽고 작성 비용이 크며 실행 시간이 길기 때문입니다. UI를 거치는 기록·재생 테스트 위주로 가면 금세 문제에 부딪혀 아이스크림 콘이 된다고도 적습니다. 그는 고수준 테스트를 두 번째 방어선으로 봅니다. 고수준 테스트에서 실패가 나왔다면 기능 코드의 버그와 함께 빠졌거나 잘못된 단위 테스트도 있다는 뜻이므로, 그 버그를 고치기 전에 단위 테스트로 먼저 재현하라고 권합니다.38 아이스크림 콘은 피라미드를 뒤집은 모양, 곧 위층의 UI 테스트가 많고 아래층의 단위 테스트가 적은 분포를 가리킵니다.

피라미드가 좋은 분포가 아니라며 통합 테스트를 더 많이 두자는 주장도 있습니다. Fowler는 이 차이가 “단위 테스트”의 정의가 서로 달라서 생기는 착시일 가능성이 높다고 봅니다.38 2.1절에서 본 것처럼 단위·컴포넌트·통합의 경계는 자료와 도구마다 다르므로, 팀의 피라미드를 그릴 때도 각 층에 무엇을 넣는지부터 합의합니다. 2.1절의 계약 테스트는 통합 층의 테스트 일부를 단위 층으로 옮기는 방법으로 볼 수 있습니다. Pact FAQ는 계약 테스트가 느린 피드백을 주는 통합 테스트를, 빠른 피드백을 주는 소비 측·제공 측 두 벌의 “단위” 테스트로 바꿀 수 있게 해 준다고 설명합니다.11

4. 하나의 제품 변경에 적용하면

사례: 주문에 할인 쿠폰 기능 추가

용어를 실제 작업에 연결해 보겠습니다. 제품의 요구사항과 위험에 따라 검사 항목은 조정합니다.

순서 확인 내용 적용할 테스트
1 만료일, 최소 금액, 중복 사용, 취소 시 복원 규칙을 정합니다. 요구사항 리뷰·수용 기준 작성
2 할인 계산, 경계 금액, 만료·오류 조건을 확인합니다. 단위·경계값·정상/오류 조건
3 쿠폰·주문·결제·DB 연결과 API 약속을 확인합니다. 통합·계약
4 기존 계산 구현을 교체한다면 결과를 비교합니다. 구현 결과 비교
5 로그인부터 쿠폰 적용·주문·취소까지 수행합니다. 기능·E2E
6 쿠폰 없는 주문과 기존 결제·환불을 다시 확인합니다. 회귀
7 동시 주문에서 같은 쿠폰의 중복 사용이 규칙대로 처리되는지 확인합니다. 동시성 통합·시스템 검사
8 다른 사용자의 쿠폰 사용 시도가 거절되는지 확인합니다. 보안·오류 조건
9 주문 처리량과 이벤트 트래픽이 영향을 받는다면 검사합니다. 부하, 필요하면 스파이크·장시간 지속
10 담당자가 쿠폰 업무 흐름과 수용 기준을 확인합니다. 인수·UAT
11 배포 직후 쿠폰 적용과 핵심 업무 지표를 확인합니다. 스모크·운영 관찰

테스트 케이스 기록 예시

항목 내용
ID / 이름 COUPON-007 / 만료된 쿠폰 사용 거절
목적·분류 만료 규칙 확인 / 기능·오류 조건
대상 버전·환경 검사할 빌드와 테스트 환경을 적습니다.
사전 조건 로그인한 사용자, 만료된 쿠폰, 주문 가능한 상품
입력·절차 만료된 쿠폰을 적용하고 주문을 시도합니다.
기대 결과 만료 안내가 표시되고 할인이 적용되지 않습니다.
사후 조건 쿠폰과 주문 상태가 잘못 바뀌지 않습니다.
실제 결과·증거 통과/실패, 실제 응답, 필요한 로그·화면을 적습니다.
후속 조치 실패하면 재현 조건과 결함을 기록하고, 수정 후 재확인 범위를 정합니다.

결함 보고서 기록 예시

테스트 케이스가 실패하면 결함 보고서를 남깁니다. ISTQB 실라버스는 결함 보고서의 목적을 세 가지로 듭니다. 결함을 처리하고 해결할 사람에게 충분한 정보를 주는 것, 작업 산출물의 품질을 추적할 수단을 주는 것, 개발·테스트 과정을 개선할 실마리를 주는 것입니다. 보고한 이상 현상이 실제 결함이 아니라 거짓 양성이나 변경 요청 같은 다른 것으로 밝혀질 수도 있습니다. 이는 결함 보고서를 처리하는 과정에서 가려집니다.39

위의 COUPON-007이 실패했다고 가정하고 실라버스가 드는 동적 테스트 결함 보고서의 전형적인 항목에 맞춰 채우면 다음과 같습니다.39 ID·버전·날짜는 설명을 위해 정한 값입니다.

항목 내용
ID / 제목 BUG-1042 / 만료된 쿠폰이 주문에 적용됨
발견일·작성자 2026-11-04, QA 담당자
테스트 대상·환경 빌드 2026.11.04-rc1, 테스트 환경
맥락 COUPON-007 실행 중, 5단계 제품 동작 검사, 만료일이 지난 테스트 쿠폰 사용
실패 설명·재현 절차 1) 테스트 사용자로 로그인한다. 2) 주문 가능한 상품을 고른다. 3) 만료된 쿠폰을 적용하고 주문한다. 응답 로그와 화면을 첨부한다.
기대 결과 만료 안내가 표시되고 할인이 적용되지 않는다.
실제 결과 안내 없이 할인이 적용되고 주문이 생성된다.
심각도 높음. 만료된 쿠폰으로 할인이 적용된다.
우선순위 출시 전 수정
상태 열림(open)
참조 테스트 케이스 COUPON-007, 쿠폰 만료 규칙의 수용 기준

심각도(severity)는 결함이 이해관계자의 이익이나 요구사항에 주는 영향의 정도이고 우선순위(priority)는 고치는 순서입니다. 실라버스도 둘을 별개 항목으로 둡니다. 상태는 열림, 보류, 중복, 수정 대기, 재확인 대기, 다시 열림, 닫힘, 거절 같은 값으로 관리합니다. 결함 관리 도구를 쓰면 ID, 날짜, 작성자, 초기 상태 같은 일부 항목이 자동으로 채워질 수 있습니다. 결함 보고서 양식과 예시는 ISO/IEC/IEEE 29119-3 표준에 있습니다. 이 표준은 결함 보고서를 사건 보고서(incident report)라고 부릅니다.39 결함을 고친 뒤 “재확인 대기” 상태에서 2.2절의 재확인 테스트를 하고 영향 범위의 회귀 검사로 이어 갑니다.

5. 출시 전 체크리스트

이 목록은 이번 변경에 필요한 검사와 출시 판단의 근거를 빠뜨리지 않기 위한 것입니다. 모든 테스트 종류를 실행할 필요는 없습니다.

  • 이번 변경의 핵심 사용자 흐름과 수용 기준을 확인했다.
  • 검사한 버전·환경·데이터와 실제 연동·대역의 범위를 기록했다.
  • 필요한 정적·단위·통합·계약 검사를 했다.
  • 핵심 동작을 확인하고, 필요한 기능·E2E와 영향 범위 회귀 검사를 했다.
  • 발견한 결함은 재현 절차, 기대 결과와 실제 결과, 심각도, 우선순위를 남겨 보고했다.
  • 고친 결함은 재확인했고, 불안정 테스트는 정상 통과와 구별했다.
  • 이번 변경의 성능·보안·접근성·호환성 위험을 검토했고, 위험이 있다고 판단한 항목은 검사를 했다.
  • DB·배치·배포 변경이 있으면 위험에 맞는 실제 리허설을 했고, 그 결과와 복구 절차를 확인했다.
  • 출시를 막는 결함과 남은 문제를 검토하고 출시 판단을 기록했다.
  • 운영 배포 후의 스모크·관찰 항목과 중단·복구 조건을 정했다.

6. 팀에서 합의해 둘 것

항목 합의할 내용
용어와 범위 단위/컴포넌트, 스모크/새니티, E2E가 우리 팀에서 각각 무엇을 포함하는가?
환경과 의존성 어떤 검사에서 실제 DB·외부 서비스·샌드박스·대역을 쓰는가?
실행 주기 변경마다, PR마다, 배포마다, 정기적으로 어떤 검사를 하는가?
합격·중단 기준 단계마다 진입·종료 기준은 무엇이고, 기능·성능·알려진 결함·불안정 테스트를 어떻게 판정하는가?
기록과 책임 누가 결과를 확인하고, 실패하면 누가 원인 조사와 출시 판단을 맡는가?
결함 분류 심각도와 우선순위를 어떤 기준으로 매기고, 어떤 결함을 출시를 막는 결함으로 보는가?
복구 장애나 데이터 문제를 어떻게 감지하고 중단·복구하는가?

이 글은 일반적인 개발·출시 용어와 흐름을 정리한 참고 자료입니다. 특정 제품의 코드, 테스트 구성, 성능 수치, 배포·복구 정책을 검사한 결과가 아닙니다. 하드웨어·안전 관련 제품이나 별도 규정이 적용되는 환경의 상세 절차는 다루지 않습니다.

참고 자료

  1. ISTQB — Certified Tester Foundation Level Syllabus v4.0.1. 2024-09-15. 2.2 Test Levels and Test Types, 2.2.1 Test Levels(p.28–29). 테스트 수준과 유형의 정의, 다섯 가지 테스트 수준, 인수 테스트의 형태. ↩ ↩2 ↩3 ↩4

  2. ISTQB Glossary — end-to-end testing. 용어집 4.8.1. 업무 프로세스를 운영과 비슷한 조건에서 처음부터 끝까지 시험하는 테스트 유형. ↩

  3. ISTQB CTFL Syllabus v4.0.1. 1.1 What is Testing?(p.15), 3.1 Static Testing Basics(p.33–34). 정적·동적 테스트의 구분, 정적 테스트로 찾기 쉬운 결함의 예, 사용자 스토리와 수용 기준 리뷰. ↩ ↩2 ↩3

  4. DORA — Capabilities: Test automation. 2025-07-17 갱신. 자동·수동 테스트를 함께 수행, 10분 안의 피드백, 빠른 테스트를 먼저 실행하는 순서, 불안정 테스트를 용인하지 말 것. ↩ ↩2 ↩3 ↩4

  5. ISTQB CTFL Syllabus v4.0.1. 4.1 Test Techniques Overview(p.39). 블랙박스·화이트박스·경험 기반 기법의 구분. ↩ ↩2

  6. ISTQB CTFL Syllabus v4.0.1. 2.2.2 Test Types(p.29–30). 기능·비기능·블랙박스·화이트박스 테스트의 정의, ISO/IEC 25010 품질 특성, 네 유형 모두 모든 테스트 수준에 적용. ↩ ↩2 ↩3

  7. ISTQB CTFL Syllabus v4.0.1. 4.4 Experience-based Test Techniques, 4.4.2 Exploratory Testing(p.43–44). 경험 기반 기법으로서의 탐색적 테스트, 정의와 세션 기반 방식. ↩ ↩2

  8. Cypress — Testing Types. E2E 테스트와 컴포넌트 테스트의 범위. ↩ ↩2

  9. ISTQB Glossary — contract testing. 인터페이스가 계약대로 쓰이는지 확인하는 통합 테스트. ↩

  10. Pact Docs — Introduction. 2026-08-25 갱신. 각 애플리케이션을 따로 실행해 메시지가 계약과 맞는지 확인하는 계약 테스트의 정의와 확인 대상. ↩

  11. Pact Docs — FAQ. 2025-10-21 갱신. 계약 테스트가 대신하는 시스템 통합 테스트와 대신하지 않는 업무 로직 테스트. ↩ ↩2 ↩3

  12. Pact Docs — What is Pact good for?. Pact가 맡지 않는 성능·부하 테스트와 제공 측 기능 테스트. ↩

  13. ISTQB CTFL Syllabus v4.0.1. 2.2.3 Confirmation Testing and Regression Testing(p.30–31). 재확인과 회귀의 정의, 영향 분석, 회귀 테스트 자동화. ↩ ↩2 ↩3 ↩4

  14. ISTQB Glossary — regression testing, confirmation testing. 바꾸지 않은 영역의 결함을 찾는 회귀 테스트와, 고친 결함의 실패가 재발하지 않는지 보는 재확인 테스트. ↩ ↩2

  15. ISTQB CTFL Syllabus v4.0.1. 4.5.3 Acceptance Test-driven Development(p.46). 구현 전에 수용 기준에서 테스트 케이스를 만들고 수동이나 자동으로 실행하는 방식, positive → negative → 비기능 특성 순서. ↩ ↩2 ↩3

  16. ISTQB Glossary — smoke testing. 계획한 테스트를 진행해도 될 만큼 대상이 준비됐는지 확인하는 테스트 유형. ↩

  17. Microsoft Learn — What is functional testing? (2024-04-23 보관본). 스모크·새니티·회귀를 비교한 교육 자료. 원래 주소는 현재 다른 문서로 이동한다. ↩

  18. Grafana — Types of load testing. smoke·average-load·stress·spike·breakpoint·soak 유형, 진행 순서, 위험에 따른 유형 선택. ↩ ↩2 ↩3 ↩4 ↩5

  19. ISTQB Glossary — load testing, stress testing, spike testing, endurance testing. 성능 테스트 계열의 정의. ↩ ↩2 ↩3

  20. Grafana k6 — Thresholds. v2.3.x. 합격 기준의 의미와 p(95) 표현. ↩

  21. Rao 외 — DiffSpec: Differential Testing with LLMs using Natural Language Specifications and Code Artifacts. 2024. 같은 입력에서 같아야 할 두 구현의 출력을 비교하는 차분 테스트의 개념. ↩

  22. ISTQB CTFL Syllabus v4.0.1. 4.2.1 Equivalence Partitioning(p.39–40). 분할의 정의, 유효·무효 분할. ↩

  23. ISTQB CTFL Syllabus v4.0.1. 4.2.2 Boundary Value Analysis(p.40). 2값·3값 경계값 분석과 3값 방식이 찾는 결함의 예. ↩ ↩2 ↩3

  24. ISTQB CTFL Syllabus v4.0.1. 4.2.4 State Transition Testing(p.41–42). 상태 표의 무효 전이, 유효 전이 커버리지와 모든 전이 커버리지. ↩

  25. OWASP Web Security Testing Guide v4.2 — Introduction. 개발 수명주기 초기부터 일찍, 자주 테스트하라는 원칙. ↩

  26. W3C WAI — Evaluating Web Accessibility Overview. 2026-08-12 갱신. 개발 초기부터의 평가와 도구만으로는 판단할 수 없다는 점. ↩

  27. ISTQB Glossary — test case, test suite, coverage. ↩

  28. pytest — About fixtures, How to use fixtures. pytest 9.2. 픽스처의 정의와 정리 단계. ↩

  29. pytest — How to write and report assertions in tests. 표준 assert 문으로 기대값 검증. ↩

  30. Martin Fowler — Test Double. 2006. Gerard Meszaros의 대역 분류(Dummy·Fake·Stub·Spy·Mock). ↩

  31. ISTQB CTFL Syllabus v4.0.1. 4.3 White-Box Test Techniques(p.42–43). 실행문·분기 커버리지의 정의와 한계. ↩

  32. Playwright — Retries. 재시도 뒤 통과한 테스트를 flaky로 분류하는 방식. ↩

  33. HashiCorp — terraform plan command reference. v1.17.x. 변경을 적용하지 않는 계획, 기본 상태 갱신과 -refresh=false, 적용 전 최종 계획 재확인. ↩

  34. Microsoft Azure Well-Architected — Architecture strategies for safe deployment practices. 스테이징·연습 환경, 점진적 노출과 카나리, 상태 지표에 따른 중단, 상태를 가진 구성요소의 롤백과 복구 방법. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  35. ISTQB CTFL Syllabus v4.0.1. 2.1.5 Shift Left(p.27). 테스트를 앞당기는 방법과 그 한계. ↩ ↩2

  36. ISTQB CTFL Syllabus v4.0.1. 5.1.3 Entry Criteria and Exit Criteria(p.49). 진입·종료 기준의 정의와 전형적인 예, 시간·예산 소진과 위험 수용, Definition of Done·Ready. ↩ ↩2

  37. ISTQB CTFL Syllabus v4.0.1. 5.1.6 Test Pyramid(p.50–51). 층별 세분성·격리·실행 시간, 층의 수와 이름. ↩ ↩2

  38. Martin Fowler — Test Pyramid. 2012. 저수준 단위 테스트를 훨씬 많이 두라는 요점, UI 기반 E2E 테스트의 비용, 고수준 테스트에서 드러난 버그를 단위 테스트로 재현하라는 권고. ↩ ↩2

  39. ISTQB CTFL Syllabus v4.0.1. 5.5 Defect Management(p.56–57). 결함 보고서의 목적과 전형적인 항목, 상태 값, ISO/IEC/IEEE 29119-3. ↩ ↩2 ↩3

Advertisement
Comments