테스트 기획·계획·분석·설계

1. 테스트 케이스를 많이 쓰면 테스트가 잘 설계된 것일까

요구가 100개인데 테스트 케이스가 1,000개라고 하자. 숫자는 많지만 가장 위험한 결제 실패와 권한오류가 빠져 있다면 테스트는 충분하지 않다. 테스트 공학은 케이스 수를 늘리는 일이 아니라 품질위험을 목표·범위·전략·자원·조건·케이스·데이터로 추적 가능하게 바꾸는 과정이다.

구현 증거가 테스트 입력이 된다

코딩·의존성·빌드·패키징·API 구현은 소스·의존성·빌드·패키지·API 계약과 실패경로를 구현증거로 남겼다. 테스트는 이 계약과 산출물을 대상으로 요구와 위험을 검증 가능한 조건으로 바꾼다.

요구와 검증·확인 질문을 함께 가져온다

요구사항 공학 장에서 모호한 표현을 관찰 가능한 조건으로 바꾸고 우선순위와 추적성을 유지했다. 검증·확인·운영 피드백에서는 명세대로 만들었는지를 묻는 검증과 실제 필요를 만족하는지를 묻는 확인을 서로 다른 질문으로 구분했다. 테스트 분석은 이 요구와 검증·확인 질문을 정상·경계·실패 조건으로 펼친다.

테스트 공학의 담당 경계

테스트 공학은 품질목표와 위험을 바탕으로 테스트의 목적·범위·전략·자원·일정을 기획·계획하고, 요구와 위험에서 테스트조건을 분석하여 케이스·데이터·절차로 설계하는 활동이다.

이번 절은 무엇을 왜 어떻게 시험할지 준비하는 단계다. 실제 실행수준·자동화·결함·커버리지·종료결과의 관리는 다음 절들이 담당한다.

위험에서 테스트 케이스까지 내려가는 흐름

품질목표·제품위험을 공통 입력으로 삼고 다음 네 활동의 질문을 구별한다.

질문을 섞으면 일정표는 있는데 왜 시험하는지 없거나, 케이스는 있는데 어떤 위험을 다루는지 알 수 없게 된다. 이 표는 반드시 한 번씩 순서대로 끝내는 공식 네 단계가 아니다. 케이스를 설계하다 요구의 누락을 발견하면 분석과 요구 확인으로 돌아가고, 환경이 늦어지면 계획을 조정한다. 진행 상황과 위험을 계속 관찰하고 필요한 조치를 내리는 모니터링·통제는 이 활동들 전체에 걸친다.

2. 테스트 기획은 목적·정책·전략·범위를 정한다

제품의 품질목표, 이해관계자, 실패비용, 규제·보안·성능 요구를 보고 어떤 수준의 증거가 필요한지 정한다. 명세대로 구현됐는지를 확인할 검증 증거와 실제 사용 목적을 만족하는지 판단할 확인 증거를 구분한다. 모든 기능을 동일한 깊이로 시험하기보다 위험과 중요도에 맞춰 전략을 선택한다.

기획에서 답할 질문

위험기반 우선순위는 단순 숫자가 아니라 판단 근거다

영향도와 발생가능성을 곱해 간단한 위험점수를 만들 수 있지만 그 공식 자체가 표준 정답은 아니다. 법적 의무·안전·복구불가 같은 위험은 단순 점수보다 우선할 수 있다. 점수와 함께 근거와 예외를 남긴다.

TP-1: 같은 6점이어도 우선순위가 다를 수 있다

가상 위험 A는 영향 3×가능성 2=6, B는 영향 2×가능성 3=6이라고 하자. A가 개인정보 영구유출이고 B가 화면 정렬오류라면 동일 점수만으로 같은 우선순위를 줄 수 없다. 영향의 성격·법적 의무·복구가능성을 함께 본다.

3. 테스트 계획은 실행 가능하도록 사람·시간·환경을 배치한다

계획에는 담당역할, 일정, 추정공수, 테스트환경, 도구, 테스트데이터, 진입·종료기준, 보고주기, 결함흐름, 의존팀과 위험대응을 포함한다. “테스트 2주” 한 줄은 계획이 아니다.

운영환경과 다른 테스트환경의 차이를 숨기지 않는다

테스트 DB가 작고 네트워크 지연이 없으며 외부서비스가 모의객체라면 기능검증에는 쓸 수 있어도 실제 부하·타임아웃·복구 특성을 그대로 대표하지 않는다. 환경차이를 기록하고 어떤 위험을 별도 시험할지 정한다.

진입기준과 종료기준을 다르게 본다

종료기준에는 합의한 품질 증거·잔여 위험과 시간·예산 조건이 포함될 수 있다. 일정이나 예산 때문에 시험을 끝냈다는 사실을 품질 기준 통과로 바꾸지 않는다. 미충족 기준·남은 위험·종료 결정은 결과·결함·커버리지·종료기준 관리에서 구별해 기록한다.

4. 테스트 분석은 요구와 위험을 테스트조건으로 바꾼다

테스트조건은 시험해야 할 기능·품질특성·상태·규칙·실패경로다. 요구사항, 사용자 흐름, 아키텍처, 인터페이스, 위험목록, 결함이력에서 조건을 도출한다.

요구를 정상·경계·오류·상태 변화로 펼친다

“나이는 18~65만 가입 가능”이라는 요구에서 정상값 18~65, 경계 바로 밖 17·66, 비정상 형식, 누락을 테스트조건으로 만든다. 단순히 대표값 30만 넣고 요구를 검증했다고 하지 않는다.

TA-1: 경계값 17·18·65·66

허용범위가 [18,65]이면 최소한 경계 바로 아래 17, 하한 18, 상한 65, 바로 위 66을 확인한다. 18과 65만 시험하면 거부경계가 올바른지 알 수 없다.

구현코드를 보고 테스트조건을 그대로 베끼지 않는다

개발자가 if age >= 18 && age <= 65라고 구현했다고 해서 그 조건을 요구의 정답으로 가정하면 같은 오류를 테스트에도 복제할 수 있다. 테스트조건은 요구·규칙·위험에서 독립적으로 도출하고 구현과 대조한다.

커버리지 모델은 무엇을 덮었는지 설명한다

요구사항 커버리지, 위험 커버리지, 상태·전이, 입력 동등분할·경계, 결정규칙 등을 사용할 수 있다. 케이스 수만 세지 않고 어떤 모델의 어떤 요소를 확인했는지 분모를 정한다.

TA-2: 요구 10개 중 8개를 시험했다고 80% 품질이 아니다

추적표에서 10개 요구 중 8개에 테스트가 연결되면 요구 연결 커버리지는 80%라고 말할 수 있다. 그러나 그 8개 테스트의 깊이와 통과여부, 빠진 2개의 위험도가 다르므로 제품 품질 80%라고 바꾸지 않는다.

5. 테스트 설계는 조건을 실행 가능한 케이스·데이터·기대결과로 바꾼다

각 케이스는 사전상태, 입력·행동, 기대결과, 후속상태와 필요한 데이터·환경을 갖는다. 결과를 사람이 그때 보고 판단하는 문장보다 판정 가능한 기대값을 쓴다.

대표 테스트 설계기법

TD-1: 결정표로 할인규칙 누락을 찾는다

회원 여부와 쿠폰 여부 두 조건이 각각 참/거짓이면 기본 조합은 4개다. 교육용 요구를 ‘회원이면 10% 할인, 유효 쿠폰이면 2000원 할인, 둘 다 해당하면 더 큰 할인 하나만 적용’으로 먼저 정한다. 주문금액 10000원·다른 할인 없음·쿠폰 입력은 유효함을 가정한다.

회원·쿠폰이 모두 O일 때 7000원이라고 답하면 ‘큰 할인 하나’ 요구를 중복 합산으로 바꾼 것이다. 이 기대값은 구현 결과를 복사하지 않고 요구에서 계산한다. 금액·쿠폰 유효성·중복 규칙이 바뀌면 조건과 기대값도 다시 설계한다.

TS-1: 성공 초기화와 잠금 유지 · 상태 따라가기

인증 시도 전 실패 수는 0이고 잠기지 않았다. 모든 단계에서 실패 수·잠금 상태의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

정상과 실패 상태의 성공은 실패 횟수를 초기화한다. 잠금 뒤에는 올바른 비밀번호를 입력해도 관리자 해제 전까지 거부한다. 관리자 해제 자체의 세부 절차는 이 로그인 입력 전이와 분리하여 계약에서 확인한다.

이 예의 조건

• 정상과 실패 상태의 성공은 실패 횟수를 초기화한다. 잠금 뒤에는 올바른 비밀번호를 입력해도 관리자 해제 전까지 거부한다. 관리자 해제 자체의 세부 절차는 이 로그인 입력 전이와 분리하여 계약에서 확인한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원래 그림의 모든 대상과 설명

대상	원래 설명
대상정상	원래 설명실패 횟수 0
대상실패 1	원래 설명다음 실패를 구분
대상실패 2	원래 설명다음 실패는 잠금
대상잠금	원래 설명관리자 해제 전 거부

원래 그림의 모든 관계와 조건

연결	원래 라벨·방향
연결정상 → 실패 1	원래 라벨·방향실패 / 정방향 / 실선
연결실패 1 → 실패 2	원래 라벨·방향실패 / 정방향 / 실선
연결실패 2 → 잠금	원래 라벨·방향실패 / 정방향 / 실선
연결실패 1 → 정상	원래 라벨·방향성공·초기화 / 정방향 / 실선
연결실패 2 → 정상	원래 라벨·방향성공·초기화 / 정방향 / 실선
연결잠금 → 잠금	원래 라벨·방향로그인 거부 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
정상 0 인증 시도 전 실패 수는 0이고 잠기지 않았다.	값·보충 정보 실패 수: count0 잠금 상태: 정상	변화·이유 현재 잠금 상태를 먼저 대조한다.
실패 1·2 실패하면 실패 횟수가 늘어나고 잠기기 전 성공하면 0으로 되돌아간다.	값·보충 정보 실패 수: 실패 1→2 / 성공 0 잠금 상태: 아직 정상	변화·이유 성공과 실패의 다른 갱신 규칙을 지킨다.
실패 2 경로의 세 번째 실패 앞 장면의 실패 2 대안을 계속한 경우 다음 실패로 3이 되어 잠긴다.	값·보충 정보 실패 수: 실패 2→3 잠금 상태: 잠김	변화·이유 성공으로 0이 된 다른 경로의 한 번 실패가 아니며 세 번 연속 실패의 임계조건이다.
해제 전 거부 잠김 상태는 관리자 해제 전까지 정상 인증을 허용하지 않는다.	값·보충 정보 실패 수: count 3 유지 잠금 상태: 해제 전 거부	변화·이유 잠긴 상태의 성공 입력을 자동 해제로 쓰지 않는다.

TS-1: 성공 초기화와 잠금 유지 · 상태 따라가기

인증 시도 전 실패 수는 0이고 잠기지 않았다. 모든 단계에서 실패 수·잠금 상태의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

정상과 실패 상태의 성공은 실패 횟수를 초기화한다. 잠금 뒤에는 올바른 비밀번호를 입력해도 관리자 해제 전까지 거부한다. 관리자 해제 자체의 세부 절차는 이 로그인 입력 전이와 분리하여 계약에서 확인한다.

이 예의 조건

• 정상과 실패 상태의 성공은 실패 횟수를 초기화한다. 잠금 뒤에는 올바른 비밀번호를 입력해도 관리자 해제 전까지 거부한다. 관리자 해제 자체의 세부 절차는 이 로그인 입력 전이와 분리하여 계약에서 확인한다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원래 그림의 모든 대상과 설명

대상	원래 설명
대상정상	원래 설명실패 횟수 0
대상실패 1	원래 설명다음 실패를 구분
대상실패 2	원래 설명다음 실패는 잠금
대상잠금	원래 설명관리자 해제 전 거부

원래 그림의 모든 관계와 조건

연결	원래 라벨·방향
연결정상 → 실패 1	원래 라벨·방향실패 / 정방향 / 실선
연결실패 1 → 실패 2	원래 라벨·방향실패 / 정방향 / 실선
연결실패 2 → 잠금	원래 라벨·방향실패 / 정방향 / 실선
연결실패 1 → 정상	원래 라벨·방향성공·초기화 / 정방향 / 실선
연결실패 2 → 정상	원래 라벨·방향성공·초기화 / 정방향 / 실선
연결잠금 → 잠금	원래 라벨·방향로그인 거부 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
정상 0 인증 시도 전 실패 수는 0이고 잠기지 않았다.	값·보충 정보 실패 수: count0 잠금 상태: 정상	변화·이유 현재 잠금 상태를 먼저 대조한다.
실패 1·2 실패하면 실패 횟수가 늘어나고 잠기기 전 성공하면 0으로 되돌아간다.	값·보충 정보 실패 수: 실패 1→2 / 성공 0 잠금 상태: 아직 정상	변화·이유 성공과 실패의 다른 갱신 규칙을 지킨다.
실패 2 경로의 세 번째 실패 앞 장면의 실패 2 대안을 계속한 경우 다음 실패로 3이 되어 잠긴다.	값·보충 정보 실패 수: 실패 2→3 잠금 상태: 잠김	변화·이유 성공으로 0이 된 다른 경로의 한 번 실패가 아니며 세 번 연속 실패의 임계조건이다.
해제 전 거부 잠김 상태는 관리자 해제 전까지 정상 인증을 허용하지 않는다.	값·보충 정보 실패 수: count 3 유지 잠금 상태: 해제 전 거부	변화·이유 잠긴 상태의 성공 입력을 자동 해제로 쓰지 않는다.

TS-1: 로그인 3회 실패 잠금의 상태전이

상태를 정상, 실패1, 실패2, 잠금으로 두고 실패 이벤트마다 다음 상태를 정의한다. 실패2에서 또 실패하면 잠금, 성공하면 실패횟수를 초기화하는지 요구를 확인한다. 단순히 “비밀번호 틀림” 케이스 하나만으로 상태규칙을 검증할 수 없다.

완성 예로는 ‘잠금 전 성공이면 실패횟수 초기화, 잠금 뒤에는 관리자 해제 전 로그인 거부’라는 별도 교육 계약을 정한다. 정상에서 실패하면 실패1, 다시 실패하면 실패2, 세 번째 실패하면 잠금이다. 실패2에서 올바른 비밀번호로 성공하면 정상으로 돌아가고, 다음 실패는 실패1로 시작한다. 반대로 잠금 상태에서 올바른 비밀번호를 넣어도 이 계약에서는 거부와 잠금 유지를 기대한다. 케이스를 만들 때는 현재 상태·입력 사건·응답·다음 상태를 네 칸으로 적어야 초기화 누락이나 잠금 우회를 발견할 수 있다. 이 규칙은 모든 서비스의 보안 정책을 대신하는 권고가 아니다.

결제에도 같은 작성 방법을 적용한다. 학습용 요청 K7의 ‘처리 중’ 상태에서 응답 시간초과를 주면 다음 상태는 ‘결과 미확인’이며 새 결제 생성은 기대하지 않는다. 같은 K7을 조회해 기존 결제 P42의 확정을 확인한 경우에만 ‘확정’으로 바꾸고, 재시도 뒤에도 P42의 한 번 청구를 기대한다. 앞 구현 절 IM-3의 주문 저장과 달리 실제 외부 결제의 중복 방지는 결제 경계에서 따로 시험해야 한다. 시간초과만 보고 ‘거절’로 바꾸거나 새 키로 결제를 만들어도 된다는 답은 관찰한 사건과 확인된 결과를 섞은 것이므로 IM-3: 응답을 못 받았다고 주문이 실패한 것은 아니다의 미확인·동일 키 분기를 다시 읽는다.

테스트 데이터가 실제 개인정보일 필요는 없다

형식·경계·관계성을 만족하는 합성·가명 데이터를 사용할 수 있다. 운영 개인정보를 복사해야만 현실적이라는 가정은 위험하다. 실제 데이터가 꼭 필요한 검증은 목적·최소범위·권한·보존기간을 별도로 승인한다.

6. 요구·위험·조건·케이스를 추적한다

추적표는 요구/위험 → 테스트조건 → 테스트케이스 → 실행결과 → 결함을 연결한다. 변경된 요구가 어떤 케이스를 재설계하게 하는지, 미검증 위험이 무엇인지 찾을 수 있어야 한다.

추적성 예

연결이 없다는 사실도 중요한 결과다. 미연결 요구와 위험을 숨기지 않는다.

주문·결제 준비에서 연령 요구를 자체 시험조건 REQ-AGE: 만18~65세 포함만 신청 허용으로 둔다. COND-AGE-LOW는 하한 바로 아래이며, TC-AGE-17의 사전상태는 비로그인 사용자 시험이 아닌 적법한 시험 계정·미생성 주문, 입력은 다른 필수 항목이 유효한 만 17세 신청이다. 기대 결과는 연령 거부 응답과 주문·결제 생성 0개다. 만 18세에서는 다른 조건이 모두 맞으면 신청 허용을 기대한다. 같은 만 17세 시험이 거부 문구만 내면서 결제를 만들면 실패다. 이 나이 범위는 시험용 요구이지 일반 법정 결제 연령이 아니다.

테스트 설계 검토의 종료 질문

• 핵심 위험마다 조건이 있는가
• 정상·경계·오류·상태 변화가 필요한가
• 테스트 데이터가 판정 가능하게 설계됐는가
• 환경차이가 위험을 숨기지 않는가
• 요구 변경 시 영향 케이스를 찾을 수 있는가
• 시작·종료 기준과 담당자가 명확한가

공식 범위 연결 — IT테스트 기획

목적·정책·전략·범위와 핵심 품질위험을 정하고 어떤 증거를 왜 수집할지 합의한다.

공식 범위 연결 — IT테스트 계획

자원·일정·환경·역할·데이터·도구·진입·종료기준을 실행 가능한 계획으로 만든다.

공식 범위 연결 — IT테스트 분석

요구·위험·아키텍처·결함이력에서 테스트대상·조건·커버리지 분모를 도출한다.

공식 범위 연결 — IT테스트 설계

테스트조건을 케이스·데이터·절차·기대결과로 변환하고 요구·위험과 추적 가능하게 연결한다.

출처와 적용 경계

기획·계획·분석·설계는 이 절에서 목적과 산출물을 구별해 학습하기 위한 구성이다. 활동의 반복·병렬 수행, 분석에서 조건을 찾고 설계에서 케이스로 구체화하는 구별은 2026-10-06에 ISTQB CTFL Syllabus v4.0.1의 §1.4.1·§5.1을 확인했다. 저작권은 해당 syllabus 저자들과 ISTQB에 있으며, 이 본문은 원문의 그림·장문 번역을 옮기지 않고 독립적으로 설명했다. 경계값·결정표·상태전이·추적표는 자체 교육 예제다. 적용 조직의 표준·계약·규제 판본에 따른 공식 산출물 명칭과 필수 항목은 별도로 확인한다.

7. 한 장으로 정리하기

1. 기획은 목적·전략·범위, 계획은 자원·일정·환경을 정한다.
2. 분석은 요구와 위험에서 테스트조건을 도출한다.
3. 설계는 조건을 케이스·데이터·기대결과로 만든다.
4. 케이스 수가 아니라 요구·위험·상태·경계의 커버리지 분모를 본다.
5. 운영과 다른 환경·데이터·의존성을 명시한다.
6. 요구–위험–조건–케이스–결과–결함을 추적한다.

독립 연습 — 실패 횟수보다 시작 상태를 먼저 적는다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

TS-1의 교육 계약에서 잠금 전 성공은 실패 횟수를 초기화하고, 잠금 뒤에는 관리자 해제 전까지 로그인을 거부한다. 정상 상태에서 실패·실패·성공·실패를 순서대로 입력한다. 별도로 잠금 상태에서 올바른 비밀번호를 입력한다.

• 첫 흐름의 각 입력 뒤 상태를 쓰고, 이후 실패 몇 번이면 잠금인지 판정하라.
• 잠금 상태에서 올바른 비밀번호를 입력했을 때의 응답과 후속 상태를 쓰라.

풀이와 오답 교정 보기

첫 흐름은 실패 1→실패 2→정상→실패 1이다. 현재 실패 1에서 두 번 더 실패하면 실패 2를 거쳐 잠금이 된다. 잠금에서 올바른 비밀번호를 넣어도 이 계약은 거부·잠금 유지다. 성공이 항상 잠금을 해제한다고 새 규칙을 넣지 않는다. 각 케이스에는 시작 상태·사건·응답·후속 상태를 함께 적어야 한다.

전체 실패 누적만 세었다면 TS-1의 초기화 계약, 구현의 조건을 정답으로 베꼈다면 구현과 독립적으로 요구에서 도출한 조건으로 돌아간다.

8. 자체 10점 문제

IT테스트의 기획, 계획, 분석, 설계 단계를 구분하고 각 단계의 주요 산출물과 상호관계를 설명하시오.

요구어는 구분, 설명이다. 네 단계를 단순 나열하지 말고 위험에서 케이스까지 내려가는 흐름으로 연결한다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 테스트 기획: 목적·전략·범위
2. 테스트 계획: 자원·일정·환경·역할
3. 테스트 분석: 조건·위험·커버리지
4. 테스트 설계: 케이스·데이터·기대결과
5. 추적성으로 네 단계 연결

10점 답안 도식

위험에서 준비 산출물로 이어지는 표를 다시 사용한다. 위험 → 기획(왜) → 계획(언제·누가) → 분석(무엇) → 설계(어떻게)를 각 산출물과 연결한다.

10점 모범답안

테스트 기획은 품질목표와 제품위험을 바탕으로 목적·정책·전략·범위와 필요한 증거수준을 정한다. 테스트 계획은 이를 실행하기 위해 역할·인력·일정·환경·도구·데이터·진입·종료기준을 배치한다. 테스트 분석은 요구·위험·아키텍처에서 시험해야 할 기능·상태·경계·실패조건과 커버리지 분모를 도출한다. 테스트 설계는 각 조건을 사전상태·입력·행동·기대결과·데이터를 가진 테스트케이스로 변환한다. 요구와 위험을 조건·케이스·결과·결함에 연결하는 추적성을 유지해야 변경영향과 미검증 범위를 확인할 수 있다.

9. 자체 25점 문제

주문·결제 시스템의 테스트를 준비하려 한다. 결제 중복, 권한오류, 네트워크 타임아웃, 연령제한, 개인정보 노출을 주요 위험으로 두고 테스트 기획·계획·분석·설계 방안을 제시하시오. 위험기반 우선순위, 환경, 경계값·결정표·상태전이, 테스트데이터, 추적성을 포함하시오.

요구어는 제시, 포함이다. 위험을 실제 조건과 케이스로 변환해야 한다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 품질목표·위험·테스트 범위
2. 위험기반 우선순위와 전략
3. 역할·일정·환경·데이터 계획
4. 요구·위험에서 테스트조건 분석
5. 경계값·결정표·상태전이 설계
6. 정상·오류·재시도·보안 케이스
7. 합성·가명 테스트데이터
8. 요구–위험–조건–케이스 추적성
9. 진입·종료기준과 미검증 범위

25점 답안 도식

중복결제·권한·timeout·PII 위험을 전략·환경·우선순위에 반영한다. 추적표의 REQ → CONDITION → CASE → RESULT → DEFECT 연결에서 조건에는 경계·상태를, 케이스에는 데이터·기대값을 남긴다. TS-1 상태 그림처럼 시작 상태와 입력 뒤 상태도 함께 확인한다.

25점 모범답안

기획에서는 주문·결제의 정확성, 중복방지, 접근통제, 개인정보 보호를 품질목표로 두고 결제 중복·권한오류·네트워크 타임아웃·연령제한·정보노출을 핵심 위험으로 정의한다. 단순 영향×가능성 점수 외에 법적 의무와 복구가능성을 반영해 우선순위를 정한다. 계획에서는 담당자, 일정, 결제샌드박스·DB·네트워크 지연 환경, 합성·가명 데이터와 진입·종료기준을 정한다. 분석에서는 주문 API 재시도, 인증·인가, 18~65 연령경계, 결제상태전이, 오류응답, 로그의 개인정보 노출을 테스트조건으로 도출한다. 설계에서는 교육용 REQ-AGE의 18~65세 포함 경계에 17·18·65·66을 대입한다. TC-AGE-17은 유효한 나머지 입력·주문 미생성 상태에서 만 17세를 제출해 연령 거부와 주문·결제 생성 0개를 함께 기대한다. TD-1의 10000원 주문은 회원·쿠폰 모두 O일 때 큰 할인 2000원 하나만 적용해 8000원을 기대한다. 결제 요청–처리–타임아웃–재시도–완료 상태전이와 멱등키 중복방지 케이스도 상태·효과로 확인한다. 운영 개인정보를 그대로 복사하지 않고 목적에 맞는 합성·가명 데이터를 사용하며, 요구·위험을 조건·케이스·실행결과·결함에 연결해 미검증 범위를 확인한다. 마지막으로 핵심 위험 케이스와 미해결 결함 기준을 품질기준으로 둔다. 합의한 시간·예산 조건으로 시험을 종료할 때도 미충족 기준·잔여 위험·종료 결정을 기록하고, 종료 사실을 품질기준 통과로 선언하지 않는다.

조건을 바꾸어 연습하기: 같은 케이스 이름을 유지해도 기대결과는 다시 계산한다.

다음 세 문제는 본문의 교육 계약을 적용하거나 명시적으로 바꾼다. 요구에서 기대결과를 먼저 정한 다음 관찰할 상태와 효과를 적는다.

1. TD-C. TD-1의 회원 할인 10%, 유효 쿠폰 할인 2,000원, 둘 다 있으면 큰 할인 하나만 적용한다는 조건은 유지한다. 주문금액만 30,000원으로 바꾸고 다른 할인은 없다. 회원·유효 쿠폰의 네 조합별 할인액과 최종금액을 구하라. 둘 다 있는 경우에 이전 예제의 기대값인 할인 2,000원을 그대로 써도 되는가? 할인들을 더한 5,000원을 기대해도 되는가?
2. TD-B. 교육용 REQ-AGE의 허용 나이를 기존 만 18~65세 포함에서 만 21~65세 포함으로 바꿨다. 나이는 정수이고, 그 밖의 입력·권한·사전상태는 유효하다. 만 17·18·20·21·65·66세 각각의 허용·거부 기대값을 쓰고, 새 최소 경계를 가장 가까이에서 확인하는 두 값을 골라라. 거부 케이스의 기대효과는 주문·결제 생성 0개다. 화면에는 거부가 표시되지만 주문이 1개 생겼다면 통과인가? 나이와 무관한 모든 케이스도 반드시 정답이 바뀌는가?
3. TD-S. TS-1 그림의 여섯 화살표만 전이 커버리지의 분모로 삼는다. 정상에서 비밀번호 실패·실패·성공·실패·실패·실패·성공을 차례로 제출한다. 각 입력 뒤 기대상태와 방문한 서로 다른 상태 수, 거친 서로 다른 화살표 수를 구하라. 아직 거치지 않은 화살표를 확인할 후속 케이스를 제안하라. 관리자 해제나 테스트 준비로 정상 상태를 다시 만드는 동작은 이 여섯 화살표의 집계에 넣지 않는다. 케이스를 설계한 것만으로 실제 실행 커버리지 100%와 보안 품질을 증명할 수 있는가?

할인 기대값·변경 경계·상태와 전이 커버리지 풀이

1. TD-C — 할인 조건의 조합과 금액을 함께 적는다. 회원 할인은 30,000×0.10=3,000원이다. 회원·쿠폰 모두 있으면 큰 할인 3,000원 하나를 적용해 27,000원, 회원만 있으면 3,000원 할인으로 27,000원, 쿠폰만 있으면 2,000원 할인으로 28,000원, 둘 다 없으면 할인 0원으로 30,000원이다. 10,000원 주문의 큰 할인은 2,000원이었지만 금액이 바뀌어 크기 관계도 달라졌다. 이전 숫자를 복사하면 요구가 아니라 과거 입력의 결과를 정답으로 삼게 된다.

두 할인을 더한 5,000원은 “큰 할인 하나”와 다른 정책이다. 기대결과에는 할인액뿐 아니라 최종금액도 적어 할인 선택과 차감을 각각 확인한다. 쿠폰 만료나 사용한도 같은 새 조건은 이 문제에 없으므로 임의로 만들지 않는다. 그런 정책이 필요하다면 요구를 확인하고 조건·데이터·기대결과를 추가한다.

2. TD-B — 변경된 경계의 양쪽과 거부 뒤 효과를 확인한다. 만 17·18·20세는 거부, 만 21·65세는 허용, 만 66세는 거부다. 새 최소 경계 양쪽의 가장 가까운 정수는 20과 21이다. 기존 18세 허용 기대값은 바뀌지만, 상한 경계 65·66의 기대값은 유지된다. 17·18이 거부됨을 확인하는 것만으로 20과 21 사이의 경계가 올바르다고 결론 내리지 않는다.

거부 표시와 주문 1개가 함께 관찰되면 생성 0개라는 기대효과를 어겼으므로 통과가 아니다. 결제 생성도 별도로 확인한다. 요구→나이 조건→관련 케이스의 연결을 따라 데이터·기대값과 회귀 범위를 갱신하고, 연령 판정에 의존하는 다른 흐름도 찾아 영향 여부를 검토한다. 나이와 무관한 케이스의 정답까지 무조건 바꾸지는 않는다. 이 범위는 교육용 계약이며 실제 업무의 연령·동의 정책을 정한 것이 아니다.

3. TD-S — 상태를 모두 방문해도 화살표를 모두 거치지는 않는다. 기대상태는 실패 1→실패 2→정상→실패 1→실패 2→잠금→잠금이다. 마지막 입력의 비밀번호가 맞아도 잠금은 유지되고 로그인은 거부된다. 시작 상태를 포함하면 정상·실패 1·실패 2·잠금 네 상태를 모두 방문하지만, 서로 다른 화살표는 정상→실패 1, 실패 1→실패 2, 실패 2→정상, 실패 2→잠금, 잠금→잠금의 다섯 개다. 상태 방문은 4/4, 이 그림의 전이는 5/6이고 실패 1→정상이 남는다.

정상으로 준비한 별도 케이스에서 실패·성공을 제출하면 실패 1→정상을 확인한다. 앞선 케이스와 합친 설계상 전이는 6/6이 된다. 실제 실행 커버리지는 각 입력의 응답·전후 상태를 관찰해 해당 전이가 실행됐다는 기록으로 계산한다. 기대상태를 적거나 모형으로 계산한 결과만으로 실제 시스템의 6/6을 선언하지 않는다. 실제로 여섯 전이를 모두 확인해도 이 모델 밖의 관리자 해제, 동시 요청, 권한, 정보 노출 등은 별도 범위이므로 전체 보안 품질 100%를 뜻하지 않는다.