통합테스트 시나리오 설계와 관리

1. 들어가며

설문 관리 서비스는 이용자가 온라인으로 설문에 응답하고, 담당 직원과 관리자가 그 결과를 확인·관리하는 서비스입니다. 겉보기에는 단순하지만 이용자·직원·관리자 등 역할별로 권한과 화면 흐름이 다르고, 회원 가입 여부에 따라 인증 방식도 여러 갈래로 나뉘며, 외부 연동 시스템과의 데이터 동기화까지 얽혀 있어 단위 기능의 정상 동작만으로는 서비스 전체의 품질을 보장하기 어려운 구조였습니다.

본 프로젝트에서 저는 QA 역할을 맡아, 요구사항 정의서를 기반으로 통합 테스트 시나리오를 직접 작성하고, 이를 개발(dev), 스테이징(stg), 운영(prod) 세 단계 환경을 거치며 실행하고 관리하는 업무를 수행하였습니다. 이 과정에서 최종적으로 71개의 테스트 시나리오(TS)와 376개의 세부 테스트 케이스(TC)로 구성된 통합 테스트 문서를 만들고 운영하게 되었습니다.

이 글에서는 단순히 '테스트를 진행했다'는 결과 보고에 그치지 않고, 왜 이러한 구조로 시나리오를 설계했는지, 어떤 기준으로 예외 케이스를 도출했는지, 문서를 어떻게 관리해야 오래도록 신뢰할 수 있는 자산이 되는지를 중심으로 경험을 정리합니다.

2. 통합 테스트 시나리오 설계가 필요했던 배경

프로젝트 초기에는 기능 단위의 단위 테스트로 각 API와 화면의 정상 동작을 검증하고 있었습니다. 그러나 회원 가입부터 본인 인증, 약관 동의, 병원 정보 연동까지 이어지는 흐름처럼 여러 화면과 API가 순차적으로 맞물리는 기능에서는, 각 단계가 개별적으로 정상이어도 전체 흐름에서 상태 값이 잘못 전달되거나 이전 단계의 예외 처리가 다음 단계에 영향을 주는 문제가 실제로 존재했습니다.

또한 이용자·직원·의료진·관리자 등 역할에 따라 같은 화면이라도 노출되는 정보와 가능한 동작이 달랐기 때문에, '이 역할이 이 화면에 접근했을 때 의도한 대로 제한되는가'와 같은 검증은 기능 단위 테스트로 대체할 수 없었습니다. 이에 요구사항 정의서의 개별 기능을 사용자 흐름 단위로 재구성한 통합 테스트 시나리오가 필요하다고 판단하였습니다.

시나리오를 별도로 설계한 실무적인 목적은 세 가지였습니다. 배포 전 회귀 테스트 범위를 명확히 정의하고, 신규 투입 인력이 문서만으로 서비스 전체 흐름을 이해할 수 있게 하며, 버그가 발생했을 때 어떤 시나리오와 케이스에서 재현되는지 추적할 기준점을 마련하는 것입니다.

3. 요구사항 정의서를 테스트 시나리오로 구조화하는 방법

요구사항 정의서는 보통 기능 단위로 정리되어 있습니다. 이를 그대로 테스트 항목으로 옮기면 하나의 케이스가 지나치게 방대해지거나, 반대로 지나치게 잘게 쪼개져 전체 흐름이 보이지 않는 문제가 발생합니다. 이를 해결하기 위해 시나리오 문서를 두 단계 구조로 설계하였습니다.

첫 번째 단계는 테스트 시나리오(TS, Test Scenario)입니다. TS는 이용자가 하나의 목적을 달성하기 위해 거치는 업무 흐름 전체를 하나의 단위로 묶은 것입니다. 예를 들어 '약관 동의 및 본인 인증'이라는 하나의 시나리오는 이름 입력, 휴대폰 인증, 인증번호 확인이라는 여러 단계를 포괄하는 하나의 목적 지향적 흐름으로 정의됩니다.

두 번째 단계는 테스트 케이스(TC, Test Case)입니다. TC는 하나의 시나리오 안에서 검증해야 하는 개별 조건을 의미합니다. 앞서 언급한 '약관 동의 및 본인 인증' 시나리오라면, 그 안에 이름 미입력 시 처리, 형식이 잘못된 휴대폰 번호 입력 시 처리, 인증번호 불일치 시 처리 등 여러 개의 케이스가 하위에 존재하게 됩니다.

이렇게 시나리오와 케이스를 분리한 구조는 실무에서 실질적인 이점을 주었습니다. 시나리오 목록만 훑으면 서비스 전체의 업무 흐름이 한눈에 파악되고, 실행은 케이스 단위로 진행 상황을 세밀하게 관리할 수 있으며, 버그가 발생했을 때 어느 시나리오의 어느 케이스인지 즉시 특정할 수 있어 개발팀과의 커뮤니케이션 비용도 크게 줄었습니다.

4. 두 개의 축으로 분류하기: 대상과 기능 영역

시나리오와 케이스의 수가 늘어날수록 단순한 목록 형태의 문서로는 관리가 어려워집니다. 71개의 시나리오와 376개의 케이스를 효율적으로 관리하기 위해, 모든 케이스에 두 가지 분류 축을 부여하였습니다.

첫 번째 축은 '대상'입니다. 이용자, 직원, 의료진, 관리자, 키오스크 등 실제로 해당 기능을 사용하는 역할을 기준으로 분류하였습니다. 동일한 기능이라 하더라도 역할에 따라 화면 구성과 접근 권한이 다르게 동작하기 때문에, 이 축을 분리하지 않으면 특정 역할에서만 발생하는 문제를 놓치기 쉬웠습니다.

두 번째 축은 '구분'으로, 인증, 서식, 설문, 통계 시각화, 마이페이지, 소통함, 대시보드, 메뉴, 관리 등 서비스의 기능 영역을 기준으로 분류하였습니다. 이 축은 개발팀이 특정 영역의 코드를 수정했을 때, 해당 영역에 속한 케이스만 골라 회귀 테스트를 수행할 수 있도록 하기 위한 목적으로 설계하였습니다.

이 두 축을 교차하면 '관리자 화면의 인증 관련 기능만 다시 검증'하거나 '이용자가 사용하는 모든 기능을 전수 검증'하는 식으로, 문서 전체를 검토하지 않고도 필요한 범위만 즉시 추출할 수 있었습니다. 배포 주기가 짧아 매번 376개 케이스를 전부 재실행하기 어려웠기에, 이러한 분류 체계는 회귀 테스트 범위를 합리적으로 좁히는 데 실질적으로 기여하였습니다.

5. Happy Path를 넘어서는 예외 케이스 도출

요구사항 정의서에는 대체로 정상적인 흐름, 즉 Happy Path가 명시되어 있습니다. 그러나 실제 서비스 운영 중 발생하는 문제의 상당수는 정상 흐름이 아니라 그 주변의 예외 상황에서 발생합니다. 요구사항을 문자 그대로 옮기는 것만으로는 이러한 예외 케이스를 빠짐없이 도출하기 어렵기 때문에, 시나리오를 작성할 때마다 다음 네 가지 검증 패턴을 반복적으로 적용하는 방식을 사용하였습니다.

• 필수값 검증: 입력이 필요한 항목이 비어있는 상태로 다음 단계를 시도하는 경우

• 형식 검증: 정해진 형식(자릿수, 허용 문자 등)을 벗어난 값을 입력하는 경우

• 상태 기반 검증: 이미 존재하거나 중복되는 상태, 또는 값이 서로 일치하지 않는 경우

• 정책성 검증: 제한 시간 초과, 시도 횟수 제한 등 정책에 의해 흐름이 달라지는 경우

아래 표는 실제로 이 네 가지 패턴을 인증 관련 시나리오에 적용한 예시를 정리한 것입니다.

예를 들어 요구사항 정의서에는 단순히 '휴대폰 인증번호를 입력받아 인증을 처리한다'는 한 줄로 기술되어 있었지만, 위 패턴을 대입해보면 실제로는 인증번호 미입력, 형식 오류, 불일치, 유효시간 초과, 시도 횟수 초과 등 다섯 개 안팎의 케이스가 파생되었습니다. 이처럼 요구사항 문서에 명시적으로 드러나지 않은 케이스를 QA 관점에서 선제적으로 도출하는 작업이, 시나리오 작성 과정에서 가장 많은 시간과 주의를 기울인 부분이었습니다.

6. dev, stg, prod 환경별 테스트 전략

작성된 시나리오는 개발(dev), 스테이징(stg), 운영(prod) 세 단계 환경을 거치며 실행하였습니다. 세 환경은 목적이 서로 달랐기 때문에, 동일한 케이스라 하더라도 환경에 따라 검증하는 관점을 다르게 가져갔습니다.

dev 환경에서는 통제된 테스트 데이터로 기능이 요구사항대로 구현되었는지, 즉 로직 자체의 정합성을 빠르게 반복 검증하였습니다. stg 환경에서는 운영과 유사한 조건에서 외부 연동 시스템과의 데이터 동기화, 권한 체계를 재검증하였는데, 외부 시스템과의 처리 순서나 응답 지연 관련 이슈는 대부분 이 단계에서 드러났습니다.

prod 환경에서는 배포 직후 핵심 흐름과 이번 배포에서 변경된 영역만 확인하는 스모크 테스트로 검증 범위를 최소화하였습니다. 이렇게 환경별로 목적과 범위를 다르게 설정한 덕분에, 동일한 시나리오 문서를 재사용하면서도 테스트 리소스를 효율적으로 배분할 수 있었습니다.

7. 테스트 결과를 기록하는 원칙

테스트를 진행하다 보면 모든 케이스가 성공 또는 실패로 명확하게 나뉘지 않는 경우가 자주 발생합니다. 외부 시스템의 대응이 선행되어야 검증이 가능한 경우, 또는 정책상 검증 대상에서 제외해야 하는 경우가 실제로 다수 존재하였습니다. 이러한 상황을 단순히 실패로 기록하면 추후 이 기록을 참고하는 사람이 문제의 원인을 오해할 수 있기 때문에, 결과를 다음과 같이 네 가지로 구분하여 기록하는 원칙을 세웠습니다.

특히 ABORTED와 BLOCKED로 기록한 케이스에는 반드시 비고란에 구체적인 사유를 남겼습니다. 예를 들어 특정 알림 기능은 외부 시스템의 변경 알림 수신과 조회 API 호출이 하나의 트랜잭션으로 처리되면 정확한 결과를 보장할 수 없다는 점이 확인되어, 로직 분리가 선행된 후 재검증하기로 하였습니다. 이를 단순히 '실패'로 남기지 않고 BLOCKED로 분류한 뒤 원인과 재검증 조건을 함께 기록해 둔 덕분에, 이후 로직이 분리된 시점에 해당 케이스만 정확히 찾아 재실행할 수 있었습니다.

이와 함께 고객사 시스템의 화면이 서비스 안에 임베딩되어 제공되는 영역처럼, 검증과 수정의 주체가 프로젝트 내부에 있지 않은 기능들도 존재하였습니다. 이러한 영역에서 오류가 발견되면 자사에서 직접 수정할 수 없기 때문에, 해당 화면의 담당자를 특정하여 재현 조건과 함께 수정을 요청하고, 반영이 확인된 후 해당 케이스만 재실행하여 결과를 갱신하는 방식으로 처리하였습니다. FAIL로 기록된 케이스들 역시 대부분 담당 개발자에게 전달하고, 수정 배포 후 동일한 TC_ID로 재검증하는 흐름을 반복하며 소거해 나갔는데, 이 과정에서 앞서 정리한 ID 체계와 결과 분류 원칙이 조직 간 커뮤니케이션의 기준점으로 유효하게 작동하는 것을 확인할 수 있었습니다.

8. 시나리오 문서의 식별자(ID) 관리 원칙

케이스 수가 많아질수록 각 케이스를 식별하는 ID 체계가 문서 전체의 신뢰도를 좌우한다는 것을 실무를 통해 체감하였습니다. 시나리오에는 TS_ID를, 케이스에는 TC_ID를 순차적으로 부여하였는데, 이 ID는 시나리오 문서 안에서만 쓰이는 것이 아니라 버그 리포트, 회귀 테스트 결과표, 배포 체크리스트 등 여러 산출물에서 반복적으로 참조되었습니다.

이 과정에서 지켰던 가장 중요한 원칙은 '한 번 부여된 ID는 검증하려는 조건 자체가 바뀌지 않는 이상 내용을 덮어쓰지 않는다'는 것이었습니다. 만약 특정 케이스의 검증 목적이 완전히 달라지는 경우, 기존 ID의 내용을 수정하는 대신 기존 ID는 폐기 처리하고 새로운 ID를 발급하여 별도의 케이스로 추가하는 방식을 택하였습니다. 오탈자 수정이나 표현을 다듬는 수준의 경미한 변경은 동일한 ID를 유지한 채 수정하였지만, 검증 조건이나 기대 결과 자체가 바뀌는 경우에는 예외 없이 새 ID를 부여하였습니다.

이러한 원칙을 지킨 이유는, ID가 단순한 번호가 아니라 특정 시점의 테스트 이력을 가리키는 참조점이기 때문입니다. 만약 같은 ID 아래 내용을 완전히 다른 케이스로 바꾸어 버리면, 과거에 그 ID를 인용하여 남긴 버그 리포트나 실행 이력이 실제로는 다른 내용을 가리키게 되어 혼선이 발생합니다. 이는 데이터베이스 스키마 변경이나 API 버전 관리에서 기존 버전을 그대로 둔 채 새 버전을 추가하는 방식과 동일한 원리라고 할 수 있습니다. 아울러 한 번 폐기된 ID는 이후에도 재사용하지 않는 것을 함께 원칙으로 삼아, 문서의 이력을 시간 순서대로 온전히 보존할 수 있도록 하였습니다.

9. 적용 결과 및 회고

이상의 원칙을 바탕으로 71개의 시나리오와 376개의 테스트 케이스로 구성된 통합 테스트 문서를 완성하고, dev, stg, prod 세 환경에서 순차적으로 실행하였습니다. 대다수 케이스는 정상 통과하였고, 일부는 외부 시스템 연동이나 환경상의 제약으로 ABORTED 또는 BLOCKED로 분류되어 별도 관리 대상으로 남았습니다.

가장 큰 배움은, 통합 테스트 시나리오 작성에서 정말 많은 시간이 필요한 일은 요구사항 정의서를 읽는 것이 아니라 문서에 명시되지 않은 예외 상황을 찾아내는 것이라는 점입니다. 네 가지 검증 패턴을 기계적으로 대입하는 습관, 그리고 ID 관리나 결과 분류처럼 사소해 보이는 규칙이 케이스가 수백 개로 늘어나는 시점부터 문서 전체의 신뢰도를 지탱한다는 것도 실무를 통해 확인하였습니다.

앞으로 유사한 규모의 프로젝트를 맡게 된다면, 이번에 정립한 시나리오 설계 원칙과 문서 관리 규칙을 프로젝트 초기부터 팀 전체가 공유할 수 있는 형태로 문서화하고, 반복 실행되는 회귀 테스트 중 자동화 가능한 영역을 선별하여 수동 테스트 리소스를 예외 케이스 발굴처럼 사람의 판단이 중요한 영역에 집중하면 좋을 것이라 생각합니다.

eunice