요구사항에서 테스트 케이스를 도출하는 설계 절차

요구사항을 테스트 자산으로 연결하는 방식

요구사항 기반 테스트(Requirements-based Testing, RBT)는 문서화된 요구사항에서 테스트 케이스를 도출하고 검증하는 절차이자 방법론이다. 테스트 케이스를 바로 작성하는 대신 요구사항의 품질을 먼저 확인하고, 요구사항을 모델로 해석한 뒤 커버리지와 추적성을 관리한다.

대상은 기능 요구사항에 한정되지 않는다. 기능 요구사항은 유스케이스, 상태, 결정 규칙을 중심으로 다루며, 비기능 요구사항은 성능·보안·신뢰성·규모·접근성 같은 품질 속성을 측정 가능한 지표로 바꾼다.

이 과정에서 요구사항 품질 리포트, 의사결정표·상태 전이·유스케이스 등의 테스트 모델, 커버리지 기준서, 테스트 케이스 세트, 요구사항 추적 매트릭스(RTM), 리뷰 기록, 베이스라인 패키지가 만들어진다.

입력을 확정하고 요구사항의 결함을 먼저 찾는다

출발점은 SRS, EPIC, 스토리와 인수 기준, 인터페이스 명세, UX·데이터 사전, 비기능 요구사항, 규제·표준이다. 이 자료에서 테스트 범위를 식별하고 변경 이력을 확인한 뒤, 우선순위와 리스크 태그를 부여한다. 이 단계의 결과물은 범위 명세, 초기 RTM 스켈레톤, 베이스라인 후보 목록이다.

수집한 요구사항은 테스트 설계에 넘기기 전에 검증가능성·일관성·명확성을 점검한다. 필수 또는 금지 용어처럼 모호성을 유발하는 표현을 확인하고, SMART 기준과 테스트 가능성 평가를 적용해 결함이나 모순을 찾는다. 발견된 문제는 요구사항 결함 리스트와 보완 요청서로 관리하며, 수정된 요구사항 버전을 다음 단계의 입력으로 사용한다.

요구사항에서 결함을 늦게 발견할수록 테스트 모델과 케이스에도 수정이 전파된다. 그래서 요구사항에서 테스트 모델로 넘어가기 전에 품질을 보강하는 결함 루프가 필요하다.

요구 유형에 맞춰 테스트 모델을 고른다

품질 보완이 끝난 요구사항은 유형별로 테스트 기법에 매핑한다. 의사결정표, 상태 전이, 유스케이스, 동등 분할·경계값, 페어와이즈가 여기에 사용된다. 비기능 요구사항은 측정 가능한 시나리오와 SLO로 변환한다.

이때 테스트 모델은 테스트 케이스 생성의 단일 진실 공급원이 된다. 입력 도메인, 상태, 규칙, 테스트 데이터 요구사항을 모델 아티팩트로 남겨 두면 케이스의 근거를 역추적할 수 있고, 동일한 규칙을 서로 다른 방식으로 중복 구현하는 문제도 줄일 수 있다.

커버리지 기준을 리스크와 함께 정한다

테스트 모델과 리스크·우선순위를 바탕으로 커버리지 기준을 정한다. 예를 들어 High 요구에는 100%, Medium 요구에는 80%를 적용할 수 있다. 조합이 과도하게 늘어나는 경우에는 pairwise나 orthogonal array 같은 조합 축소 전략을 사용하고, 비기능 요구사항에는 목표값과 부하 프로파일을 정의한다.

커버리지 계획서에는 샘플링 규칙과 중복 억제 규칙도 포함한다. 모든 항목에 100%를 요구하면 일정과 비용이 급격히 커질 수 있으므로, 중요도와 리스크에 따라 임계치를 달리 적용해야 한다.

실행 가능한 케이스와 RTM을 만든다

커버리지 계획과 모델, 데이터 요구사항을 바탕으로 케이스 식별자, 전제조건, 절차, 테스트 데이터, 기대 결과, 오라클을 구체화한다. 자동화 적합성도 이 단계에서 평가한다. 결과물은 실행 가능한 테스트 케이스, 데이터 세트, 자동화 후보 목록이다.

이후 RTM에 Req↔Model↔TC↔Defect 관계를 기록한다. 요구사항과 모델, 테스트 케이스, 결함을 양방향으로 연결하면 결측과 중복을 확인할 수 있으며, 커버리지 실적과 보완 액션 아이템도 함께 관리할 수 있다. 변경이 발생했을 때 영향도를 분석하고 회귀 테스트 범위를 정하는 근거도 이 관계에서 나온다.

⤢✕

리뷰를 거쳐 베이스라인과 자동화로 넘긴다

RTM, 테스트 케이스, 메트릭을 대상으로 동료 리뷰와 워크스루를 수행하고 표준 준수 여부를 확인한다. 데이터 분리와 공통 스텝 추출로 유지보수성을 개선한 뒤, CI 연동 계획을 세운다.

승인된 베이스라인, 자동화 파이프라인 백로그, 변경관리 계획이 이 단계의 산출물이다. ALM·이슈 트래커, 모델링 도구, 테스트 관리 도구, CI의 성능·보안 도구를 연결할 수 있으며, 테스트 데이터 관리(TDM)와 시드·마스킹 정책도 표준화 대상이다.

모델별 적용 특성

기법	성능(효율)	확장성	일관성	안정성	운영 편의
동등 분할/경계값 분석	높음	높음	중간	높음	높음
의사결정표	중간	중간	매우 높음	높음	중간
상태 전이	중간	중간	높음	높음	중간
페어와이즈(조합 축소)	높음	매우 높음	중간	중간	높음
유스케이스 기반	중간	중간	중간	중간	중간

규칙과 상태가 복잡한 기능에 적용하기

금융의 계좌 이체 기능에서는 수수료와 한도 규칙을 의사결정표로 모델링하고, 금액과 일 한도에 경계값 테스트를 적용할 수 있다. 거래 상태는 작성→대기→성공/실패 전이로 검증한다. 비기능 시나리오에는 TPS 2000, p95=300ms, 2FA 실패 시 잠금이라는 보안 요구를 포함하고 부하·취약점 테스트와 연계한다.

커머스의 쿠폰·장바구니 프로모션은 쿠폰 적용 규칙을 결정표로, 사용자 흐름을 유스케이스로 변환한다. 디바이스·브라우저·결제수단 조합은 페어와이즈로 축소할 수 있다. 트래픽 피크 5배 스파이크, 캐시 정책과 정합성, 프로모션 동시성도 테스트 케이스 설계 대상이다.

공공 API 게이트웨이의 할당량과 스로틀링은 정상→제한→차단 상태 전이와 재시도 백오프 규칙을 모델링하고, 분당 호출 수에 경계값을 적용한다. 장애 복원 시나리오, SLA 위반 알림 테스트, 감사 로그와 추적성 검증도 함께 다룬다.

운영 비용과 품질의 균형

모델을 먼저 설계하면 케이스를 곧바로 작성할 때 생기기 쉬운 중복과 누락을 줄일 수 있지만, 초기 모델링 비용은 높아진다. 테스트 데이터도 케이스에서 분리하면 재사용성과 유지보수성이 좋아지지만 초기 TDM 구축 비용을 고려해야 한다.

자동화 후보는 빈도·안정성·ROI를 기준으로 선별한다. 불안정한 UI 영역은 계약 테스트나 API 레벨 테스트로 대체하는 방안을 검토할 수 있다.

요구사항 기반 테스트를 운영하면 요구사항 결함 조기 발견률은 2040%p 증가하고, 중복 케이스는 1530% 감소하며, High 요구 커버리지는 ≥95% 달성하고 회귀 선정 시간은 50% 단축할 수 있다. 변경 대응의 탄력성, 의사소통의 표준화, 감사·컴플라이언스 대응의 용이성, 품질에 대한 조직 신뢰도도 함께 높아진다.