테스트 케이스로 재현성과 요구사항 추적성 확보하기

조건과 결과를 연결하는 검증 계약

테스트 케이스는 특정 요구사항이나 기능을 검증하기 위해 조건, 입력값, 실행 단계, 기대 결과를 미리 정리한 단위다. 성공과 실패를 판정할 수락 기준도 함께 둔다. 기능 정확성을 확인하는 데서 그치지 않고, 변경 뒤 회귀 위험을 억제하고 영향 범위를 파악하며 자동화와 리포팅에 필요한 정형 구조를 제공한다.

운영 가능한 케이스에는 테스트 식별자와 버전, 우선순위, 전제조건, 테스트 데이터, 실행 단계, 기대 결과, 후처리, 소유자 같은 메타데이터가 필요하다. 이 정보가 빠지면 같은 검증을 다시 실행하거나 실패 원인을 분리하기 어려워진다.

재실행 가능한 케이스가 갖춰야 할 정보

전제조건에는 환경, 권한, 데이터 상태를 적고 입력값의 범위도 분명히 둔다. 기대 결과는 화면이나 API의 출력만 뜻하지 않는다. 데이터베이스 상태 변경, 로그, 외부 호출 같은 부수효과까지 검증 대상에 포함한다. 수락 기준을 정량 문구로 통일하면 해석 차이도 줄일 수 있다.

재현성은 환경과 데이터가 흔들리지 않을 때 확보된다. 테스트 데이터에는 고유 식별자를 부여하고, 시드(seed)와 고정 시점 스냅샷을 사용한다. 외부 의존성은 모킹이나 스텁으로 처리하거나 계약 기반 테스트로 다룬다. 실행이 끝난 뒤에는 rollback 또는 삭제로 상태를 정리해 다른 케이스와 독립되게 만든다.

변경을 따라가려면 요구사항 ID, 테스트 케이스 ID, 결함 ID 사이에 양방향 링크가 있어야 한다. 변경이 발생하면 버전을 올리고 이력을 남긴다. 커버리지 리포트와 RTM(Requirements Traceability Matrix)은 아직 검증되지 않은 요구사항 영역을 찾는 데 쓴다.

자동화 환경에서는 테스트 로직과 데이터 드리븐 파라미터를 분리하는 편이 유지보수에 유리하다. ID, 태그, 우선순위, 컴포넌트로 실행 대상을 고를 수 있어야 하며, CI 통합과 병렬 실행에서도 안전한지 검토해야 한다. 이 구조는 기능 테스트뿐 아니라 성능, 보안, 호환성 검증에도 확장된다. 공통 before/after 훅으로 준비와 정리 절차를 표준화하고, 비기능 요구사항에는 p95 지연시간 같은 계량 지표를 포함할 수 있다.

작성부터 재테스트까지 이어지는 흐름

테스트 케이스는 계획, 설계, 검토, 데이터 준비, 실행, 결과 기록, 결함 처리, 리포트, 유지보수의 흐름 안에서 관리한다. 실패가 나오면 데이터나 환경 문제인지 코드 결함인지 분리해 분석해야 한다. 데이터 준비가 실패하거나 환경이 일치하지 않을 때에는 자동 롤백, 재시도, 격리 절차도 마련한다.

⤢✕

제품 유형에 따라 달라지는 기대 결과

웹 API의 기능 및 회귀 테스트에서는 고정 토큰과 계정, 시드 데이터, 외부 호출 모킹을 전제조건으로 둘 수 있다. 최대·최소 경계값과 필수 필드 누락 같은 오류 입력을 넣고, HTTP 상태와 페이로드 스키마, 데이터베이스 변경 및 이벤트 발행을 함께 확인한다.

데이터 파이프라인은 소스 스냅샷과 스키마 버전을 고정한 상태에서 샘플 배치 파일이나 메시지 세트를 입력한다. 행 수와 합계의 불변성, 중복률, p95 처리시간이 기대 결과가 된다.

모바일 앱의 흐름을 검증할 때는 디바이스 매트릭스, OS 버전, 네트워크 조건을 전제조건으로 기록한다. 탭, 스크롤, 입력 같은 사용자 행동 시나리오를 실행한 뒤 화면 전환, 접근성 라벨, 크래시 없음 여부를 확인한다.

템플릿과 관리 방식 선택

운영 템플릿에는 TC_ID, Title, Requirement_ID, Priority, Preconditions, Test_Data, Steps, Expected_Result, Postconditions, Owner, Version, Tags를 필수 필드로 둔다. 식별자는 TC-{도메인}-{일련번호} 형식을 사용할 수 있으며, 상태는 Draft → In Review → Approved → Deprecated로 관리한다.

관리 방식	성능	확장성	일관성	안정성	운영 편의
스프레드시트	중간	낮음	낮음	낮음	높음
테스트 관리 도구(TestRail, Zephyr 등)	중간	높음	높음	높음	중간
코드 기반(pytest/JUnit)	높음	높음	높음	중간	중간

선택 기준은 팀의 자동화 성숙도, 규제 준수 필요성, 리포팅 요구 수준이다.

pytest로 API 케이스를 실행하는 예

전제조건은 Python 3.11+, pytest 8.x, requests 2.x와 로컬 또는 스테이징 API 엔드포인트 접근이다.

# test_user_api.py
# 실행: pytest -q
import os
import random
import string
import requests
import pytest

BASE_URL = os.getenv("API_BASE", "https://staging.example.com/api")
TOKEN = os.getenv("API_TOKEN", "fixed-test-token")

def rand_email():
    return "u_" + "".join(random.choices(string.ascii_lowercase, k=6)) + "@example.test"

@pytest.mark.parametrize("payload,expected_status", [
    ({"email": lambda: rand_email(), "name": "alice"}, 201),   # 정상
    ({"email": "", "name": "alice"}, 400),                    # 필수 필드 오류
    ({"email": "not-an-email", "name": "bob"}, 422),          # 유효성 오류
])
def test_create_user(payload, expected_status):
    # Preconditions: 인증 토큰 유효, 사용자 이메일 중복 없음
    body = {k: (v() if callable(v) else v) for k, v in payload.items()}
    r = requests.post(f"{BASE_URL}/users", json=body, headers={"Authorization": f"Bearer {TOKEN}"})
    assert r.status_code == expected_status

    # Postconditions: 성공 시 리소스 정리로 독립성 보장
    if r.status_code == 201:
        uid = r.json()["id"]
        d = requests.delete(f"{BASE_URL}/users/{uid}", headers={"Authorization": f"Bearer {TOKEN}"})
        assert d.status_code in (200, 204)

이 예제의 핵심은 생성, 검증, 삭제를 하나의 흐름으로 유지해 테스트 데이터를 격리하는 데 있다. 난수 시드를 관리하고 외부 호출의 타임아웃을 설정해 재현성을 높인다. @pytest.mark에는 requirement_id, priority, component 태그를 부여해 요구사항과 실행 결과를 연결할 수 있다.

데이터 보호와 환경 일관성의 균형

테스트에는 실데이터를 반입하지 않고 마스킹 또는 합성 데이터를 사용한다. 현실성은 낮아질 수 있으므로 계약 기반 검증을 강화하는 방식으로 보완한다.

데이터베이스 테스트는 케이스마다 트랜잭션을 시작하고 롤백해 격리성을 확보한다. 다만 외부 시스템과 연동하면 일관성을 맞추는 비용이 커질 수 있다. Flaky 테스트는 재시도를 최후 수단으로 두고 타이밍, 레이스, 비결정성 같은 근본 원인을 먼저 제거한다. 테스트 시간 증가는 안정성 개선과 함께 판단한다.

운영 환경과 유사한 환경에서는 구성 요소의 버전과 플래그를 동기화한다. 인프라 비용은 늘 수 있지만 결함을 더 일찍 발견할 수 있다.

회귀 위험을 낮추는 운영 결과

테스트 케이스를 정형화해 운영하면 회귀 결함률은 3050% 감소하고, 재현 불가 이슈는 70% 이상 축소된다. 테스트 준비와 정리를 자동화하면 평균 실행 시간도 2040% 단축된다.

요구사항 변경의 영향 범위를 가시화할 수 있고, 리뷰 품질과 감사·규제 대응의 용이성도 높아진다. 조건, 입력, 기대 결과를 일관되게 기록하고 데이터 격리, 요구사항 링크, 자동화 중심의 수명주기를 함께 운영하는 것이 핵심이다.