품질 특성별 테스트 분석 — 기능 적합성과 상호운용성을 케이스로 내리기

개념

특성 목록을 아는 것과 케이스를 뽑는 것 사이의 거리

모듈 25 레슨 2에서 ISO/IEC 25010의 품질 특성을 검증 항목으로 옮기는 4단계를 배웠고, 모듈 30 레슨 2에서 2023년 2판이 9특성 체계로 바뀐 것을 확인했다. 모듈 30 레슨 3에서는 호환성 칸의 경계 — 공존성과 상호운용성 둘뿐이라는 것 — 을 그었다.

그 위에서 이 레슨이 다루는 질문은 하나다. 특성 이름에서 실제 테스트 케이스까지 내려가는 길을 어떻게 만드는가.

이 길이 없으면 품질 특성은 문서 장식이 된다. 테스트 계획서에 "ISO/IEC 25010 기준 품질 특성을 고려하여 시험한다"고 적혀 있는데 정작 케이스 목록은 기능 시나리오만 나열된 상황이 흔하다. 특성과 케이스가 연결되지 않은 것이다.

5단계 분석 절차

특성에서 케이스까지는 다섯 단계를 거친다. 중간 단계를 건너뛰면 "성능 테스트: 응답 시간 확인" 같은, 케이스도 아니고 계획도 아닌 문장이 나온다.

① 특성·부특성 선택      어느 축을 볼 것인가            25010:2023
       ↓
② 품질 요구 진술        우리 제품에서 그것이 무슨 뜻인가  제품 맥락
       ↓
③ 테스트 조건 도출      무엇을 확인하면 알 수 있는가     분석의 핵심
       ↓
④ 케이스 설계           어떤 입력으로 확인하는가         모듈 3 기법
       ↓
⑤ 합격 기준 확정        무엇을 보면 합격인가             모듈 58 레슨 1 오라클

③번이 이 모듈의 주제다. ④는 기법의 영역이고 ⑤는 오라클의 영역이다. 분석이란 ①②③을 하는 일 이다.

기능 적합성 — 세 부특성은 서로 다른 세 종류의 분석이다

기능 적합성(functional suitability)의 세 부특성은 이름이 비슷해서 뭉뚱그려지기 쉬운데, 실제로는 서로 완전히 다른 질문 이고 다른 입력 자료를 요구한다.

이 구분이 실무에서 만드는 차이를 예로 보자. 대상은 "휴가 신청" 기능이다.

[완전성 분석]  요구 목록 대 구현 목록을 대조한다
  - 신청 / 조회 / 취소 / 결재 / 반려 / 대리 결재 / 이력 조회
  - 구현: 신청·조회·결재·반려만 있다  →  취소, 대리 결재, 이력 조회 누락
  ※ 여기서 나오는 산출물은 케이스가 아니라 "커버리지 격자"다
 
[정확성 분석]  계산·판정 규칙을 규칙 단위로 쪼갠다
  - 잔여 연차 계산: 입사일 기준 vs 회계연도 기준
  - 반차 0.5일 처리, 경조사 휴가 일수, 무급 휴가 차감 제외
  - 토·일·공휴일 제외 규칙, 연도 경계를 넘는 신청
  ※ 여기서 나오는 산출물은 경계값·결정 테이블 케이스다
 
[적절성 분석]  사용자 목표에서 출발해 흐름을 따라간다
  - 목표: "다음 주 수요일 오후에 반차를 쓰고 싶다"
  - 달성 경로가 3클릭인가 9클릭인가, 잔여 연차를 신청 화면에서 볼 수 있는가
  - 결재자가 부재중이면 목표 달성이 막히는가
  ※ 여기서 나오는 산출물은 시나리오 케이스와 사용성 관찰 항목이다

세 분석의 입력도 다르고 출력도 다르다. 기능 적합성을 "기능이 요구대로 동작하는지 본다"로 뭉뚱그리면 이 중 정확성만 하게 되고, 완전성 분석(누락 발견)과 적절성 분석(목표 달성 실패)은 통째로 빠진다. 운영에서 "기능은 다 되는데 쓸 수가 없다"는 피드백이 오는 제품은 대개 적절성 분석이 없었던 제품이다.

완전성 분석의 도구 — 커버리지 격자

완전성은 케이스를 쓰는 일이 아니라 대조하는 일 이다. 축을 둘 잡고 격자를 만든다.

빈칸이 아니라 X가 있는 칸이 발견 이다. 명세 X 는 요구 공백(기획에게 질문), 구현 X 는 구현 누락(개발에게 결함)이다. 모듈 4 레슨 7의 계층별 전수 점검 체계와 같은 발상이고, 축을 "기능 × 사용자 유형" 외에 "기능 × 데이터 상태", "기능 × 채널(웹·앱·API)"로도 잡을 수 있다.

상호운용성 — 네 층으로 나눈다

상호운용성(interoperability)은 "연동이 되는가"로 뭉뚱그려지는 대표적인 특성이다. 모듈 30 레슨 3에서 상호운용성의 경계(상대가 다른 제품인가)를 그었다면, 여기서는 연동 시험을 어느 층까지 내려갈 것인가 를 다룬다. 네 층으로 나눈다.

층 4  버전·진화   상대가 필드를 추가/삭제/변경했을 때
       ↑
층 3  오류·장애   상대가 느리거나, 죽거나, 이상한 값을 줄 때
       ↑
층 2  의미        같은 값이 양쪽에서 같은 뜻인가
       ↑
층 1  구문·계약   형식·필수 여부·타입·인증이 맞는가

②층이 사고를 만든다. 구문은 맞는데 뜻이 다른 경우다. 실제로 반복되는 유형이 있다.

- 금액 단위: 한쪽은 원, 다른 쪽은 전(1/100원) → 100배 오차
- 시간대: 한쪽 KST, 다른 쪽 UTC → 9시간 차이, 날짜 경계에서 하루 차이
- 날짜 경계: "영업일"의 정의가 다르다 (모듈 41 레슨 2)
- 식별자: 주문번호가 한쪽은 주문 단위, 다른 쪽은 배송 단위
- 상태코드: 같은 코드값을 양쪽이 다르게 매핑
- 소수 처리: 반올림 vs 내림, 처리 시점이 다르다

②층의 테스트 조건은 양쪽 문서를 나란히 놓고 값 하나하나를 대조하는 작업 에서 나온다. 이 대조표를 만드는 것이 상호운용성 분석의 실체다.

③층을 시험하려면 환경을 설계해야 한다

오류·장애 층은 "상대가 정상일 때"는 절대 안 보인다. 상대를 인위적으로 망가뜨릴 수단이 필요하다.

수단                       무엇을 시험할 수 있나
────────────────────────────────────────────────
계약 테스트 (Pact 등)      ①층 계약 불일치를 CI에서 조기 검출
목/스텁 서버               ②③④층 전부. 응답을 마음대로 조작
프록시 지연·오류 주입      ③층 타임아웃·부분 실패
상대 샌드박스 환경         실제 구현과의 차이 확인

실무에서 가장 자주 빠지는 것은 목 서버로 ③층을 시험할 수 있다는 사실을 모르는 것 이다. "연동 상대가 협조를 안 해줘서 장애 시나리오를 못 본다"는 말은 대부분 사실이 아니다. 목 서버로 타임아웃·5xx·잘린 응답·잘못된 JSON을 던지는 것은 상대의 협조 없이 우리 쪽에서 전부 할 수 있다.

[목 서버로 만드는 ③층 시험 조건 목록]
- 응답 지연 (타임아웃 경계 직전 / 직후)
- HTTP 500 / 502 / 503
- 연결 수립 후 무응답
- 응답 본문이 중간에 잘림
- Content-Type은 JSON인데 본문이 HTML (오류 페이지)
- 200 OK인데 본문에 오류 코드
- 같은 요청에 두 번 다른 응답 (재시도 중복 처리 확인)

마지막 항목이 멱등성 결함을 잡는다. 금융에서는 이것이 이중 출금으로 직결된다(모듈 41 레슨 2).

분석 결과를 추적 가능하게 남긴다

5단계를 거친 결과는 하나의 표로 남는다. 이 표가 "품질 특성을 고려했다"는 주장의 증거가 된다.

QA-04의 합격 기준이 레슨 1에서 다룬 불변식 오라클이다. 품질 특성 분석과 오라클 설계는 같은 표의 다른 칸이다.

실무에서 왜 필요한가

RFP와 제안서에는 "ISO/IEC 25010 품질 특성에 따른 시험"이라는 문장이 자주 들어간다. 이 문장을 실제 산출물로 증명해야 하는 순간이 오면 — GS인증 심사, 발주처 검수, 고객사 품질 감사 — 특성에서 케이스로 내려간 추적표가 있는 팀과 없는 팀이 갈린다. 없는 팀은 그 자리에서 기존 케이스를 특성에 사후 배치하는데, 그러면 빈 특성이 드러난다.

더 일상적인 효과는 케이스 목록의 공백 발견 이다. 기능 적합성을 세 부특성으로 분리하는 것만으로 대부분의 팀에서 완전성 분석과 적절성 분석이 통째로 비어 있다는 것이 보인다. 상호운용성을 네 층으로 나누면 ③층(오류·장애)이 거의 항상 비어 있다. 이 두 발견이 이 레슨의 실질적인 산출물이다.

실습 과제

과제 1 — 기능 적합성 세 갈래로 쪼개기 (25분)

담당 기능 하나를 골라 세 부특성별로 분석한다. 각각 산출물 형태가 다르다는 점에 주의한다.

1. 완전성 — 축 두 개를 잡아 커버리지 격자를 그리고 명세 X / 구현 X 칸을 표시한다
2. 정확성 — 계산·판정 규칙을 규칙 단위로 뽑고 각 규칙의 경계를 적는다
3. 적절성 — 사용자 목표 두 개를 정하고 목표 달성 경로를 끝까지 따라가 막히는 지점을 적는다

끝나고 센다. 셋 중 지금까지 한 번도 해본 적 없는 분석이 어느 것인가.

과제 2 — 연동 필드 대조표 (25분)

외부 연동 하나를 골라 필드 대조표를 만든다. 양쪽 규격서를 나란히 놓고 필드별로 채운다.

단위·시간대·소수 처리·식별자 범위·코드 매핑 다섯 축을 반드시 확인한다. 상대 규격서에 정의가 없으면 그 칸은 "미정의" 로 적는다 — 미정의 칸이 레슨 1의 "오라클 출처 없음"에 해당하는 질문 목록이 된다.

과제 3 — 목 서버로 ③층 여섯 건 (20분)

본문의 ③층 시험 조건 목록에서 여섯 개를 골라 목 서버(또는 프록시)로 재현하고, 우리 시스템의 실제 동작을 기록한다.

"기대했던 동작" 칸을 채울 수 없는 행이 있으면, 그건 결함이 아니라 설계 공백 이다. 그대로 질문으로 올린다.

자가 체크리스트

• 특성 → 품질 요구 진술 → 테스트 조건 → 케이스 → 합격 기준의 5단계를 설명할 수 있다
• 기능 완전성·정확성·적절성이 서로 다른 입력 자료와 산출물을 요구한다는 것을 설명할 수 있다
• 커버리지 격자를 만들어 요구 공백과 구현 누락을 구분해 표시할 수 있다
• 상호운용성을 구문·의미·오류·버전 네 층으로 나눠 시험 조건을 낼 수 있다
• 연동 필드 대조표에서 단위·시간대·소수 처리·식별자·코드 매핑을 점검할 수 있다
• 목 서버로 상대의 협조 없이 오류·장애 층을 시험할 수 있다
• 분석 결과를 특성·요구·조건·케이스·합격 기준·오라클이 한 줄에 놓인 추적표로 남길 수 있다

흔한 실수

• 기능 적합성을 "기능이 되는지"로 뭉뚱그린다. 정확성만 하게 되고 완전성·적절성 분석이 통째로 빠진다.
• 품질 특성을 계획서에만 적는다. 케이스와 연결되지 않은 특성 목록은 장식이다. 추적표로 내려야 한다.
• 여덟(또는 아홉) 특성을 균등하게 채우려 한다. 모듈 25 레슨 2에서 지적한 함정이다. 제품 맥락에 맞춰 가중치를 둔다.
• 연동 시험을 정상 흐름만 한다. 오류·장애 층이 비어 있고, 그 층에서 운영 사고가 난다.
• 연동 규격서를 읽고 "맞다"고 판단한다. 문서가 아니라 실제 응답을 받아 대조해야 한다. 규격서와 구현이 다른 경우가 흔하다.
• 상대가 협조하지 않아 장애 시나리오를 못 본다고 말한다. 목 서버로 대부분 가능하다.

참고 자료

• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model — 9특성 체계의 정본
• ISO/IEC 25010 품질 모델 정리 — iso25000.com — 특성·부특성 정의를 영문으로 확인할 때
• ISO/IEC 25023:2016 — Measurement of system and software product quality. 특성별 측정량 정의. 2011판 특성 이름 기준이라는 점에 주의(모듈 30 레슨 2)
• ISTQB Certified Tester Advanced Level Test Analyst (CTAL-TA) — 품질 특성 기반 테스트 분석 영역
• 레슨 s2-m25-l02 — ISO/IEC 25010 품질 특성을 검증 항목으로 옮기기(4단계와 가중치)
• 레슨 s2-m30-l02 — 25010 2판 개정(9특성 체계와 판 표기)
• 레슨 s2-m30-l03 — 호환성: 공존성과 상호운용성의 경계
• 레슨 s2-m58-l01 — 테스트 오라클 설계(합격 기준 칸의 근거)