34장. 요구사항에서 시험으로

요구와 설계 후보에서 수용 조건과 시험 판정 기준을 만들고 미정 정책을 시험이 몰래 확정하지 않게 한다.

이번 장에서 해결할 질문

학습 목표

• “요구사항의 수용 기준을 실행 가능한 시험 조건으로 어떻게 전환하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

요구사항이 시험으로 이어지지 않으면 ‘완료’의 의미는 구현자의 판단에 남는다. 요구 문장을 그대로 시험 절차로 복사해서는 조건·입력·관찰 지점과 기대 결과가 충분히 드러나지 않으며, 정상 사례만 확인하면 경계와 실패 책임을 검증할 수 없다.

이 장에서는 요구사항에서 수용 기준과 시험 조건·데이터·기대 결과를 도출한다. 기능·품질·데이터·인터페이스 요구에 맞는 검증 방법을 선택하고 요구 버전과 시험을 추적해, 누락된 요구와 시험 불가능한 표현을 개발 전에 되돌려 찾는 방법을 살펴본다.

1. 수용 기준

시험으로의 전환은 요구사항 문장 끝에 “정상 동작해야 한다”를 붙이는 일이 아니다. 이해관계자가 필요를 충족했다고 판단할 관찰 가능한 조건을 정하고, 그 조건을 어떤 환경·데이터·절차·판정 근거로 확인할지 연결하는 일이다. 요구사항이 불명확하면 시험은 그 불명확성을 그대로 물려받는다.

수용 기준은 요구사항과 시험 케이스 사이의 계약이다. 요구사항보다 임의로 범위를 넓히지 않고, 구현 절차를 과도하게 고정하지 않으며, 성공·경계·실패에서 관찰할 결과를 분명히 한다. 실제 승인 기준선이 없는 이 사례에서 아래 AC와 TC 식별자는 모두 교육용 후보다. 시험을 통과했다는 결과도 아니고 이해관계자가 수용했다는 뜻도 아니다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 후보 수용 기준을 예로 들면 다음과 같다.

좋은 수용 기준은 화면 문구나 데이터베이스 열에만 묶이지 않는다. “초록색 성공 배너가 나온다”보다 “신청 ID와 접수 상태가 색상에만 의존하지 않고 제공된다”가 사용자 결과와 접근성에 가깝다. “HTTP 200”만으로는 업무 승인 여부를 알 수 없다. 반대로 구현 독립성을 이유로 관찰 지점을 전혀 쓰지 않으면 시험할 수 없다.

품질 요구에도 수용 기준이 필요하다. QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 상태 조회 p95 2초 후보는 동시 사용자 수, 데이터량, 요청 분포, 측정 시작·종료 지점, 준비·측정 시간, 캐시 조건, 오류율을 함께 정해야 한다. QR-003QR-003 · 품질 요구동시 신청 경쟁.의 신뢰성은 중복·응답 유실·프로세스 재시작 중 복수 승인이나 좌석 불일치가 없다는 조건으로 내릴 수 있다. 수치와 환경이 확인되기 전에는 통과 기준으로 표시하지 않는다.

수용 기준 검토에서 “확인할 수 없다”는 결론도 가치가 있다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.의 졸업 예정자 우선권은 대상 정의, 동률 처리, 적용 시점, 공개 사유와 좌석 정책이 미결이다. 따라서 우선 배정의 예상 결과를 시험 기준으로 확정할 수 없다. 이 공백은 개발팀이 임의로 채우지 않고 정책 결정 요청으로 되돌린다.

2. 시험 조건

시험 조건은 무엇을 검사할지 범주와 변수를 정한 상위 항목이다. 아직 상세 단계나 입력값을 모두 쓰지 않아도 요구의 위험 공간이 빠짐없이 포함됐는지 검토할 수 있다. ISO/IEC/IEEE 29119-2은 생명주기 모델과 무관하게 적용할 수 있는 일반 시험 프로세스를 다룬다. 프로젝트는 표준 이름을 붙이는 데 그치지 않고 계획·모니터링·설계·구현·실행·완료의 증거를 실제 산출물로 연결한다.

수강신청의 시험 조건 후보는 다음 범주로 나눈다.

경계값은 숫자 양옆만 고르는 것이 아니다. 신청 기간 종료와 서버 시간, 학기 전환, 규칙 버전 교체 중 처리, 취소와 승인 순서, 오래된 화면에서 제출하는 순간이 시간·상태 경계다. 개인정보 마스킹이 운영 로그에서는 되지만 메시지 큐의 실패 보관소에서는 빠지는지처럼 데이터 흐름 경계도 본다.

조합 수가 커지면 모든 경우를 무작정 곱하지 않는다. 위험 기반으로 우선순위를 정하고 동등 분할, 경계값 분석, 결정표, 상태 전이, 쌍대 조합을 선택한다. 규칙의 상호작용이 핵심인 선수과목·학점·시간·좌석은 결정표가 유용하고, 접수에서 취소까지는 상태 전이 시험이 적합하다. 적용 기법과 제외한 조합의 근거를 기록한다.

시험 조건에는 시험 가능성도 포함한다. 규칙 버전을 조회할 방법, 시간을 통제할 수 있는 환경, 중복 요청 ID 주입, 외부 응답 지연·무효화, 동시 요청 생성, 감사 기록 열람과 개인정보가 제거된 증거 수집이 필요하다. 관찰 지점이 없으면 통과 여부가 아니라 추측만 남는다. 필요한 시험용 제어 지점(테스트 훅)은 운영 보안을 약화하지 않도록 인증·환경 제한과 감사 조건을 둔다.

운영 데이터의 무단 복사는 시험 준비가 아니다. 최소화·익명화·합성 데이터를 우선하고, 실제 분포가 중요한 성능 시험은 승인된 생성·마스킹 절차와 보존 기간을 사용한다. 시험 계정도 학생·담당자·운영자 역할을 분리하고 사용 뒤 정리한다.

3. 시험 시나리오

시험 시나리오는 사용자 또는 시스템 관점의 의미 있는 흐름을 처음부터 결과까지 잇는다. 화면 하나의 기능 확인보다 여러 책임 경계가 함께 작동할 때의 결과를 검증한다. 정상 흐름만 쓰지 않고 대체·예외·회복 흐름을 같은 수준으로 관리한다.

SCN-ENR-01SCN-ENR-01 · 시나리오정상 신청 후보. 정상 신청 후보:

이 시나리오는 버튼 클릭 성공이 아니라 접수와 판정의 구분, 데이터 기준선, 상태 조회와 감사 이력을 함께 관찰한다. 알림을 받더라도 공식 결과는 상태 조회에서 확인한다.

주요 대체·예외 시나리오 후보:

VAL-SCN-01VAL-SCN-01 · 확인 시나리오보류의 사용자·운영 적합성 확인.은 학생·담당자가 보류 상태와 다음 행동을 이해하는지 확인하는 검증 시나리오다. SCN-TIMEOUT-01SCN-TIMEOUT-01 · 시나리오규칙 연계가 제한 시간을 초과.과 같은 장애를 쓰더라도 목적이 다르다. 전자는 사용자 필요와 운영 절차가 적합한지 확인하고, 후자는 명세대로 안전하게 처리했는지 검증한다. 둘의 결과를 한 칸의 “통과”로 합치지 않는다.

시나리오는 시작 상태와 종료 상태를 명시한다. 시험 뒤 남은 신청·좌석·보류·알림 기록을 정리하거나 다음 시험의 전제로 사용한다. 서로 독립이라고 가정한 시험이 동일 좌석을 공유하면 재현성이 떨어진다. 시각·규칙 버전·외부 응답을 고정할 수 없는 요소는 실행 기록에 남긴다.

우선순위 배정 시나리오는 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.이 승인되기 전에는 예상 승자를 정할 수 없다. 지금 가능한 시험은 미승인 규칙이 운영 결과에 적용되지 않는지, 정책 플래그가 있다면 기본 상태가 무엇인지 확인하는 수준이다. 정책을 테스트가 창작해서는 안 된다.

4. 시험 케이스

시험 케이스는 조건과 시나리오를 반복 실행 가능한 입력·절차·예상 결과로 구체화한다. 테스트 자동화 코드와 동일하지 않으며, 판정 근거를 사람이 검토할 수 있을 만큼 명확해야 한다. ISTQB CTFL v4.0.1이 다루는 기본 원칙과 기법도 시험이 요구를 모두 증명한다거나 결함이 없음을 보장한다는 오해를 경계하는 데 유용하다.

TC-IR-001-01TC-IR-001-01 · 시험 항목규칙 연계의 실패·무효·시간 초과·늦은 응답에서 자동 승인 없이 원인 있는 보류와 이력이 남는지 확인하는 시험 후보다. 후보를 상세화하면 다음과 같다.

예상 결과는 “에러 메시지가 뜬다”가 아니라 각 관찰 지점의 일관성을 쓴다. 화면은 보류인데 데이터가 승인이라면 실패다. API가 시간 초과됐어도 신청 ID로 조회했을 때 기존 접수가 일관되게 나오면 응답 유실 회복은 성공할 수 있다. 오류 코드 하나만 보고 전체 시험을 통과시키지 않는다.

동시성 시험 TC-CAP-001-01TC-CAP-001-01 · 시험 항목마지막 좌석에 여러 신청이 동시에 들어와도 정원 초과와 복수 승인이 생기지 않는지 확인하는 시험 후보다.은 두 요청을 순서대로 보내서는 목적을 달성하지 못한다. 같은 상태에서 실제로 겹치는 실행을 만들고, 결과뿐 아니라 좌석·신청·결정·감사 데이터를 대사한다. 어떤 학생이 승인돼야 하는지는 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.와 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.이 해결된 뒤 정한다. 현재 RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.로 확인할 수 있는 불변조건은 수용량을 초과하는 승인 없음과 각 결과에 설명 가능한 근거가 있다는 것이다.

중복 시험 TC-DUP-001-01TC-DUP-001-01 · 시험 항목같은 신청 의도가 반복되거나 응답이 유실돼도 기존 신청에 연결되고 중복 처리가 생기지 않는지 확인하는 시험 후보다.은 같은 키·같은 내용, 같은 키·다른 내용, 다른 키·같은 사용자 조작을 분리한다. 첫 경우는 기존 결과를 재사용할 수 있지만, 두 번째는 충돌로 거절해야 할 수 있고, 세 번째는 업무상 중복 판별 정책이 필요하다. “멱등성 테스트” 한 줄로 이 차이를 숨기지 않는다.

시험 결과 기록에는 케이스·요구 버전, 빌드·설정, 환경, 데이터 세트, 외부 모의 응답, 실행 시각·주체, 실제 결과, 판정, 결함 링크와 증거 위치를 남긴다. 자동화가 통과해도 증거의 버전과 환경이 다르면 수용 근거로 재사용하지 않는다. 실패를 재실행해 통과시켰다면 최초 실패 원인과 수정·변경 내용을 보존한다.

5. 요구사항 기반 시험

요구사항 기반 시험은 요구 목록마다 케이스 하나를 만드는 방식이 아니다. 각 요구의 의도·위험·수용 기준을 조건과 시나리오로 내려가고, 반대로 모든 시험이 어떤 필요를 확인하는지 설명하는 양방향 추적이다. 테스트가 없는 요구와 요구가 없는 테스트를 모두 찾는다.

핵심 추적표 후보:

REQ → Feature → Flow → Screen → API → Data → TC의 전체 사슬을 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.으로 확인하면 다음과 같다.

TC-FR-003-01TC-FR-003-01 · 시험 항목정상·보류·거절·인가 결과 확인.이 실패했을 때 화면만 수정할지 결정하기 전에 사슬을 거슬러 올라간다. API가 사유를 제공하지 않는지, 데이터가 규칙 버전을 저장하지 않는지, 기능 책임에서 보류 상태를 누락했는지 확인한다. 반대로 DATA-DECISION-01DATA-DECISION-01 · 데이터 설계학적 기준·우선 근거 재현.의 필드를 삭제하려면 어느 화면·API·시험과 상위 요구가 영향을 받는지 순방향으로 찾는다.

추적률을 숫자 하나로 보고하지 않는다. 모든 요구에 아무 케이스나 연결하면 100%가 되지만 경계·실패·품질 위험은 비어 있을 수 있다. 수용 기준별 정상·대체·예외·품질 조건의 깊이, 미결 요구, 실행되지 않은 케이스와 실패 상태를 함께 본다. 자동화 비율도 품질의 대용 지표가 아니다.

시험에서 새로운 요구가 발견되면 시험 케이스 안에 몰래 넣지 않는다. 예를 들어 보류가 24시간을 넘으면 자동 거절해야 한다는 예상이 생겼다면 근거·영향·책임자를 가진 변경 후보로 올린다. 승인 전에는 예상 결과를 “자동 거절”로 고정하지 않는다.

6. 회귀 시험

회귀 시험은 과거 케이스를 전부 다시 실행하는 행위가 아니라 변경이 기존 능력과 불변조건을 깨뜨리지 않았다는 위험 기반 증거를 만드는 활동이다. 요구-설계-시험 추적은 회귀 범위를 고르는 영향 지도다.

CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.이 졸업 예정자 우선 배정을 제안한다고 가정하면 영향은 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다. 하나에 머물지 않으며 RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 수용량 불변조건도 다시 검증해야 한다.

정책이 승인되기 전에는 이 사슬이 변경 영향 후보다. 승인 후에는 새 우선권 대상뿐 아니라 비대상 학생, 기존 선착순 또는 추첨 규칙, 좌석 초과 방지, 개인정보 공개와 운영 재처리를 회귀 범위에 포함한다. 오래된 신청에 새 규칙을 소급할지, 처리 중 요청은 어느 버전으로 끝낼지도 시험한다.

회귀 묶음은 위험과 속도로 계층화할 수 있다.

실패한 회귀를 “불안정한 테스트”로 분류해 제외하기 전에 제품 결함, 환경 경합, 시간 의존성과 시험 데이터 누출을 조사한다. 반복 불안정 자체가 동시성·관찰 가능성 문제의 신호일 수 있다. 제외에는 소유자, 위험, 복구 기한과 대체 통제를 둔다.

데이터·스키마 변경은 앞뒤 호환 구간을 시험한다. 구버전 애플리케이션과 신버전 데이터, 부분 배포, 롤백, 백필 중 조회와 쓰기를 확인한다. 마이그레이션 성공 메시지보다 건수·합계·중복·누락 대사와 표본 판정 재현이 중요하다. DR-006DR-006 · 데이터 요구이관 전후 건수·관계·핵심 값과 이력을 대사할 수 있게 한다의 실제 이관 범위가 확인되기 전에는 샘플 결과를 운영 보장으로 확대하지 않는다.

7. 사용자 인수시험

사용자 인수시험은 개발 시험의 마지막 체크박스가 아니라 의도한 사용자가 실제 업무 맥락에서 해결책을 받아들일 수 있는지 확인하는 활동이다. 시스템이 명세대로 작동하는지 검증하는 일과, 그 명세·설계가 현장의 필요에 맞는지 검증하는 일을 함께 보되 판정을 구분한다.

참여자는 학생 한 유형으로 끝내지 않는다. 일반 재학생, 규칙 경계에 있는 학생, 접근성 요구가 있는 학생, 학사 담당자, 지원·운영 담당자와 정책 책임자의 대표성이 필요하다. 누가 최종 수용 권한을 갖는지, 자문과 승인 역할을 구분한다. 개인정보가 있는 실제 사례는 적법한 절차 없이 사용하지 않는다.

UAT 후보 과업은 다음과 같다.

1. 자신의 조건에 맞는 강좌를 찾고 정보의 기준 시점을 설명한다.
2. 신청을 제출한 뒤 접수와 승인의 차이를 말하고 다시 상태를 찾는다.
3. 선수과목 거절 사유를 이해하고 가능한 다음 행동을 선택한다.
4. 규칙 장애로 보류된 신청에서 자동 승인되지 않았음을 이해하고 조회·문의 경로를 사용한다.
5. 허용 상태의 신청을 취소하고 경합 결과를 확인한다.
6. 담당자가 보류 사례를 근거와 감사 이력을 남기며 처리한다.

관찰 항목은 과업 완료, 시간, 오류·되돌림, 이해한 상태와 사유, 지원 요청, 접근 장벽과 신뢰다. 참가자가 침묵했다고 성공으로 보지 않고 자신의 말로 결과와 다음 행동을 설명하게 한다. 화면낭독기·키보드·확대 환경은 별도 부록이 아니라 같은 핵심 과업으로 수행한다.

UAT는 성능·보안·복구 시험을 대신하지 않는다. 소수 사용자가 빠르게 느꼈다고 p95 목표가 입증되지 않고, 화면에서 다른 학생 버튼이 보이지 않는다고 객체 수준 인가가 검증되지 않는다. 반대로 자동 시험이 모두 통과해도 사용자가 보류를 대기명단으로 오해하면 요구나 용어 설계를 다시 검토해야 한다.

운영 인수에는 모니터링과 대응도 포함한다. 담당자가 접수 급감, 규칙 시간 초과, 보류 적체, 알림 실패, 좌석 대사 불일치를 구분할 수 있는지, 누가 어떤 권한으로 재처리하며 근거를 남기는지, 복구 뒤 사용자에게 무엇을 안내하는지 리허설한다. 문서·연락망·대시보드가 실제 환경과 같은 버전인지 확인한다.

인수 결과는 단순 서명보다 근거를 남긴다. 실행한 요구·시나리오와 버전, 참여 역할, 환경·데이터, 관찰 결과, 미해결 결함·위험, 조건부 수용 조건, 결정자와 날짜를 기록한다. 교육용 사례에서는 실제 결정자가 없으므로 “수용 완료”라고 표시하지 않고 검토 질문과 필요한 증거를 산출물로 남긴다.

이 장에서 정리한 결과는 요구사항-수용 기준-시험 추적표, 시험 조건 목록, 정상·대체·예외 시나리오, 재현 가능한 시험 케이스, 회귀 영향표, UAT·운영 인수 기록 틀이다. 시험은 요구사항 작업의 끝이 아니라 앞 단계의 모호함과 누락을 발견해 다시 요구·기능·화면·설계로 돌려보내는 피드백 고리다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로