명세기반 테스트로 기능 요구사항을 검증하는 방법

요구사항을 테스트의 기준으로 삼는 방식

명세기반 테스트(Black Box Test)는 시스템 내부 구조나 코드 구현을 알지 못해도 수행할 수 있는 테스트 접근이다. 요구사항 명세, 사용자 스토리, 유스케이스를 기준으로 입력을 주고 예상 결과와 실제 결과를 비교한다. 관심사는 시스템이 어떻게 구현됐는지가 아니라, 요구된 기능을 제대로 제공하는지에 있다.

구현 방식에 독립적이므로 개발자와 테스터가 역할을 나누기 좋고, 실제 사용자 경험에 가까운 조건을 다룰 수 있다. 단위 테스트부터 시스템 테스트와 인수 테스트까지 적용 범위도 넓다. 입출력 관계가 명확한 기능은 자동화 테스트로 옮기기에도 수월하다.

입력 영역과 조건을 나누어 테스트 케이스를 설계한다

동등 분할(Equivalence Partitioning)

동등 분할은 입력 데이터를 유효 또는 무효한 동등 클래스로 분류하고, 각 클래스에서 대표값을 골라 검증하는 기법이다. 모든 값을 검사하지 않고도 입력 영역을 효율적으로 다룰 수 있다.

예를 들어 1-100 사이 숫자를 받는 기능이라면 유효 분할은 1-100 사이의 값이며, 대표값으로 50을 선택할 수 있다. 무효 분할에는 0 이하의 값과 100 초과의 값이 포함되며, 각각 -5와 150 같은 값을 사용할 수 있다.

경계값 분석(Boundary Value Analysis)

경계값 분석은 동등 분할을 확장해 분할의 경계에 놓인 값을 집중적으로 확인한다. 결함이 경계값에서 자주 발생한다는 경험적 사실을 바탕으로 한다.

1-100 범위 입력 기능이라면 0, 1, 99, 100, 101이 주요 검증 대상이 된다. 경계 바로 앞, 경계값, 경계 직후를 함께 확인하는 방식이다.

결정 테이블 테스트(Decision Table Testing)

여러 조건의 조합에 따라 다른 결과가 나오는 기능은 결정 테이블로 정리하는 편이 적합하다. 조건과 액션의 관계를 표로 만들고, 가능한 조합에서 필요한 테스트 케이스를 설계한다.

대출 승인 시스템에서는 신용점수, 소득, 기존 대출 여부가 조건이 될 수 있고, 대출 승인·거부·조건부 승인이 결과가 될 수 있다. 조건 조합을 먼저 식별한 뒤 예상 결과를 정의하면 누락된 규칙을 찾는 데도 도움이 된다.

상태 전이 테스트(State Transition Testing)

상태 전이 테스트는 시스템이 어떤 상태에 있으며, 특정 이벤트가 발생했을 때 어디로 이동하는지를 검증한다. 상태를 갖는 시스템에서 특히 유용하다.

ATM 로그인 프로세스를 예로 들면 상태는 대기, 카드 삽입, PIN 입력, 인증됨, 잠김으로 구분할 수 있다. 카드 삽입, PIN 입력, 취소 같은 이벤트와 잘못된 PIN 입력 1-2회, 잘못된 PIN 입력 3회 같은 전이 조건을 테스트 대상으로 삼는다.

⤢✕

유스케이스 테스트(Use Case Testing)

유스케이스 테스트는 사용자와 시스템의 상호작용 시나리오를 기준으로 케이스를 만든다. 온라인 쇼핑몰 주문이라면 상품 선택, 장바구니 담기, 결제, 주문 완료로 이어지는 기본 흐름을 검증한다. 상품 품절이나 결제 실패처럼 기본 흐름에서 벗어나는 대체 흐름도 함께 다룬다.

기능 검증에서 얻는 것과 놓치는 것

명세기반 테스트는 코드 구현 전에도 테스트 케이스를 설계할 수 있고, 요구사항 기반으로 케이스를 만들면서 기능 누락을 확인할 수 있다. 시스템 통합 테스트나 사용자 수용 테스트에도 잘 맞는다.

반면 모든 코드 경로를 확인할 수는 없다. 내부 로직의 결함을 찾는 데 비효율적일 수 있으며, 명세가 불완전하면 테스트 효과도 줄어든다. 복잡한 로직이나 알고리즘에는 한계가 있고, 조건 조합에 따라 테스트 케이스 수가 과도하게 많아질 수도 있다.

로그인과 송금 기능에 적용해 보기

웹 애플리케이션 로그인에서는 유효한 입력, 무효한 입력, 경계 조건을 구분해 검증할 수 있다. 올바른 사용자 ID와 비밀번호 입력 시 로그인 성공 여부를 확인하고, 잘못된 비밀번호나 존재하지 않는 사용자 ID에는 오류 메시지가 표시되는지 점검한다. 빈 ID 또는 비밀번호 필드의 유효성 검사 메시지, 최대 길이(예: 50자) ID의 처리, SQL 인젝션 문자열에 대한 적절한 방어 및 오류 처리도 테스트 범위가 된다.

송금 기능은 잔액과 일일 한도처럼 여러 조건이 결과를 함께 결정하므로 결정 테이블이 유용하다.

조건/액션	케이스1	케이스2	케이스3	케이스4
잔액 충분	Y	Y	N	N
일일 한도 이내	Y	N	Y	N
송금 성공	Y	N	N	N
한도 초과 오류	N	Y	N	N
잔액 부족 오류	N	N	Y	Y

명세에서 실행 결과까지 이어지는 흐름

테스트는 시스템 명세와 기능 요구사항 문서를 검토하는 데서 출발한다. 이후 기능 특성에 맞는 블랙박스 테스트 기법을 고르고, 그 기법으로 테스트 케이스를 작성한다. 각 케이스에 필요한 입력 데이터와 예상 결과를 준비한 다음 실행하며, 발견된 결함은 식별하고 문서화한다.

명세가 모호하면 좋은 케이스를 만들기 어렵다. 요구사항을 명확히 확보하고, 단일 기법에만 의존하기보다 여러 기법을 조합하는 편이 낫다. 중요도와 위험도에 따라 우선순위를 정하고, 반복되는 케이스는 자동화를 고려한다. 발견된 결함의 패턴을 다시 분석해 테스트 전략에 반영하는 피드백 루프도 필요하다.

애자일 환경에서는 사용자 스토리를 기반으로 케이스를 설계하고, 스프린트 단위로 기능 테스트 계획을 수립해 실행할 수 있다. CI 파이프라인에 블랙박스 테스트 자동화를 통합하는 방식도 가능하다. DevOps 흐름에서는 CD 과정에서 자동화된 테스트를 실행하고, 결과를 모니터링 시스템과 연동한다. 운영 환경에서 이슈가 발생하면 관련 블랙박스 테스트를 강화한다.

명세기반 테스트는 사용자에게 보이는 기능을 검증하는 데 강점이 있다. 동등 분할, 경계값 분석, 결정 테이블 같은 기법을 기능 특성에 맞춰 적용하고, 화이트박스 테스트와 보완적으로 사용하면 테스트 범위를 더 넓힐 수 있다.