[CTFL] 5장. 테스트 활동 관리

ISTQB-CTFL 실러버스 5장 정리하기

2026년 06월 10일

테스트 활동 관리

용어

결함 관리: 결함을 발견부터 종료까지 추적하고 처리하는 프로세스
결함 보고서: 발견된 결함의 정보를 기록한 문서
시작 조건: 특정 활동을 시작하기 위해 충족해야 하는 전제 조건
완료 조건: 특정 활동의 종료를 선언하기 위해 달성해야 하는 조건
제품 리스크: 제품의 품질 특성과 관련된 리스크
프로젝트 리스크: 프로젝트 관리 및 제어와 관련된 리스크
리스크: 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황
리스크 분석: 리스크를 식별하고 평가하는 활동
리스크 평가: 식별한 리스크의 발생 가능성, 영향, 수준을 결정하는 활동
리스크 제어: 리스크를 완화하고 모니터링하는 활동
리스크 식별: 포괄적인 리스크 목록을 생성하는 활동
리스크 수준: 리스크 발생 가능성과 영향을 조합해 산출한 리스크 측정값
리스크 관리: 리스크 분석과 리스크 제어를 포함하는 전반적인 활동
리스크 완화: 리스크 평가 때 제안된 조치를 실행해 리스크 수준을 낮추는 활동
리스크 모니터링: 완화 조치의 효과를 확인하고 신규 리스크를 식별하는 활동
리스크 기반 테스팅: 리스크 분석과 제어를 기반으로 테스트 활동을 선택하고 우선순위를 정해 관리하는 접근법
테스트 접근법: 테스트 목적 달성을 위한 전반적인 테스팅 방법 및 전략
테스트 완료 보고서: 특정 테스트 활동이 끝났을 때 결과를 요약한 보고서
테스트 제어: 테스트 목적 달성을 위해 필요한 조치를 취하는 활동
테스트 모니터링: 테스트 진행 상황을 지속적으로 추적하고 파악하는 활동
테스트 계획서: 테스트 목적, 자원, 프로세스를 설명하는 문서
테스트 계획: 테스트 목적을 달성하기 위한 접근법과 일정을 수립하는 활동
테스트 진행 보고서: 테스트 진행 상황을 주기적으로 이해관계자에게 전달하는 보고서
테스트 피라미드: 테스트 세분화 수준과 자동화 수준의 관계를 층으로 표현한 모델
테스트 전략: 테스팅에 대한 조직 수준의 일반적인 접근 방향
테스팅 사분면: 테스트 유형과 레벨을 비즈니스/기술, 팀 지원/제품 평가 두 축으로 분류한 모델

5.1 테스트 계획

5.1.1 테스트 계획서의 목적과 내용

테스트 계획서는 테스트 프로젝트의 테스트 목적, 자원, 프로세스를 설명한다. 테스트 계획 활동은 테스터가 리스크, 일정, 인력, 도구, 비용, 노력 등 향후 문제를 고민하도록 한다.

5.1.2 반복 주기와 릴리스 계획에 대한 테스터의 기여

일반적으로 반복적 SDLC에서 릴리스 계획과 반복 주기 계획이 이루어진다.

릴리스 계획
- 제품 릴리스를 계획하는 단계
- 제품 백로그를 (재)정의
- 큰 사용자 스토리를 작은 사용자 스토리들로 세분화하는 작업을 포함할 수 있다.
- 개별 반복 주기의 테스트 접근법과 테스트 계획을 위한 기반이 된다.
릴리스 계획에 참여하는 테스터
- 테스트 가능한 사용자 스토리와 인수 조건이 작성되도록 하기
- 프로젝트 및 품질 리스크 분석에 참여
- 사용자 스토리와 관련된 테스트 노력을 추정
- 테스트 접근법을 결정하고 릴리스를 위한 테스팅을 계획
반복 주기 계획
- 개별 반복 주기를 계획하는 것으로 반복 주기 백로그와 관련
반복 주기 계획에 참여하는 테스터
- 사용자 스토리의 구체적인 리스크 분석에 참여
- 사용자 스토리의 테스트 용이성을 판단
- 사용자 스토리를 업무 단위로 분류
- 테스트 노력을 추정
- 테스트 대상의 기능 및 비기능적 측면을 식별하고 구체화

5.1.3 시작 조건과 완료 조건

시작 조건: 어떤 활동을 수행하기 위한 전제 조건을 정의
- 자원의 가용성 (예: 인력, 도구, 환경, 테스트 데이터, 예산, 시간)
- 테스트웨어 가용성 (예: 테스트 베이시스, 테스트 케이스, 사용자 스토리)
- 테스트 대상의 초기 품질 수준 (예: 모든 스모크 테스트가 합격함)
완료 조건: 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항
- 테스트의 철저함을 측정하는 지표 (예: 달성한 커버리지 수준, 미해결 결함 수, 결함 밀도)
- 시간 및 예산의 소진

시작 조건과 완료 조건은 각 테스트 레벨에 대해 정의해야 하며 테스트 목적에 따라 달라진다.

※ 애자일에서 완료 조건을 완료의 정의(Definition of Done), 시작 조건을 준비의 정의(Definition of Ready) 라고 한다.

5.1.4 추정 기법

비율 기반 추정
- 이전 프로젝트의 메트릭에서 도출한 표준 비율을 사용해 새 프로젝트의 테스트 노력을 추정한다.
- 예: 과거 프로젝트에서 개발:테스트 비율이 3:2였고, 현재 프로젝트 개발 노력이 600MD이면 테스트 노력은 400MD로 추정
외삽법(Extrapolation)
- 현재 프로젝트에서 초기에 데이터를 수집해 수학적 모델로 남은 작업의 노력을 추정한다.
- 반복적 SDLC에 적합하다.
와이드밴드 델파이(Wideband Delphi)
- 여러 전문가가 독립적으로 추정
- 편차가 있으면 논의 후 재추정하는 과정을 합의에 도달할 때까지 반복한다.
- 애자일에서는 플래닝 포커(Planning Poker) 형태로 많이 사용한다.
3점 추정(Three-point estimation)
- 전문가가 낙관적(a), 확률적으로 가장 높은(m), 비관적(b) 세 추정치를 도출하여 가중 평균으로 계산한다.
- 계산식: E = (a + 4*m + b) / 6
- 표준 편차: SD = (b - a) / 6
- 예: a=6, m=9, b=18이면 E=10, SD=2 → 최종 추정치: 10±2 MH

5.1.5 테스트 케이스 우선순위 지정

테스트 케이스와 테스트 절차를 도출해서 테스트 스위트로 조립하고 나면 테스트 스위트를 테스트 일정으로 구성할 수 있다.

리스크 기반 우선순위 지정
- 리스크 분석 결과에 따라 테스트 실행 순서를 결정
- 가장 중요한 리스크를 다루는 테스트 케이스를 먼저 실행
커버리지 기반 우선순위 지정
- 테스트 실행 순서를 커버리지에 따라 결정
- 가장 높은 커버리지를 달성하는 테스트 케이스를 먼저 실행
요구사항 기반 우선순위 지정
- 테스트 실행 순서를 요구사항의 우선순위에 따라 결정
- 가장 중요한 요구사항 관련 테스트 케이스를 먼저 실행

5.1.6 테스트 피라미드

테스트 피라미드는 테스트에 따라 세분화 수준(granularity) 이 다를 수 있다는 것을 보여주는 모델이다.

계층이 높아질수록
- 테스트 세분화 정도는 낮아진다.
- 테스트 격리는 낮아지며 테스트 실행 시간은 길어진다.
- 복잡하고 상위 수준의 End-to-End 테스트를 대변한다.
- 상위 수준 테스트는 실행 속도가 비교적 느리다.
- 큰 규모의 기능을 확인하기 때문에 적은 수로 적절한 커버리지 도달 가능

5.1.7 테스팅 사분면

테스트는 비즈니스 또는 기술에 대한 테스트일 수 있다. 테스트는 팀을 지원하거나 제품을 평가할 수 있다. 이 두 가지의 조합에 따라 네 개의 사분면이 결정된다.

1사분면 (기술 측면, 팀 지원)
- 컴포넌트 테스트 및 컴포넌트 통합 테스트를 포함
- 자동화해야 하며 지속적인 통합(CI) 프로세스에 포함돼야 한다.
2사분면 (비즈니스 측면, 팀 지원)
- 기능 테스트, 예제, 사용자 스토리 테스트
- 사용자 경험 프로토타입, API 테스팅, 시뮬레이션 등
- 인수 조건을 확인하며 수동 또는 자동화
3사분면 (비즈니스 측면, 제품 평가)
- 탐색적 테스팅, 사용성 테스팅, 사용자 인수 테스팅을 포함
- 사용자 중심으로 이루어지며 수동 실행이 많다.
4사분면 (기술 측면, 제품 평가)
- 스모크 테스트와 비기능 테스트 (사용성 테스트 제외)를 포함
- 자동화가 많다.

5.2 리스크 관리

주요 리스크 관리 활동은 다음과 같다.

리스크 분석: 리스크 식별과 리스크 평가로 구성
리스크 제어: 리스크 완화와 리스크 모니터링으로 구성

5.2.1 리스크의 정의와 리스크의 속성

리스크: 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황
- 리스크 발생 가능성: 리스크 발생 확률 (0 초과 1 미만)
- 리스크 영향(피해): 발생했을 때 생기게 될 피해

이 두 요소를 조합해 리스크 수준을 표현한다. 리스크 수준이 높을수록 그에 대한 조치도 중요해진다.

5.2.2 프로젝트 리스크와 제품 리스크

프로젝트 리스크: 프로젝트 관리 및 제어와 관련
- 조직 문제 (예: 인도 지연, 부정확한 추정, 예산 축소)
- 인력 문제 (예: 기술 부족, 갈등, 의사소통 문제)
- 기술적 문제 (예: 합의 없는 범위 추가, 도구 지원 부족)
- 공급업체 문제 (예: 제3자 인도 실패, 지원 기업의 파산)
제품 리스크: 제품 품질 특성과 관련
- 예: 누락/잘못된 기능, 부정확한 계산, 런타임 오류, 열악한 아키텍처, 보안 취약점 등

5.2.3 제품 리스크 분석

제품 리스크 분석은 SDLC 초기에 시작하는 것이 이상적이다.

리스크 식별: 포괄적인 리스크 목록을 생성
- 브레인스토밍, 워크숍, 인터뷰, 원인-결과 다이어그램 등 활용
리스크 평가: 정량적 또는 정성적 접근법을 사용
- 정량적 접근법: 리스크 수준 = 리스크 발생 가능성 × 리스크 영향
- 정성적 접근법: 리스크 행렬을 사용하여 리스크 수준 판단

5.2.4 제품 리스크 제어

제품 리스크 제어: 식별 및 평가된 제품 리스크에 대응해 취하는 모든 조치
- 리스크 완화: 리스크 평가 때 제안된 조치를 실행해 리스크 수준을 낮추는 활동
- 리스크 모니터링: 완화 조치가 효과적인지 확인, 리스크 평가 개선을 위해 추가 정보 확보, 새로운 리스크 식별

5.3 테스트 모니터링, 테스트 제어, 테스트 완료

테스트 모니터링: 테스팅에 대한 정보 수집
- 테스트 진행 상황 평가
- 완료 조건이나 관련된 테스트 작업이 충족되었는지 측정
테스트 제어: 테스트 모니터링으로 얻은 정보로 제어 지침/지도/필요 수정 조치 등을 제공

5.3.1 테스팅에 사용하는 메트릭

테스트 메트릭은 테스트 진행 상황, 테스트 대상의 품질, 테스트 활동의 효과를 보여주기 위해 수집한다.

많이 사용하는 테스트 메트릭은 다음과 같다.

프로젝트 진행 상황 메트릭 (예: 작업 완료율, 자원 사용률, 테스트 노력 투입률)
테스트 진행 상황 메트릭 (예: 테스트 케이스 구현 진행률, 합격/불합격 테스트 케이스 수, 테스트 실행 시간)
제품 품질 메트릭 (예: 가용성, 응답 시간, 평균 장애 시간)
결함 메트릭 (예: 발견/수정한 결함의 수와 우선순위, 결함 밀도, 결함 발견 비율)
리스크 메트릭 (예: 잔여 리스크 수준)
커버리지 메트릭 (예: 요구사항 커버리지, 코드 커버리지)
비용 메트릭 (예: 테스팅 비용, 조직의 품질 비용)

5.3.2 테스트 보고서의 목적, 내용, 대상

테스트 보고는 테스팅 도중과 이후에 테스트 정보를 요약하고 전달하는 활동이다.

테스트 모니터링 및 제어 과정 중 테스트팀은 이해관계자에게 정보를 제공하기 위해 테스트 진행 상황 보고서를 작성한다. 일반적으로 정기적으로 작성하며 다음을 포함한다.

테스팅 기간
테스트 진행 상황 (예정보다 빠름/늦어짐), 주목할 만한 편차 포함
테스팅 진행 방해 요소와 대응 방법
테스트 메트릭
테스팅 중 식별한 신규 및 변경된 리스크
다음 주기에 예정된 테스팅

테스트 완료 보고서는 프로젝트, 테스트 레벨, 테스트 유형이 끝나고 이상적으로는 완료 조건도 충족된 상황에서 이루어지는 테스트 완료 활동 중 작성한다. 일반적으로 다음을 포함한다.

테스트 요약
원래 테스트 계획에 기반한 테스팅 및 제품 품질 평가
테스트 계획과의 편차 (예: 계획한 일정, 기간, 공수와의 차이)
테스팅 방해 요소와 대응 방법
테스트 진행 상황 보고서를 기반으로 한 테스트 메트릭
완화되지 않은 리스크, 수정되지 않은 결함
테스팅 관련 교훈

5.3.3 테스팅 상황 전달

테스트 상황을 전달하는 의사소통 방식으로 여러 가지가 있으며 선택지 중 하나 이상을 사용할 수 있다. 물리적 거리나 시차로 인해 직접적인 대화가 어려운 분산된 팀은 더욱 공식적인 의사소통 방법을 사용하는 것이 적합할 수 있다.

의사소통 방법의 예는 다음과 같다.

팀원 및 기타 이해관계자와의 대화
대시보드 (예: CI/CD 대시보드, 태스크 보드, 번다운 차트)
전자 통신 채널 (예: 이메일, 채팅)
온라인 문서
공식 테스트 보고서

5.4 형상 관리

형상 관리(CM, Configuration Management) 는 테스트 계획서, 테스트 케이스, 테스트 스크립트, 테스트 결과 등 작업 산출물을 형상 항목으로 식별, 제어, 추적하는 지침을 제공한다.

테스팅을 적절히 지원하기 위해 형상 관리는 다음을 보장한다.

모든 형상 항목에 고유 식별자 부여, 버전 관리, 변경 추적, 연관성 식별 → 테스트 프로세스 전체에서 추적성 유지
모든 문서와 소프트웨어 항목은 테스트웨어 내에서 명확하게 참조되어야 한다.

형상 항목이 테스팅용으로 승인되면 베이스라인이 되며, 공식적인 변경 제어 프로세스를 통해서만 수정할 수 있다. 이전 베이스라인으로 되돌리면 이전 테스트 결과를 재현할 수 있다.

※ CI/CD 파이프라인에는 보통 자동화된 형상 관리가 포함되어 있다.

5.5 결함 관리

보고된 이상 사항은 SDLC 모든 단계에서 보고될 수 있으며, 보고된 이상 사항이 실제로 결함인지 아닌지는 결함 보고서를 처리하는 과정에서 해결된다.

최소한 결함 관리 프로세스에는 개별 결함이나 이상 사항을 발견부터 종료까지 처리하는 작업 흐름(workflow) 과 분류 기준에 대한 규칙이 포함되어야 한다.

참고

ISTQB 공식 Syllabus