ISTQB CTFL v4.0 용어 및 학습목표 정리

CokeBear·2025년 10월 24일

제 1장: 테스팅의 기초 (180분)

📌 핵심 용어

용어	설명
커버리지(coverage)	테스트가 대상을 얼마나 다루었는지를 나타내는 측정치
디버깅(debugging)	장애의 원인(결함)을 찾고, 분석하고, 제거하는 활동
결함(defect)	작업 산출물의 불완전성이나 오류 (버그, 결점)
오류(error)	사람이 저지르는 실수
장애(failure)	시스템이 요구된 작업을 수행하지 못하는 현상
품질(quality)	컴포넌트나 시스템이 명시된 요구사항을 충족하는 정도
품질 보증(quality assurance)	프로세스 중심의 예방적 접근법
근본 원인(root cause)	문제 발생의 근본적 이유
테스트 분석(test analysis)	테스트 베이시스를 분석해 테스트 가능한 기능을 식별하는 활동
테스트 베이시스(test basis)	테스트 케이스를 도출하기 위한 기반이 되는 문서나 정보
테스트 케이스(test case)	특정 목적을 달성하기 위한 입력값, 실행 조건, 기대 결과의 집합
테스트 완료(test completion)	테스트 활동에서 데이터를 수집하여 경험과 테스트웨어를 정리하는 활동
테스트 컨디션(test condition)	테스트 가능한 컴포넌트나 시스템의 특성
테스트 제어(test control)	테스트 목적 달성을 위한 조치를 하는 활동
테스트 데이터(test data)	테스트 실행 시 사용되는 데이터
테스트 설계(test design)	테스트 컨디션을 테스트 케이스로 구체화하는 활동
테스트 실행(test execution)	테스트를 수행하는 활동
테스트 구현(test implementation)	테스트 실행에 필요한 테스트웨어를 만들거나 획득하는 활동
테스트 모니터링(test monitoring)	테스팅 정보를 지속적으로 수집하고 분석하는 활동
테스트 대상(test object)	테스트되는 작업 산출물
테스트 목적(test objective)	테스팅을 통해 달성하고자 하는 목표
테스트 계획(test planning)	테스트 목적을 정의하고 접근법을 선택하는 활동
테스트 절차(test procedure)	테스트 케이스들의 실행 순서
테스트 결과(test result)	테스트 실행의 결과
테스팅(testing)	결함을 식별하고 품질을 평가하는 일련의 활동
테스트웨어(testware)	테스트 프로세스 중 생성되는 모든 산출물
추적성(traceability)	테스트 베이시스와 테스트웨어 간의 연결 관계
밸리데이션(validation)	사용자 필요 충족 여부를 확인하는 활동
베리피케이션(verification)	요구사항 충족 여부를 확인하는 활동

🎯 학습 목표 및 답변

FL-1.1.1 (K1) 일반적인 테스트 목적을 식별할 수 있다

답변:
일반적인 테스트 목적은 다음과 같습니다:

요구사항, 사용자 스토리, 설계, 소스 코드 등 작업 산출물 평가
장애 유발 및 결함 식별
테스트 대상에 대해 요구된 커버리지 보장
소프트웨어 품질 부족으로 인한 리스크 수준 완화
정의된 요구사항 충족 여부를 확인하는 베리피케이션
계약, 법률, 규제 요구사항 준수 여부 확인
이해관계자의 정보에 입각한 의사결정 지원
테스트 대상의 품질에 대한 자신감 획득
이해관계자의 기대 충족 여부를 확인하는 밸리데이션

FL-1.1.2 (K2) 테스팅과 디버깅을 구별할 수 있다

답변:
| 구분 | 테스팅 | 디버깅 |
|------|--------|---------|
| 목적 | 결함으로 인한 장애를 유발하거나 결함을 직접 찾아냄 | 장애의 원인(결함)을 찾고, 분석하고, 제거함 |
| 활동 | 동적 테스팅: 장애 유발
정적 테스팅: 결함 직접 발견 | 1. 장애 재현
2. 분석(결함 찾기)
3. 결함 수정 |
| 수행 시점 | 테스트 실행 중 | 장애 발견 후 |
| 후속 활동 | 결함 보고 → 디버깅 | 확인 테스팅, 리그레션 테스팅 |

관계: 테스팅에서 발견한 결함 → 디버깅으로 수정 → 확인 테스팅으로 검증 → 리그레션 테스팅으로 부작용 확인

FL-1.2.1 (K2) 테스팅이 필요한 이유를 예를 들어 설명할 수 있다

답변:
테스팅이 필요한 이유:

결함을 조기에 식별하여 비용 절감
- 예: 요구사항 단계에서 결함 발견 시 개발 후 발견보다 수정 비용이 훨씬 적음
소프트웨어 품질을 직접 평가
- 예: 성능 테스트를 통해 시스템이 1000명 동시 접속을 처리할 수 있는지 확인
사용자를 간접적으로 대변
- 예: 실제 사용자 참여가 어려운 경우 테스터가 사용자 시나리오 기반 테스트 수행
리스크 감소
- 예: 금융 시스템에서 보안 테스팅을 통해 금전적 손실 리스크 완화
계약/법률/규제 요구사항 충족
- 예: 의료기기 소프트웨어는 FDA 규제 준수를 위한 테스팅 필수
제품 릴리스 의사결정 지원
- 예: 테스트 커버리지 90% 달성 시 릴리스 승인

FL-1.2.2 (K1) 테스팅과 품질 보증의 관계를 상기할 수 있다

답변:
| 구분 | 테스팅 | 품질 보증(QA) |
|------|--------|---------------|
| 접근법 | 교정적(corrective) | 예방적(preventive) |
| 초점 | 제품 중심 | 프로세스 중심 |
| 목적 | 결함 식별 및 제거 | 좋은 프로세스로 좋은 제품 생산 |
| 활동 | 테스트 실행, 결함 발견 | 프로세스 구현 및 개선 |
| 범위 | 품질 제어의 주요 활동 | 개발 및 테스팅 프로세스 전체 |

관계: 테스트 결과는 품질 보증과 테스팅 모두에 사용됨

테스팅: 결함 수정에 사용
품질 보증: 프로세스가 잘 작동하는지 확인하는 피드백으로 사용

FL-1.2.3 (K2) 근본 원인, 오류, 결함, 장애를 구별할 수 있다

답변:

근본 원인 → 오류 → 결함 → 장애

용어	정의	예시
근본 원인	문제 발생의 근본적 이유	시간 압박, 기술 부족, 의사소통 문제
오류(Error)	사람이 저지르는 실수	개발자가 "≤"를 "="로 잘못 코딩
결함(Defect)	작업 산출물의 불완전성	소스 코드의 버그, 요구사항 문서의 모호성
장애(Failure)	시스템이 요구된 작업을 수행하지 못하는 현상	10 이하 값에서만 작동해야 하는데 10에서 작동 안 함

흐름:
1. 시간 압박(근본 원인) → 2. 개발자 실수(오류) → 3. 코드 버그(결함) → 4. 시스템 비정상 작동(장애)

특징:

결함이 실행되면 항상 장애를 일으키는 것은 아님 (특정 조건에서만 발생)
환경 조건(방사선, 전자기장)도 장애 원인이 될 수 있음

FL-1.3.1 (K2) 테스팅의 7가지 원리를 설명할 수 있다

답변:

테스팅은 결함의 존재를 밝히지만, 부재를 증명하지 않는다
- 결함이 없음을 증명할 수 없음, 단지 잔존 확률만 줄일 수 있음
완벽한 테스팅은 불가능하다
- 모든 것을 테스트하는 것은 불가능
- 테스트 기법, 우선순위지정, 리스크 기반 테스팅으로 노력 집중
조기 테스팅으로 시간과 비용을 절약할 수 있다
- 초기 결함 발견 시 후속 결함 방지
- 정적/동적 테스팅 모두 최대한 조기 시작
결함은 집중된다
- 소수 컴포넌트에 대부분의 결함 집중 (파레토 원리)
- 리스크 기반 테스팅에서 중요 고려 사항
테스트 효과는 줄어든다
- 같은 테스트 반복 시 신규 결함 발견 효과 감소
- 테스트 수정 및 신규 테스트 필요
- 자동 리그레션 테스트는 예외
테스팅은 정황에 의존적이다
- 모든 상황에 적용 가능한 단일 접근법 없음
- 정황(도메인, 기술, 프로젝트)에 따라 다르게 진행
결함-부재는 궤변이다
- 모든 결함을 수정해도 사용자 요구 불충족 가능
- 베리피케이션 + 밸리데이션 모두 필요

FL-1.4.1 (K2) 다양한 테스트 활동과 관련된 업무를 설명할 수 있다

답변:

테스트 활동	주요 업무	산출물
테스트 계획	- 테스트 목적 정의 - 접근법 선택 - 제약 조건 고려	테스트 계획서
테스트 모니터링	- 테스트 활동 지속 점검 - 실제 vs 계획 비교	테스트 진행 보고서
테스트 제어	- 테스트 목적 달성 조치 - 일정/자원 조정	제어 지침 문서
테스트 분석	- 테스트 베이시스 분석 - 테스트 컨디션 정의 - 리스크 고려	테스트 컨디션, 결함 보고서
테스트 설계	- 테스트 케이스 구체화 - 커버리지 항목 식별 - 테스트 데이터 요구사항 정의	테스트 케이스, 테스트 차터
테스트 구현	- 테스트웨어 생성/획득 - 테스트 절차 작성 - 테스트 환경 구축	테스트 절차, 테스트 스크립트
테스트 실행	- 테스트 수행(수동/자동) - 실제 vs 기대 결과 비교 - 이상 사항 분석 및 보고	테스트 로그, 결함 보고서
테스트 완료	- 테스트웨어 보관 - 교훈 분석 - 완료 보고서 작성	테스트 완료 보고서, 교훈

FL-1.4.2 (K2) 정황이 테스트 프로세스에 미치는 영향을 설명할 수 있다

답변:

테스트 프로세스에 영향을 미치는 정황 요소:

이해관계자: 필요, 기대, 요구사항, 협력 의지
팀원: 기술, 지식, 경험, 가용성, 훈련 필요성
비즈니스 도메인: 중요도, 리스크, 시장 요구, 법적 규제
기술적 요인: 소프트웨어 유형, 아키텍처, 기술
프로젝트 제약: 범위, 시간, 예산, 자원
조직적 요인: 조직 구조, 정책, 적용 프랙티스
SDLC: 공학 프랙티스, 개발 방법론
도구: 가용성, 사용성, 규정 준수

영향을 받는 테스트 요소:

테스트 전략 및 테스트 기법 선택
테스트 자동화 수준
필요 커버리지 수준
테스트웨어 상세화 수준
테스트 보고 방식

예시:

안전 치명적 시스템: 높은 독립성, 공식 리뷰, 100% 분기 커버리지
애자일 프로젝트: 경험 기반 기법, 자동화 우선, 가벼운 문서
규제 산업: 상세 문서, 추적성 강화, 감사 대응

FL-1.4.3 (K2) 테스트 활동을 지원하는 테스트웨어를 구분할 수 있다

답변:

테스트 활동별 테스트웨어:

테스트 계획
├─ 테스트 계획서
├─ 테스트 일정
├─ 리스크 관리 대장
└─ 시작/완료 조건

테스트 모니터링/제어
├─ 테스트 진행 보고서
├─ 제어 지침 문서
└─ 리스크 정보

테스트 분석
├─ (우선순위 지정된) 테스트 컨디션
└─ 결함 보고서 (테스트 베이시스의 결함)

테스트 설계
├─ (우선순위 지정된) 테스트 케이스
├─ 테스트 차터
├─ 커버리지 항목
├─ 테스트 데이터 요구사항
└─ 테스트 환경 요구사항

테스트 구현
├─ 테스트 절차
├─ 수동/자동 테스트 스크립트
├─ 테스트 스위트
├─ 테스트 데이터
├─ 테스트 실행 일정
└─ 테스트 환경 요소 (스텁, 드라이버, 시뮬레이터)

테스트 실행
├─ 테스트 로그
└─ 결함 보고서

테스트 완료
├─ 테스트 완료 보고서
├─ 실천 항목 (개선사항)
├─ 문서화된 교훈
└─ 변경 요청서

형상 관리 대상: 모든 테스트웨어는 일관성과 무결성 보장을 위해 형상 관리가 필요

FL-1.4.4 (K2) 추적성을 유지하는 것의 가치를 설명할 수 있다

답변:

추적성(Traceability)이란:
테스트 베이시스의 개별 요소 ↔ 테스트웨어 ↔ 테스트 결과 ↔ 결함 간의 연결 관계

추적성의 가치:

커버리지 평가 지원
- 테스트 케이스 → 요구사항: 요구사항 커버리지 확인
- 테스트 결과 → 리스크: 잔존 리스크 수준 평가
- 예: "요구사항 100개 중 95개가 테스트 케이스로 커버됨"
변경 영향도 분석
- 요구사항 변경 시 영향받는 테스트 케이스 신속 파악
- 리그레션 테스트 범위 결정
- 예: "요구사항 A 변경 → 관련 테스트 케이스 5개 재실행 필요"
테스트 감사 용이
- IT 운영 및 관리 기준 충족 입증
- 규제 요구사항 준수 증명
- 예: "모든 안전 관련 요구사항이 테스트되었음을 추적성으로 증명"
테스트 보고 명확화
- 테스트 베이시스 요소의 상태 명시
- 이해관계자에게 기술적 내용을 이해하기 쉽게 전달
- 예: "고위험 요구사항 10개 중 8개 합격, 2개 실패"
비즈니스 목표 평가
- 제품 품질, 프로세스 역량, 프로젝트 진행 상황 평가
- 예: "비즈니스 크리티컬 기능 100% 테스트 완료"

FL-1.4.5 (K2) 테스팅에 참여하는 다양한 역할을 비교할 수 있다

답변:

역할	주요 책임	관심 활동	특징
테스트 관리 역할	- 테스트 프로세스 전반 책임 - 팀 리더십 - 테스트 활동 관리	- 테스트 계획 - 테스트 모니터링 - 테스트 제어 - 테스트 완료	- 팀 리더, 테스트 관리자, 개발 관리자 등이 수행 - 애자일: 팀이 일부 수행 가능
테스팅 역할	- 테스팅의 공학적 측면 책임 - 테스트 실제 수행	- 테스트 분석 - 테스트 설계 - 테스트 구현 - 테스트 실행	- 테스터, 테스트 분석가, 테스트 엔지니어 - 개발자도 수행 가능

상황에 따른 변화:

한 사람이 두 역할 동시 수행 가능
애자일:
- 팀이 테스트 관리 업무 일부 처리
- 조직 전체 협업은 외부 테스트 관리자
대형 프로젝트: 역할 분리
소형 프로젝트: 역할 통합

FL-1.5.1 (K2) 테스팅에 필요한 보편적인 기술의 예를 제시할 수 있다

답변:

테스터에게 필요한 보편적 기술:

테스팅 지식
- 테스트 기법 활용
- 예: 동등 분할, 경계값 분석 적용으로 효과적 테스트 케이스 도출
철저함, 신중함, 호기심, 세부사항 주의력
- 찾기 어려운 결함 식별
- 예: 특정 조건에서만 발생하는 간헐적 오류 발견
우수한 의사소통 기술, 경청, 팀플레이
- 이해관계자와 효과적 상호작용
- 결함 명확히 보고 및 논의
- 예: 개발자와 협력하여 결함 원인 분석
분석적 사고, 비판적 사고, 창의성
- 테스팅 효과 향상
- 예: 사용자 시나리오 기반 창의적 테스트 케이스 설계
기술 지식
- 적절한 테스트 도구 사용
- 예: 자동화 도구, 성능 테스트 도구 활용
도메인 지식
- 최종 사용자/비즈니스 대표자 이해 및 소통
- 예: 금융 도메인 지식으로 금융 규제 요구사항 테스트

특히 중요한 의사소통 기술:

나쁜 소식(결함) 전달 시 필수
확증 편향 극복
건설적 방식으로 결함/장애 정보 전달

FL-1.5.2 (K1) 전체 팀 접근법의 장점을 상기할 수 있다

답변:

전체 팀 접근법(Whole Team Approach)이란:

필요 지식과 기술을 갖춘 팀원이라면 누구나 어떤 작업이라도 수행
모든 팀원이 품질에 대한 책임 공유
(물리적/가상) 작업 공간 공유

장점:

팀 활력 증대
- 다양한 관점과 기술의 시너지
- 예: 개발자+테스터+비즈니스 담당자 협업으로 완성도 높은 사용자 스토리
의사소통과 협업 강화
- 작업 공간 공유로 즉각적 소통
- 예: 테스터가 개발 중 즉시 피드백 제공
다양한 기술 활용
- 팀이 가진 모든 역량 동원
- 예: 개발자의 테스팅 참여, 테스터의 설계 리뷰 참여
품질 책임 공유
- 테스터만의 책임이 아닌 팀 전체 책임
- 예: 개발자도 단위 테스트 작성, 비즈니스 담당자도 인수 테스트 참여
지식 공유와 학습
- 테스터가 테스팅 지식을 팀원과 공유
- 제품 개발에 영향력 발휘
- 예: 페어 프로그래밍, 페어 테스팅

적용 제한:

안전 치명적 시스템: 높은 테스팅 독립성 필요 시 부적합할 수 있음

FL-1.5.3 (K2) 독립적 테스팅의 장단점을 구분할 수 있다

답변:

독립성 수준:

없음 → 일정 수준 → 높음 → 매우 높음
저자   같은 팀      조직 내      조직 외
      동료        다른 팀      테스터

장점:

다른 관점의 결함 식별
- 배경, 기술 관점, 편향이 다름
- 예: 개발자가 못 본 사용성 문제를 독립 테스터가 발견
가정 검증 및 반증
- 명세 작성/구현 시 이해관계자의 가정 검증
- 예: "사용자가 이렇게 사용할 것"이라는 가정에 반례 제시
인지 편향 차이
- 저자와 테스터의 편향 차이로 효과적 결함 발견
- 예: 저자는 자신의 코드에 대한 확증 편향 보유

단점:

협업 저해 가능
- 개발팀과 차단되어 의사소통 어려움
- 예: "우리 vs 그들" 문화 형성
적대적 관계 발생 가능
- 결함 보고를 비난으로 인식
- 예: 개발자가 테스터를 적대시
책임감 손실
- 개발자가 품질 책임을 테스터에게 전가
- 예: "테스터가 찾을 거야" 태도
병목 및 비난 대상
- 출시 지연 시 테스터가 원인으로 지목
- 예: "테스팅이 느려서 출시가 늦어짐"

균형:

대부분 프로젝트: 여러 수준의 독립성 조합이 최선
- 예: 개발자(컴포넌트 테스트) + 독립 테스터(시스템 테스트) + 비즈니스 담당자(인수 테스트)

제 2장: SDLC와 테스팅 (130분)

📌 핵심 용어

용어	설명
인수 테스팅(acceptance testing)	시스템이 사용자 요구사항과 비즈니스 목표를 충족하는지 확인하는 테스트
블랙박스 테스팅(black-box testing)	내부 구조를 참조하지 않고 명세를 기반으로 하는 테스트
컴포넌트 통합 테스팅(component integration testing)	컴포넌트 간 인터페이스와 상호작용을 테스트
컴포넌트 테스팅(component testing)	개별 컴포넌트를 독립적으로 테스트 (단위 테스팅)
확인 테스팅(confirmation testing)	결함이 성공적으로 수정되었는지 확인하는 테스트
기능 테스팅(functional testing)	시스템이 수행해야 하는 기능을 평가하는 테스트
통합 테스팅(integration testing)	컴포넌트나 시스템 간 인터페이스 테스트
유지보수 테스팅(maintenance testing)	운영 중인 시스템의 변경사항을 테스트
비기능 테스팅(non-functional testing)	기능 외 속성(성능, 사용성 등)을 평가하는 테스트
리그레션 테스팅(regression testing)	변경으로 인한 부정적 영향이 없는지 확인하는 테스트
시프트 레프트(shift left)	테스팅을 SDLC 초기에 수행하는 접근법
시스템 통합 테스팅(system integration testing)	외부 시스템과의 인터페이스를 테스트
시스템 테스팅(system testing)	전체 시스템의 전반적 동작과 기능을 테스트
테스트 레벨(test level)	함께 구성하고 관리하는 테스트 활동 집합
테스트 대상(test object)	테스트되는 작업 산출물
테스트 유형(test type)	특정 품질 특성 관련 테스트 활동 집합
화이트박스 테스팅(white-box testing)	내부 구조와 처리를 기반으로 하는 테스트

🎯 학습 목표 및 답변

FL-2.1.1 (K2) SDLC가 테스팅에 미치는 영향을 설명할 수 있다

답변:

SDLC 모델 선택이 테스팅에 미치는 영향:

테스트 활동 범위 및 시기
- 순차적 모델(폭포수, V-모델): 초기 리뷰, 후반 동적 테스팅
- 반복적 모델: 각 반복마다 모든 테스트 레벨 수행
테스트 문서 상세화 수준
- 순차적: 상세한 테스트 계획서, 테스트 케이스
- 애자일: 가벼운 문서, 테스트 차터
테스트 기법 및 접근법 선택
- 순차적: 블랙박스 기법 중심
- 애자일: 경험 기반 기법(탐색적) 선호
테스트 자동화 범위
- 점진적 개발: 광범위한 리그레션 자동화 필수
- 순차적: 자동화 범위 제한적
테스터 역할과 책임
- 애자일: 전체 팀 접근법, 역할 유연
- 순차적: 독립된 테스트팀, 명확한 역할 구분

SDLC 유형별 특성:

SDLC 유형	테스팅 특성	예시
순차적	- 초기: 요구사항 리뷰 - 후반: 동적 테스팅 - 실행 코드 후반 생성	V-모델, 폭포수
반복적/점진적	- 반복마다 전체 레벨 - 동작 프로토타입 - 빠른 피드백 필요	나선형, 통합 프로세스
애자일	- 변화 수용 - 가벼운 산출물 - 자동화 선호 - 경험 기반 기법	Scrum, XP, Kanban

FL-2.1.2 (K1) 모든 SDLC에 적용되는 좋은 테스팅 프랙티스를 상기할 수 있다

답변:

SDLC에 관계없이 적용되는 좋은 테스팅 프랙티스:

개발 활동 ↔ 테스트 활동 매핑
- 모든 개발 활동에 상응하는 테스트 활동 배치
- 모든 개발 활동이 품질 제어 대상이 되도록
- 예: 요구사항 정의 → 요구사항 리뷰, 설계 → 설계 리뷰
테스트 레벨별 독립적 목적 설정
- 각 테스트 레벨마다 구체적 목적
- 중복 방지, 포괄적 테스팅
- 예:
  - 컴포넌트: 개별 기능 확인
  - 시스템: 엔드투엔드 시나리오
  - 인수: 비즈니스 가치 확인
조기 테스트 분석/설계 시작
- 각 개발 단계에서 해당 테스트 레벨의 분석/설계 시작
- 조기 테스팅 원리 준수
- 예: 요구사항 단계에서 시스템 테스트 분석 시작
리뷰 조기 참여
- 문서 초안 가용 즉시 리뷰 참여
- 조기 결함 발견
- 시프트 레프트 지원
- 예: 요구사항 명세 초안 리뷰

FL-2.1.3 (K1) 개발에서 테스트 우선 접근법의 예를 들 수 있다

답변:

세 가지 테스트 우선 접근법:

접근법	레벨	특징	예시
TDD (Test-Driven Development)	컴포넌트	- 테스트 먼저 작성 - 코드 작성 - 리팩토링 - 테스트 자동화 유지	1. assertEqual(add(2,3), 5) 작성 2. add() 함수 구현 3. 테스트 통과 4. 코드 개선
ATDD (Acceptance Test-Driven Development)	시스템/인수	- 인수 조건 기반 - 구현 전 테스트 작성 - 이해관계자 협업 - 명세 워크숍	1. "사용자가 로그인하면..." 2. 인수 조건 정의 3. 테스트 케이스 작성 4. 구현
BDD (Behavior-Driven Development)	시스템	- Given/When/Then 형식 - 자연어 표현 - 자동 실행 가능 - ATDD와 유사	Given 로그인 페이지 When 유효한 자격증명 입력 Then 메인 페이지 표시

공통점:

조기 테스팅 원리 준수
시프트 레프트 구현
자동화 테스트 유지
코드 품질 보장

FL-2.1.4 (K2) DevOps가 테스팅에 미치는 영향을 요약할 수 있다

답변:

DevOps란:
개발(테스팅 포함)과 운영이 협력하여 공통 목표를 달성하는 조직 차원 접근법

테스팅 관점의 이점:

빠른 피드백
- 코드 품질 즉시 확인
- 변경사항의 영향 신속 파악
- 예: 코드 커밋 후 5분 내 테스트 결과
시프트 레프트 장려
- CI: 개발자가 컴포넌트 테스트와 함께 코드 제출
- 정적 분석 자동 수행
- 예: 코드 커밋 시 자동 단위 테스트 + 정적 분석
안정적 테스트 환경
- CI/CD 자동화 프로세스
- 일관된 환경 구성
- 예: 컨테이너 기반 테스트 환경 자동 생성
비기능 품질 가시성
- 성능, 신뢰성 지속 모니터링
- 대시보드로 실시간 확인
- 예: 응답 시간, 처리량 추세 그래프
수동 테스트 감소
- 배포 파이프라인 자동화
- 반복 작업 제거
- 예: 리그레션 테스트 완전 자동화
리그레션 리스크 최소화
- 자동 리그레션 테스트 확대
- 매 빌드마다 실행
- 예: 10,000개 테스트 케이스 30분 내 실행

리스크와 어려움:

배포 파이프라인 정의/설정
- 초기 구축 노력 필요
- 예: Jenkins, GitLab CI/CD 파이프라인 구성
CI/CD 도구 도입/유지보수
- 도구 학습 및 관리
- 예: 도구 업그레이드, 플러그인 관리
테스트 자동화 자원
- 추가 인력/시간 필요
- 설정 및 유지보수 어려움
- 예: Selenium 스크립트 작성 및 유지보수
수동 테스팅 여전히 필요
- 특히 사용자 관점 테스트
- 예: 탐색적 테스팅, 사용성 테스팅

FL-2.1.5 (K2) 시프트 레프트 접근법을 설명할 수 있다

답변:

시프트 레프트(Shift Left)란:
테스팅을 SDLC 초기에 수행하여 조기 테스팅 원리를 실현하는 접근법

핵심 프랙티스:

명세 리뷰 (테스터 관점)

요구사항 초안 → 테스터 리뷰 → 모호성/불완전성 발견
결과: 구현 전 결함 제거

코드 작성 전 테스트 케이스 작성

테스트 케이스 작성 → 코드 구현 → 테스트 하네스 실행
기법: TDD, ATDD, BDD

CI/CD 적용

코드 커밋 → 자동 빌드 → 자동 테스트 → 빠른 피드백
결과: 즉각적 품질 확인

동적 테스팅 전 정적 분석

소스 코드 → 정적 분석 도구 → 결함 조기 발견
예: SonarQube로 코드 품질 검사

컴포넌트 레벨부터 비기능 테스팅

기존: 시스템 레벨에서만 성능 테스트
시프트 레프트: 컴포넌트 레벨부터 성능 테스트
예: 단위 성능 테스트

효과:

초기: 훈련, 공수, 비용 증가
후반: 공수와 비용 대폭 절감
전체: ROI 긍정적

성공 요인:
이해관계자의 개념 이해 및 수용

FL-2.1.6 (K2) 프로세스 개선을 위한 방법으로 회고의 사용을 설명할 수 있다

답변:

회고(Retrospective)란:
프로젝트/반복 주기 종료 시 팀이 경험을 돌아보고 개선점을 도출하는 활동

회고 시점:

프로젝트/반복 주기 종료
릴리스 마일스톤
필요 시 언제든

회고 참가자:
테스터, 개발자, 설계자, 제품 소유자, 비즈니스 분석가 등

논의 주제:

성공 요인 (유지할 것)
- 무엇이 잘 작동했는가?
- 예: "페어 프로그래밍으로 결함 50% 감소"
개선 영역 (바꿀 것)
- 무엇이 부족했는가?
- 예: "테스트 환경 준비 지연으로 일정 차질"
실행 계획 (어떻게 개선할 것인가)
- 개선사항 도입 방법
- 성공 요소 유지 방법
- 예: "다음 스프린트부터 환경 자동화 도입"

산출물:

기록된 교훈
실천 항목(Action Items)
테스트 완료 보고서에 포함

테스팅 관점의 이점:

이점	설명	예시
효과성/효율성 향상	프로세스 개선 구현	자동화로 테스트 시간 30% 단축
테스트웨어 품질	프로세스 함께 검토	테스트 케이스 템플릿 개선
팀 결속/학습	문제 제기 및 개선 기회	테스팅 모범 사례 공유
테스트 베이시스 개선	요구사항 부족 발견/수정	인수 조건 작성 가이드 마련
협업 개선	협업 과정 정기 최적화	개발-테스팅 일일 동기화 회의

성공 요소:

모든 권장 사항에 대한 후속 조치 필수
비난 없는 문화
안전한 환경

FL-2.2.1 (K2) 테스트 레벨을 구별할 수 있다

답변:

테스트 레벨이란:
특정 개발 단계의 소프트웨어와 관련해 수행하는 테스트 프로세스의 인스턴스

5가지 테스트 레벨 비교:

레벨	테스트 대상	주요 목적	담당자	기법	테스트 환경
컴포넌트 (단위)	개별 컴포넌트	컴포넌트 개별 동작	개발자	화이트박스	테스트 하네스
컴포넌트 통합 (단위 통합)	컴포넌트 간 인터페이스	인터페이스/ 상호작용	개발자	블랙박스/ 화이트박스	통합 환경
시스템	전체 시스템	전반적 동작/ 엔드투엔드	독립 테스터	블랙박스	실제 환경 대변
시스템 통합	외부 시스템 연계	외부 인터페이스	독립 테스터	블랙박스	운영 환경 유사
인수	전체 시스템	배포 준비/ 비즈니스 요구	실제 사용자	블랙박스	실제 운영 환경

인수 테스팅 유형:

UAT(User Acceptance Testing): 사용자 인수
OAT(Operational Acceptance Testing): 운영 인수
계약 인수, 규제 인수, 알파/베타 테스팅

레벨 간 관계:

컴포넌트 테스트 → 완료 조건 충족
    ↓
컴포넌트 통합 → 시작 조건 충족
    ↓
시스템 테스트 → 완료 조건
    ↓
시스템 통합 → 시작 조건
    ↓
인수 테스트 → 릴리스 결정

구분 속성:

테스트 대상
테스트 목적
테스트 베이시스
결함과 장애 유형
접근법과 역할

FL-2.2.2 (K2) 테스트 유형을 구별할 수 있다

답변:

테스트 유형이란:
특정 품질 특성 관련 테스트 활동 집합

4가지 테스트 유형:

유형	초점	테스트 대상	적용 기법	예시
기능 테스팅	"무엇을" 하는가	- 기능 완전성 - 기능 정확성 - 기능 적합성	블랙박스	로그인 기능, 계산 정확성, 워크플로우
비기능 테스팅	"얼마나 잘" 하는가	ISO 25010: - 성능 효율성 - 호환성 - 사용성 - 신뢰도 - 보안 - 유지보수성 - 이식성 - 안전성	블랙박스/ 화이트박스/ 경험 기반	응답 시간, 동시 사용자, UI 직관성, 가용성
블랙박스 테스팅	명세 기반	시스템 동작	- 동등 분할 - 경계값 - 결정 테이블 - 상태 전이	입력 유효성 검증, 비즈니스 규칙
화이트박스 테스팅	구조 기반	내부 구조/ 커버리지	- 구문 커버리지 - 분기 커버리지	코드 경로, 조건 분기

모든 레벨에서 모든 유형 적용 가능:

컴포넌트: 기능 + 비기능(성능) + 화이트박스
시스템: 기능 + 비기능(전체) + 블랙박스 + 경험 기반
인수: 기능 + 비기능(사용성) + 블랙박스

비기능 테스팅 특징:

SDLC 초기 시작 권장 (컴포넌트 레벨부터)
기능 테스트 기반 도출 가능
특수 테스트 환경 필요 시 있음 (예: 유용성 랩)

FL-2.2.3 (K2) 확인 테스팅을 리그레션 테스팅과 구별할 수 있다

답변:

구분	확인 테스팅	리그레션 테스팅
목적	결함이 성공적으로 수정되었는지 확인	변경으로 인한 부정적 영향이 없는지 확인
대상	특정 결함	변경된 영역 + 영향받을 수 있는 영역
실행 방법	1. 원래 실패한 TC 재실행 2. 또는 수정 확인용 신규 TC	영향도 분석 기반 TC 선택 실행
시점	결함 수정 직후	확인 테스팅 후
범위	좁음 (특정 결함)	넓음 (관련 기능 전체)
자동화	선택적	강력 권장 (반복 실행)

프로세스 흐름:

1. 결함 발견 (테스트 실행)
    ↓
2. 결함 보고 (결함 관리)
    ↓
3. 디버깅 (개발자)
    ↓
4. 확인 테스팅
   - 원래 실패 TC 재실행
   - 또는 새 TC로 수정 확인
    ↓
5. 리그레션 테스팅
   - 영향도 분석
   - 관련 TC 선택 실행
   - 자동화 활용

리그레션 테스팅 특징:

범위 결정
- 영향도 분석 선행
- 추적성 활용
- 예: 요구사항 A 변경 → 관련 TC 파악
대상
- 변경된 컴포넌트
- 같은 시스템의 다른 컴포넌트
- 연결된 다른 시스템
- 환경
반복 실행
- 테스트 스위트 지속 확장
- 자동화 적합
- CI/CD 통합
모든 레벨 적용
- 컴포넌트 ~ 인수 테스트
- 각 레벨에서 결함 수정 시 수행

예시:

상황: 로그인 모듈 결함 수정
확인 테스팅: "잘못된 비밀번호 5회 입력 시 계정 잠금" 테스트
리그레션 테스팅:
  - 로그인 관련 전체 TC (정상 로그인, 로그아웃 등)
  - 세션 관리 TC
  - 권한 관련 TC

FL-2.3.1 (K2) 유지보수 테스팅과 유발요인을 요약할 수 있다

답변:

유지보수 테스팅이란:
운영 중인 시스템의 변경사항을 테스트하는 활동

유지보수 범위 결정 요소:

변경의 리스크 수준
기존 시스템 크기
변경사항 크기

유발요인과 테스팅 활동:

유발요인	테스팅 활동	예시
계획된 개선/수정	- 변경 검증 (확인 테스팅) - 영향도 테스트 (리그레션) - 영향도 분석 선행	- 신규 기능 추가 - 버그 수정 - 핫픽스
핫픽스	- 긴급 확인 테스팅 - 제한적 리그레션	보안 취약점 긴급 패치
환경 업그레이드	- 환경 호환성 테스트 - 마이그레션 테스트 - 비기능 테스트	- OS 업그레이드 - DB 버전 업 - 플랫폼 이전
데이터 마이그레이션	- 데이터 변환 테스트 - 무결성 테스트	레거시 → 신규 시스템
애플리케이션 단종	- 데이터 보관 테스트 - 복원/복구 테스트 - 장기 보관 테스트	- 시스템 폐기 - 데이터 아카이빙

영향도 분석:

변경 전 → 영향도 분석 → 영향 범위 파악 → 테스트 범위 결정
       ↓
   리스크 평가

유지보수 테스팅 특징:

계획된/계획되지 않은 모두 포함
변경된 부분 + 영향받는 부분
리그레션 테스팅 중요도 높음
자동화 필수적

예시:

시나리오: 결제 모듈 성능 개선
1. 영향도 분석:
   - 결제 프로세스
   - 주문 관리
   - 재고 관리 (연계)
2. 유지보수 테스팅:
   - 확인: 성능 개선 확인
   - 리그레션: 결제/주문/재고 전체 TC
   - 비기능: 응답 시간, 동시 처리

제 3장: 정적 테스팅 (80분)

📌 핵심 용어

용어	설명
이상 사항(anomaly)	기대하지 않은 또는 표준을 벗어난 상태
동적 테스팅(dynamic testing)	소프트웨어를 실행하여 테스트하는 활동
공식 리뷰(formal review)	문서화된 절차를 따르는 체계적 리뷰
비공식 리뷰(informal review)	정의된 프로세스 없이 수행하는 리뷰
인스펙션(inspection)	가장 공식적인 리뷰 유형
리뷰(review)	작업 산출물을 평가하는 활동
정적 분석(static analysis)	도구를 사용하여 코드를 분석하는 활동
정적 테스팅(static testing)	실행 없이 작업 산출물을 평가하는 활동
기술 리뷰(technical review)	기술적 자격을 갖춘 리뷰어가 수행하는 리뷰
워크쓰루(walkthrough)	저자가 리더가 되는 리뷰

🎯 학습 목표 및 답변

FL-3.1.1 (K1) 정적 테스팅으로 검토할 수 있는 작업 산출물 유형을 인식할 수 있다

답변:

정적 테스팅 가능한 작업 산출물:

리뷰 대상 (읽고 이해 가능한 모든 것)
- 요구사항 명세서
- 사용자 스토리, 인수 조건
- 설계 문서, 아키텍처 문서
- 소스 코드
- 테스트 계획서, 테스트 케이스
- 테스트 차터, 제품 백로그 항목
- 프로젝트 문서, 계약서
- 모델 (UML, ERD 등)
- 웹 페이지 콘텐츠
정적 분석 대상 (구조가 있는 것)
- 소스 코드
- 모델 (공식 문법)
- 구조화된 문서

부적합한 산출물:

사람이 해석하기 어려운 것
법적 문제가 있는 타사 실행 코드
바이너리 파일

예시:

리뷰 가능:
✓ 요구사항: "시스템은 1000명 동시 접속을 지원해야 한다"
✓ 코드: if (user.isValid()) { login(); }
✓ 테스트 케이스: "로그인 TC-001"

정적 분석 가능:
✓ 소스 코드 → 복잡도 분석, 코딩 표준 검사
✓ UML 모델 → 일관성 검사

부적합:
✗ 컴파일된 .exe 파일
✗ 타사 라이브러리 바이너리

FL-3.1.2 (K2) 정적 테스팅의 가치를 설명할 수 있다

답변:

정적 테스팅의 가치:

조기 결함 식별
- SDLC 초기 단계에서 결함 발견
- 조기 테스팅 원리 실현
- 예: 요구사항 단계에서 모호성 발견 → 구현 전 수정
동적 테스팅으로 불가능한 결함 발견
- 도달 불가능한 코드
- 잘못 구현된 설계 패턴
- 비-실행 산출물의 결함
- 예:
  - Dead code 식별
  - 요구사항 문서의 모순 발견
품질 평가 및 신뢰 구축
- 작업 산출물 품질 객관적 평가
- 이해관계자 신뢰 증대
- 예: 코드 복잡도 메트릭으로 유지보수성 평가
요구사항 조기 밸리데이션
- 이해관계자가 요구사항 확인
- 자신의 필요사항이 정확히 반영되었는지 검증
- 예: 비즈니스 담당자가 사용자 스토리 리뷰
공통 이해 형성
- 이해관계자 간 의사소통 개선
- 요구사항에 대한 합의
- 예: 리뷰 회의에서 용어 정의 통일
비용 효율성
- 초기 결함 수정 비용 << 후반 수정 비용
- 전체 프로젝트 비용 절감
- 예: 요구사항 결함 수정 비용 1 : 개발 후 수정 비용 100
개발 노력 감소
- 정적 분석으로 코드 결함 조기 발견
- 동적 테스팅보다 효율적
- 예: SonarQube로 보안 취약점 자동 발견

FL-3.1.3 (K2) 정적 테스팅과 동적 테스팅을 비교하고 대조할 수 있다

답변:

구분	정적 테스팅	동적 테스팅
실행 여부	실행하지 않음	실행 필요
결함 발견 방식	결함 직접 식별	장애 유발 → 분석 → 결함 찾기
적용 대상	- 모든 작업 산출물 - 실행/비-실행 모두	실행 가능한 산출물만
적용 시기	SDLC 초기부터 가능	코드 완성 후
기법	- 리뷰 - 정적 분석	- 테스트 케이스 실행 - 테스트 기법 적용
장애 의존	장애 없이 결함 발견	장애를 통해 결함 추론

유사점:

둘 다 결함 식별 목적
둘 다 품질 평가
둘 다 테스팅 활동

정적 테스팅만 가능한 결함 예시:

요구사항 불일치, 모호성, 모순, 누락
설계 결함 (비효율적 DB 구조, 모듈화 불량)
도달 불가능한 코드, 정의되지 않은 변수
표준 위반 (명명 규칙)
잘못된 인터페이스 명세
보안 취약성 (버퍼 오버플로우)
테스트 베이시스 커버리지 gap

동적 테스팅만 가능한 결함 예시:

런타임 메모리 누수
실제 성능 문제
동시성 문제 (Race condition)
실제 환경에서만 나타나는 통합 문제

품질 특성 측정:

정적: 유지보수성, 보안(코드 분석)
동적: 성능 효율성, 신뢰성

보완 관계:

정적 + 동적 = 포괄적 테스팅
├─ 정적: 조기 결함, 비-실행 산출물, 도달 어려운 경로
└─ 동적: 런타임 동작, 통합, 성능

FL-3.2.1 (K1) 이해관계자 피드백을 조기에 자주 받을 때의 이점을 식별할 수 있다

답변:

조기/빈번 피드백의 이점:

잠재적 품질 문제 조기 파악
- 개발 초기에 문제 발견
- 수정 비용 최소화
- 예: 프로토타입 단계에서 UI 개선 → 재작업 방지
오해 방지
- 요구사항에 대한 공통 이해
- 잘못된 가정 조기 수정
- 예: "보고서 출력"의 의미를 PDF로 통일
요구사항 변경 조기 반영
- 변화하는 요구사항 빠르게 수용
- 비용 증가 전 대응
- 예: 시장 변화에 따른 기능 조정
제품 이해도 향상
- 개발팀의 제품 이해 증진
- 구현 방향 명확화
- 예: 도메인 전문가 피드백으로 비즈니스 규칙 정확히 이해
중요 기능에 집중
- 이해관계자에게 중요한 것 우선
- 식별된 리스크에 긍정적 영향
- 예: 핵심 비즈니스 기능 우선 개발/테스트
재작업 방지
- 잘못된 방향 조기 수정
- 납기일 지연 방지
- 예: 설계 단계 피드백으로 대규모 코드 수정 회피
프로젝트 실패 방지
- 이해관계자 참여 부족 → 요구 불충족
- 조기/빈번 피드백 → 성공 확률 증가
- 예: 사용자 대표가 매 스프린트 리뷰 참여

FL-3.2.2 (K2) 리뷰 프로세스에서 수행하는 활동을 요약할 수 있다

답변:

리뷰 프로세스 5단계:

1. 계획 → 2. 착수 → 3. 개별 리뷰 → 4. 논의/분석 → 5. 수정/보고

단계	활동	산출물	예시
1. 계획	- 범위/목적 정의 - 리뷰 대상 선정 - 품질 특성 지정 - 완료 조건 설정 - 표준 선택 - 공수/일정 결정	리뷰 계획	- 대상: 로그인 모듈 설계서 - 목적: 보안 검증 - 완료: 심각도 高 결함 0개 - 일정: 5일
2. 착수	- 리뷰 준비 확인 - 접근 권한 확인 - 역할/책임 설명 - 필요 자료 배포	착수 완료 확인	- 리뷰어에게 설계서 배포 - 체크리스트 제공 - 역할 할당 - 일정 공지
3. 개별 리뷰	- 리뷰 기법 적용 - 이상 사항 식별 - 권장 사항 기록 - 의문 사항 기록	이상 사항 목록	- 체크리스트 기반 검토 - "암호 길이 제한 누락" 발견 - "2FA 권장" 제안
4. 논의/ 분석	- 이상 사항 분석 - 상태 결정 (결함/아님) - 담당자 지정 - 조치 사항 결정 - 품질 수준 평가 - 후속 리뷰 결정	리뷰 회의록, 결함 목록	- 회의: 10개 이상 사항 논의 - 7개 결함, 3개 개선 사항 - 우선순위: 높음 2, 중간 5 - 담당: 설계자 A씨 - 후속: 수정 후 재리뷰
5. 수정/ 보고	- 결함 보고서 작성 - 추적 가능하게 - 완료 조건 확인 - 승인 여부 결정 - 결과 보고	결함 보고서, 리뷰 완료 보고서	- 7개 결함 보고서 - 수정 후 확인 - 조건 충족 → 승인 - 관리자에게 보고

큰 작업 산출물:

여러 번 리뷰 프로세스 반복
예: 300페이지 요구사항 → 50페이지씩 6회

FL-3.2.3 (K1) 리뷰를 수행할 때 주요 역할별로 어떤 책임이 부여되는지 상기할 수 있다

답변:

역할	주요 책임	활동	비고
관리자 (Manager)	- 리뷰 대상 결정 - 자원 제공 (인력, 시간)	- 리뷰 승인 - 자원 배정 - 일정 조정	프로젝트 관리자, 부서장
저자 (Author)	- 산출물 작성 - 결함 수정	- 산출물 제공 - 질의 응답 - 수정 수행	개발자, 분석가, 설계자
중재자 (Moderator/ Facilitator)	- 리뷰 회의 효과적 운영 - 시간 관리 - 안전한 환경 조성	- 회의 진행 - 토론 중재 - 발언 기회 제공 - 갈등 해소	숙련된 리뷰어, 중립적 역할
서기 (Scribe/ Recorder)	- 이상 사항 수집 - 리뷰 정보 기록	- 결함 기록 - 결정 사항 기록 - 회의록 작성	리뷰 회의에서 문서화 담당
리뷰어 (Reviewer)	- 리뷰 수행 - 이상 사항 식별	- 개별 리뷰 - 이상 사항 제출 - 회의 참여	- 프로젝트 팀원 - 주제 전문가 - 이해관계자
리뷰 리더 (Review Leader)	- 리뷰 전반 책임 - 참여자 선정 - 일정 협의	- 리뷰 계획 - 참여자 초대 - 장소 예약 - 진행 관리	공식 리뷰에서 주로 필요

역할 겸임:

한 사람이 여러 역할 가능
예: 중재자 + 서기
단, 인스펙션: 저자는 리뷰 리더/서기 불가

리뷰 유형별 역할:

비공식 리뷰: 최소 역할 (저자 + 리뷰어)
워크쓰루: 저자가 리더
기술 리뷰: 중재자가 리더
인스펙션: 모든 역할 명확히 구분

FL-3.2.4 (K2) 다양한 리뷰 유형을 비교하고 대조할 수 있다

답변:

리뷰 유형	공식성	리더	주요 목적	개별 리뷰	특징	적용
비공식 리뷰	낮음	없음	이상 사항 식별	선택	- 정의된 프로세스 없음 - 공식 문서 없음 - 빠르고 유연	- 빠른 피드백 - 동료 검토 - 아이디어 공유
워크쓰루	중간	저자	- 품질 평가 - 신뢰 구축 - 교육 - 합의 - 아이디어 - 동기 부여 - 이상 사항 발견	선택 (필수 아님)	- 저자 주도 - 여러 목적 - 시나리오 기반 - 건식/습식	- 설계 리뷰 - 교육 목적 - 합의 도출
기술 리뷰	중간	중재자	- 기술 결정 - 합의 - 이상 사항 식별 - 품질 평가 - 신뢰 구축 - 아이디어	필수	- 기술 전문가 - 기술적 자격 - 중재자 리드 - 체크리스트	- 아키텍처 검토 - 설계 패턴 - 기술 선택
인스펙션	높음	리뷰 리더	- 최대 결함 발견 - 품질 평가 - 신뢰 구축 - 동기 부여 - 메트릭 수집	필수	- 가장 공식적 - 철저한 프로세스 - 저자 ≠ 리더/서기 - 메트릭 - 프로세스 개선	- 안전 치명적 - 고위험 산출물 - 표준 준수 필수 - 품질 최우선

선택 기준:

필요 사항                  → 권장 리뷰 유형
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
빠른 피드백               → 비공식 리뷰
교육 및 지식 공유         → 워크쓰루
기술적 의사결정           → 기술 리뷰
최대 결함 발견            → 인스펙션
프로세스 개선 데이터      → 인스펙션
표준 준수 검증            → 인스펙션
안전/미션 치명적          → 인스펙션

예시:

상황: 결제 모듈 설계 리뷰

1차 (비공식): 동료와 설계 아이디어 논의
2차 (워크쓰루): 설계자가 팀에게 설계 설명, 피드백 수집
3차 (기술 리뷰): 아키텍트와 보안 전문가 참여, 기술적 검증
4차 (인스펙션): 정식 프로세스로 최종 승인 전 철저 검토

FL-3.2.5 (K1) 성공적인 리뷰에 기여하는 요소를 상기할 수 있다

답변:

리뷰 성공 요소:

명확한 목표와 측정 가능한 완료 조건
- 목표: "보안 취약점 발견"
- 완료 조건: "심각도 高 결함 0개"
- ❌ 참가자 평가 목적
적합한 리뷰 유형 선택
- 목표 달성 가능한 유형
- 작업 산출물에 맞는 유형
- 정황 고려
- 예: 고위험 산출물 → 인스펙션
작은 단위로 리뷰
- 집중력 유지
- 회의 효과성 증대
- 예: 50페이지씩 분할
피드백 제공
- 이해관계자에게 결과 공유
- 저자에게 개선 방향 제시
- 제품 및 활동 개선
- 예: 리뷰 완료 보고서
충분한 준비 시간
- 리뷰어가 개별 리뷰 수행
- 품질 높은 이상 사항 식별
- 예: 배포 후 3일 준비 기간
관리층 지원
- 리뷰 프로세스 승인
- 자원 제공
- 리뷰 문화 장려
- 예: 리뷰 시간을 공식 일정에 포함
조직 문화의 일부
- 학습 및 개선 촉진
- 비난 없는 문화
- 지속적 프로세스
- 예: "결함은 배울 기회"
적절한 교육
- 역할별 교육 제공
- 리뷰 기법 습득
- 효과적 수행 방법
- 예: 중재자 퍼실리테이션 교육
퍼실리테이션
- 회의 효과적 진행
- 갈등 관리
- 안전한 환경
- 예: 모든 의견 존중, 시간 관리

제 4장: 테스트 분석과 설계 (390분)

📌 핵심 용어

용어	설명
인수 조건(acceptance criteria)	사용자 스토리 구현 결과를 승인하기 위해 충족되어야 하는 조건
인수 테스트 주도 개발(ATDD)	인수 조건 기반의 테스트 우선 접근법
블랙박스 테스트 기법	내부 구조를 참조하지 않고 명세를 기반으로 하는 테스트 기법
경계값 분석(boundary value analysis)	분할의 경계에 있는 값을 테스트하는 기법
분기 커버리지(branch coverage)	실행된 분기의 비율
체크리스트 기반 테스팅	체크리스트를 활용하여 테스트하는 기법
협업 기반 테스트 접근법	협업과 커뮤니케이션을 통한 테스트 접근법
커버리지(coverage)	테스트가 대상을 얼마나 다루었는지를 나타내는 측정치
커버리지 항목(coverage item)	테스트 기법이 다루는 대상 요소
결정 테이블 테스팅	조건 조합과 결과를 테이블로 표현하여 테스트하는 기법
동등 분할(equivalence partitioning)	데이터를 동일하게 처리되는 분할로 나누는 기법
오류 추정(error guessing)	테스터의 지식을 기반으로 오류를 예측하는 기법
경험 기반 테스트 기법	테스터의 지식과 경험을 활용하는 테스트 기법
탐색적 테스팅(exploratory testing)	학습, 설계, 실행을 동시에 하는 테스트 기법
상태 전이 테스팅	상태 다이어그램을 기반으로 테스트하는 기법
구문 커버리지(statement coverage)	실행된 구문의 비율
테스트 기법(test technique)	테스트 분석과 설계를 지원하는 체계적 방법
화이트박스 테스트 기법	내부 구조를 기반으로 하는 테스트 기법

🎯 학습 목표 및 답변

FL-4.1.1 (K2) 블랙박스, 화이트박스, 경험 기반 테스트 기법을 구별할 수 있다

답변:

기법 유형	기반	특징	적용 시기	주요 기법	장점	단점
블랙박스 (명세 기반)	명세, 요구사항	- 내부 구조 무관 - 동작 중심 - 구현 독립적	명세 완성 후 구현 전후 가능	- 동등 분할 - 경계값 - 결정 테이블 - 상태 전이	- 사용자 관점 - 구현 변경 시 테스트 유효 - 체계적	누락 요구사항 발견 어려움
화이트박스 (구조 기반)	내부 구조, 코드	- 구현 의존 - 커버리지 측정 - 코드 경로	설계/구현 후	- 구문 커버리지 - 분기 커버리지 - 경로 테스팅	- 내부 논리 검증 - 커버리지 측정 - 도달 어려운 경로 테스트	- 명세 모호 시 효과적 - 누락 요구사항 발견 못 함
경험 기반	테스터 지식/경험	- 개인 역량 의존 - 직관적 - 유연	언제든지	- 오류 추정 - 탐색적 - 체크리스트	- 다른 기법으로 못 찾는 결함 - 신속 - 보완적	- 일관성 낮음 - 재현성 낮음 - 역량 의존

보완 관계:

블랙박스 → 명세 커버
    +
화이트박스 → 코드 커버
    +
경험 기반 → Gap 발견
    =
포괄적 테스팅

적용 예시:

로그인 기능 테스트

블랙박스:
- 유효한 ID/PW → 로그인 성공
- 무효한 ID/PW → 로그인 실패
- 경계값: 최대 길이 ID

화이트박스:
- 모든 if문 실행 확인
- 암호화 함수 경로 커버

경험 기반:
- SQL Injection 시도
- 동시 로그인 테스트
- 브라우저 뒤로가기 후 접근

FL-4.2.1 (K3) 동등 분할을 사용해 테스트 케이스를 도출할 수 있다

답변:

동등 분할(Equivalence Partitioning):
테스트 대상이 하나의 분할에 속한 모든 요소를 동일하게 처리한다는 가정하에 데이터를 분할로 나누는 기법

기본 원리:

한 분할의 어떤 값으로 결함 발견 시, 같은 분할의 다른 값도 같은 결함 발견
각 분할당 1개 테스트만 필요

적용 방법:

분할 식별

예: 할인율 계산
- 구매액 0~999원: 할인 없음
- 구매액 1000~4999원: 5% 할인
- 구매액 5000원 이상: 10% 할인

유효/비유효 분할

유효 분할:
- VP1: 0~999 (할인 0%)
- VP2: 1000~4999 (할인 5%)
- VP3: 5000 이상 (할인 10%)

비유효 분할:
- IP1: 음수
- IP2: 문자
- IP3: 공백

테스트 케이스 도출

TC1: 구매액 = 500 (VP1) → 할인 0%
TC2: 구매액 = 3000 (VP2) → 할인 5%
TC3: 구매액 = 7000 (VP3) → 할인 10%
TC4: 구매액 = -100 (IP1) → 오류 메시지
TC5: 구매액 = "abc" (IP2) → 오류 메시지
TC6: 구매액 = null (IP3) → 오류 메시지

커버리지 계산

커버리지 = 실행된 분할 수 / 전체 분할 수 × 100%

6개 분할 모두 실행 시: 6/6 × 100% = 100%

여러 분할 집합:

예: 사용자 등록
- 나이: [0-17], [18-64], [65+], [음수], [문자]
- 국가: [KR], [US], [기타], [공백]

이치 초이스 커버리지:
각 분할 집합의 모든 분할을 최소 1회 실행

TC1: 나이=25, 국가=KR
TC2: 나이=15, 국가=US
TC3: 나이=70, 국가=JP
TC4: 나이=-5, 국가=공백
TC5: 나이=abc, 국가=KR (필요시)

특징:

연속적/불연속적 분할 가능
분할 간 겹치지 않음
공집합 불가
체계적 테스트 케이스 생성

FL-4.2.2 (K3) 경계값 분석을 사용해 테스트 케이스를 도출할 수 있다

답변:

경계값 분석(Boundary Value Analysis):
동등 분할의 경계 실행을 기반으로, 정렬된 분할의 경계값을 테스트하는 기법

기본 원리:

개발자가 경계 처리 시 오류를 범하기 쉬움
경계값과 인접 값을 테스트

두 가지 유형:

1. 두 개 선택 BVA (2-value)

각 경계값당 2개 커버리지 항목
- 경계값 자체
- 인접 분할의 가장 가까운 값

예: [1-10], [11-20], [21-30]

경계 10:
  - 경계값: 10
  - 인접값: 11

경계 11:
  - 경계값: 11
  - 인접값: 10

경계 20:
  - 경계값: 20
  - 인접값: 21

경계 21:
  - 경계값: 21
  - 인접값: 20

2. 세 개 선택 BVA (3-value)

각 경계값당 3개 커버리지 항목
- 경계값 자체
- 양쪽 인접값 모두

예: [1-10], [11-20], [21-30]

경계 10:
  - 9 (아래)
  - 10 (경계)
  - 11 (위)

경계 11:
  - 10 (아래)
  - 11 (경계)
  - 12 (위)

경계 20:
  - 19 (아래)
  - 20 (경계)
  - 21 (위)

실전 적용 예시:

요구사항: 나이 입력 (18-65세 유효)

분할:
- VP1: 18-65 (유효)
- IP1: 1-17 (미성년)
- IP2: 66-120 (고령)
- IP3: ≤0 (무효)
- IP4: >120 (무효)

두 개 선택 BVA:

경계 18:
TC1: 17 (IP1)
TC2: 18 (VP1, 경계)

경계 65:
TC3: 65 (VP1, 경계)
TC4: 66 (IP2)

경계 0:
TC5: 0 (IP3, 경계)
TC6: 1 (IP1)

세 개 선택 BVA:

경계 18:
TC1: 17 (아래)
TC2: 18 (경계)
TC3: 19 (위)

경계 65:
TC4: 64 (아래)
TC5: 65 (경계)
TC6: 66 (위)

커버리지 계산:

두 개 선택:
- 경계값 수: 4개 (0, 1, 17, 18, 65, 66, 120, 121 중 주요)
- 커버리지 = 실행 경계값 / 전체 경계값 × 100%

세 개 선택:
- 경계값+인접값 수: 12개
- 커버리지 = 실행 항목 / 전체 항목 × 100%

세 개 선택의 장점:

잘못 구현: if (x=10) ... (정상: if (x≤10) ...)

두 개 선택: x=10, x=11 → 결함 미발견
세 개 선택: x=9, x=10, x=11 → x=9로 결함 발견 가능

FL-4.2.3 (K3) 결정 테이블 테스팅을 사용해 테스트 케이스를 도출할 수 있다

답변:

결정 테이블 테스팅:
서로 다른 조건 조합에 따른 결과를 표로 나타내어 테스트하는 기법

구성 요소:

행: 조건과 동작
열: 결정 규칙 (조건 조합 + 결과 동작)

표기법:

조건:
- T (참): 조건 충족
- F (거짓): 조건 불충족
- - (상관없음): 결과에 영향 없음
- N/A: 실행 불가능

동작:
- X: 동작 발생
- 공백: 동작 미발생

작성 예시:

요구사항: 대출 승인
- 조건1: 신용등급 A 이상
- 조건2: 소득 3000만원 이상
- 조건3: 기존 대출 없음
- 동작1: 대출 승인
- 동작2: 추가 심사 필요
- 동작3: 대출 거부

결정 테이블:

규칙     | R1  | R2  | R3  | R4  | R5  | R6  | R7  | R8
---------|-----|-----|-----|-----|-----|-----|-----|-----
조건1(신용)| T   | T   | T   | T   | F   | F   | F   | F
조건2(소득)| T   | T   | F   | F   | T   | T   | F   | F
조건3(기존)| T   | F   | T   | F   | T   | F   | T   | F
---------|-----|-----|-----|-----|-----|-----|-----|-----
동작1(승인)| X   |     |     |     |     |     |     |
동작2(심사)|     | X   | X   | X   | X   | X   |     |
동작3(거부)|     |     |     |     |     |     | X   | X

최소화 테이블:

일부 조건이 결과에 영향 없는 경우 병합

규칙     | R1  | R2  | R3  | R4
---------|-----|-----|-----|-----
조건1(신용)| T   | T   | F   | F
조건2(소득)| T   | -   | -   | F
조건3(기존)| T   | F   | T   | -
---------|-----|-----|-----|-----
동작1(승인)| X   |     |     |
동작2(심사)|     | X   | X   |
동작3(거부)|     |     |     | X

규칙 수 감소: 8 → 4

테스트 케이스 도출:

TC1 (R1): 신용=A, 소득=5000, 기존=없음 → 승인
TC2 (R2): 신용=A, 소득=2000, 기존=있음 → 추가심사
TC3 (R3): 신용=C, 소득=4000, 기존=없음 → 추가심사
TC4 (R4): 신용=C, 소득=2000, 기존=상관없음 → 거부

커버리지:

커버리지 = 실행된 열 수 / 실행 가능한 열 수 × 100%

4개 규칙 모두 실행: 4/4 × 100% = 100%

장점:

모든 조건 조합 체계적 식별
누락/모순 요구사항 발견
복잡한 비즈니스 규칙 명확화

단점:

조건 많으면 규칙 수 기하급수 증가 (2^n)
최소화 또는 리스크 기반 선택 필요

FL-4.2.4 (K3) 상태 전이 테스팅을 사용해 테스트 케이스를 도출할 수 있다

답변:

상태 전이 테스팅:
상태 다이어그램이나 상태 테이블을 기반으로 테스트하는 기법

구성 요소:

상태(State): 시스템의 특정 조건
전이(Transition): 상태 간 이동
이벤트(Event): 전이를 유발하는 요인
가드 조건(Guard): 전이 조건
동작(Action): 전이 시 수행 작업

전이 표기:

이벤트 [가드 조건] / 동작

예시: ATM 시스템

상태 다이어그램:

[대기] --카드삽입--> [PIN입력]
[PIN입력] --올바른PIN--> [메뉴]
[PIN입력] --잘못된PIN(시도<3)--> [PIN입력]
[PIN입력] --잘못된PIN(시도=3)--> [카드압류]
[메뉴] --출금선택--> [출금]
[출금] --출금완료--> [메뉴]
[메뉴] --카드반환--> [대기]

상태 테이블:

현재상태\이벤트 | 카드삽입 | 올바른PIN | 잘못된PIN | 출금선택 | 출금완료 | 카드반환
----------------|---------|----------|-----------|---------|---------|--------
대기            | PIN입력  | -        | -         | -       | -       | -
PIN입력         | -       | 메뉴      | PIN입력   | -       | -       | -
                |         |          | /카드압류  |         |         |
메뉴            | -       | -        | -         | 출금     | -       | 대기
출금            | -       | -        | -         | -       | 메뉴     | -
카드압류        | -       | -        | -         | -       | -       | -

커버리지 기준:

1. 모든 상태 커버리지

목표: 모든 상태를 최소 1회 방문

TC1: 대기 → PIN입력 → 메뉴 → 출금 → 메뉴 → 대기
커버: 대기, PIN입력, 메뉴, 출금 (4개)

TC2: 대기 → PIN입력 → (3회 실패) → 카드압류
커버: 카드압류 추가 (5개 완료)

커버리지 = 5/5 × 100% = 100%

2. 유효 전이 커버리지 (0-스위치)

목표: 모든 유효 전이를 최소 1회 실행

유효 전이:
1. 대기 → PIN입력
2. PIN입력 → 메뉴
3. PIN입력 → PIN입력 (재시도)
4. PIN입력 → 카드압류
5. 메뉴 → 출금
6. 출금 → 메뉴
7. 메뉴 → 대기

TC1: 대기 →(1)→ PIN입력 →(2)→ 메뉴 →(5)→ 출금 →(6)→ 메뉴 →(7)→ 대기
커버: 1,2,5,6,7

TC2: 대기 → PIN입력 →(3)→ PIN입력 →(3)→ PIN입력 →(4)→ 카드압류
커버: 3,4

커버리지 = 7/7 × 100% = 100%

3. 모든 전이 커버리지

목표: 유효 전이 + 비유효 전이 시도

비유효 전이 (오류 처리):
- 대기에서 올바른PIN: 무시/오류
- 메뉴에서 카드삽입: 무시/오류
- 출금에서 잘못된PIN: 무시/오류
등...

각 비유효 전이마다 별도 TC 작성
(결함 마스킹 방지)

TC_invalid_1: 대기 상태에서 올바른PIN 입력 → 오류 확인
TC_invalid_2: 메뉴에서 카드삽입 시도 → 무시 확인
...

전체 전이 = 유효 7개 + 비유효 N개

테스트 케이스 예시:

TC1: 정상 흐름
1. 카드 삽입 (대기 → PIN입력)
2. 올바른 PIN (PIN입력 → 메뉴)
3. 출금 선택 (메뉴 → 출금)
4. 출금 완료 (출금 → 메뉴)
5. 카드 반환 (메뉴 → 대기)

TC2: PIN 재시도
1. 카드 삽입
2. 잘못된 PIN (PIN입력 → PIN입력)
3. 올바른 PIN (PIN입력 → 메뉴)
4. 카드 반환

TC3: 카드 압류
1. 카드 삽입
2. 잘못된 PIN 1회
3. 잘못된 PIN 2회
4. 잘못된 PIN 3회 (PIN입력 → 카드압류)

적용 영역:

워크플로우
화면 내비게이션
세션 관리
프로토콜 테스팅

FL-4.3.1 (K2) 구문 테스팅을 설명할 수 있다

답변:

구문 테스팅(Statement Testing):
코드의 실행 가능한 구문을 테스트하는 화이트박스 기법

커버리지 항목: 실행 가능한 구문

구문 커버리지 계산:

구문 커버리지 = (실행된 구문 수 / 전체 실행 가능 구문 수) × 100%

예시 코드:

1: function checkDiscount(age, isMember) {
2:     let discount = 0;
3:     if (age >= 65) {
4:         discount = 20;
5:     }
6:     if (isMember) {
7:         discount += 10;
8:     }
9:     return discount;
10: }

실행 가능 구문: 2, 3, 4, 5, 6, 7, 8, 9 (8개)

테스트 케이스:

TC1: checkDiscount(70, true)
실행 경로: 2 → 3(T) → 4 → 5 → 6(T) → 7 → 8 → 9
실행 구문: 2,3,4,5,6,7,8,9 (8개)
커버리지: 8/8 × 100% = 100%

100% 구문 커버리지의 의미:

✅ 모든 코드를 최소 1회 실행
✅ 실행되지 않는 Dead Code 없음
❌ 모든 결정 논리가 테스트되었다고 보장 못 함
❌ 모든 조건 조합이 테스트되었다고 보장 못 함

한계:

if (x > 0 && y > 0) {  // 복합 조건
    doSomething();
}

TC: x=1, y=1
→ 100% 구문 커버리지 달성
→ 하지만 (x>0 && y≤0), (x≤0 && y>0) 미테스트

장점:

간단하고 직관적
자동화 도구로 쉽게 측정
기본적 커버리지 확보

활용:

최소 커버리지 기준
컴포넌트 테스트
단위 테스트
더 강한 기준(분기 커버리지)의 기초

FL-4.3.2 (K2) 분기 테스팅을 설명할 수 있다

답변:

분기 테스팅(Branch Testing):
코드의 모든 분기(제어 흐름 이동)를 테스트하는 화이트박스 기법

분기(Branch)란:

제어 흐름 그래프에서 두 노드 간 제어 이동
무조건 분기: 직선 코드
조건 분기: if, switch, while 등의 결정문 결과

커버리지 항목: 분기

분기 커버리지 계산:

분기 커버리지 = (실행된 분기 수 / 전체 분기 수) × 100%

예시 코드:

1: function evaluateScore(score) {
2:     let result;
3:     if (score >= 90) {           // 결정 D1
4:         result = "A";            // 분기 B1 (참)
5:     } else if (score >= 70) {    // 결정 D2
6:         result = "B";            // 분기 B2 (참)
7:     } else {
8:         result = "C";            // 분기 B3 (거짓)
9:     }
10:    return result;               // 분기 B4 (무조건)
11: }

제어 흐름 그래프:

분기:
- B1: D1이 참일 때 (score >= 90)
- B2: D1이 거짓, D2가 참일 때 (70 ≤ score < 90)
- B3: D1, D2 모두 거짓일 때 (score < 70)
- B4: return (무조건)

전체 분기: 4개

테스트 케이스:

TC1: score = 95
경로: 3(T) → 4 → 10
커버 분기: B1, B4 (2/4 = 50%)

TC2: score = 75
경로: 3(F) → 5(T) → 6 → 10
커버 분기: B2 (누적 3/4 = 75%)

TC3: score = 50
경로: 3(F) → 5(F) → 8 → 10
커버 분기: B3 (누적 4/4 = 100%)

100% 분기 커버리지의 의미:

✅ 모든 결정의 참/거짓 경로 실행
✅ 100% 구문 커버리지 포함 (더 강한 기준)
✅ if...then의 참과 거짓 모두 테스트
✅ 루프의 진입/미진입 모두 테스트
❌ 복합 조건의 모든 조합은 보장 못 함

구문 vs 분기 커버리지:

function discount(isMember, isPremium) {
    if (isMember && isPremium) {  // 복합 조건
        return 30;
    }
    return 0;
}

// 구문 커버리지 100%:
TC1: isMember=true, isPremium=true
→ 모든 구문 실행, 하지만 else 분기 미실행

// 분기 커버리지 100%:
TC1: isMember=true, isPremium=true  (참 분기)
TC2: isMember=false, isPremium=false (거짓 분기)
→ 모든 분기 실행

장점:

구문 커버리지보다 철저
결정 논리 검증
업계 표준 (많은 프로젝트에서 목표)

한계:

복합 조건: if (A && B && C)
분기 커버리지: T/F 2가지만 테스트
실제 조합: 2^3 = 8가지 존재

FL-4.3.3 (K2) 화이트박스 테스팅의 가치를 설명할 수 있다

답변:

화이트박스 테스팅의 가치:

1. 강점

A. 전체 구현 고려

명세가 모호/뒤떨어짐/불완전해도 결함 발견
예: 명세에 없는 숨겨진 기능 테스트 가능

B. 도달 어려운 코드 테스트

동적 테스팅으로 접근 어려운 경로 식별
예: 
- 에러 처리 코드
- 예외적 조건 (divide by zero)
- 복잡한 중첩 조건

C. 객관적 커버리지 측정

블랙박스만으로는 커버리지 측정 불가
화이트박스: 구문/분기 커버리지 정량 측정
→ 코드 신뢰도 향상

D. 정적 테스팅 적용

실행 전 코드에도 적용 가능:
- 코드 드라이 런
- 슈도 코드 리뷰
- 제어 흐름 그래프 분석

E. 추가 테스트 생성 정보

커버되지 않은 경로 식별
→ 테스트 케이스 추가 생성
→ 커버리지 목표 달성

2. 약점

A. 누락 요구사항 미발견

요구사항에 없는 기능 → 코드 없음 → 테스트 없음
예: 
요구사항: "로그인 실패 시 오류 메시지"
구현: 오류 메시지 없음
화이트박스: 오류 메시지 코드 없으므로 결함 발견 못 함

B. 구현 의존성

코드 변경 시 테스트 케이스 수정 필요
리팩토링 시 테스트 유지보수 부담

3. 활용 시나리오

상황	화이트박스 가치	예시
안전 치명적	높은 커버리지 요구	100% 분기 커버리지
복잡한 알고리즘	내부 논리 검증	정렬 알고리즘, 암호화
레거시 코드	명세 없을 때 유용	역공학적 테스트
리그레션 방지	코드 변경 영향 파악	변경 영역 커버리지 확인
성능 최적화	핫스팟 식별	자주 실행되는 경로 분석

4. 블랙박스와의 보완

블랙박스 테스팅
  ↓ 명세 기반 TC 도출
  ↓ 실행
  ↓
화이트박스 커버리지 측정
  ↓ 미커버 영역 식별
  ↓
추가 TC 생성 (화이트박스 기반)
  ↓ 실행
  ↓
목표 커버리지 달성

결론:
화이트박스는 객관적 품질 척도와 내부 논리 검증을 제공하지만, 블랙박스와 함께 사용해야 포괄적 테스팅 가능

FL-4.4.1 (K2) 오류 추정을 설명할 수 있다

답변:

오류 추정(Error Guessing):
테스터의 지식을 기반으로 오류, 결함, 장애 발생을 예측하는 경험 기반 테스트 기법

테스터 지식 기반:
1. 과거 경험

애플리케이션의 과거 동작
이전 결함 패턴
유사 프로젝트 경험

일반적 실수
- 개발자가 범하기 쉬운 오류 유형
- 이런 오류로 발생하는 결함
- 다른 애플리케이션의 장애 유형

일반적 오류 영역:

영역	오류 예시	테스트 예시
입력	- 올바른 입력 인식 실패 - 매개변수 오류/누락 - 경계값 처리 오류	- Null 입력 - 특수문자 - 최대 길이+1
출력	- 잘못된 형식 - 잘못된 결과 - 누락	- 소수점 자리 - 날짜 형식 - 필수 필드
논리	- 사례 누락 - 잘못된 연산자 - 잘못된 조건	- 경계 조건 - 특수 케이스 - 예외 상황
계산	- 잘못된 피연산자 - 잘못된 계산 - 반올림 오류	- 0으로 나누기 - 오버플로우 - 부동소수점
인터페이스	- 매개변수 불일치 - 호환되지 않는 유형 - 순서 오류	- API 호출 - 데이터 타입 - 파라미터 순서
데이터	- 잘못된 초기화 - 잘못된 유형 - 상태 불일치	- 초기값 NULL - 타입 변환 - 동시성

결함 공격(Defect Attack):
오류 추정을 구현하는 구체적 방법

단계:

1. 발생 가능한 오류/결함/장애 목록 작성
   ↓
2. 각 항목별 테스트 설계
   ↓
3. 목록 기반 체계적 테스트 수행

목록 작성 기반:

경험
결함 및 장애 데이터
소프트웨어 문제의 일반적 지식

예시: 로그인 기능

오류 추정 목록:

입력 관련:
☐ SQL Injection: admin' OR '1'='1
☐ XSS: <script>alert('xss')</script>
☐ 빈 문자열
☐ 공백만
☐ 매우 긴 문자열 (버퍼 오버플로우)
☐ 특수문자: !@#$%^&*()

논리 관련:
☐ 대소문자 구분 오류: Admin vs admin
☐ 세션 타임아웃 처리
☐ 동시 로그인 시도
☐ 이미 로그인된 상태에서 재로그인

인터페이스 관련:
☐ 브라우저 뒤로가기 후 접근
☐ 토큰 만료 후 요청
☐ CSRF 공격

계산 관련:
☐ 로그인 시도 카운터 오버플로우
☐ 타임스탬프 2038년 문제

활용:

다른 기법으로 놓칠 수 있는 결함 발견
탐색적 테스팅과 결합
체크리스트 기반 테스팅의 기초
리스크 식별

FL-4.4.2 (K2) 탐색적 테스팅을 설명할 수 있다

답변:

탐색적 테스팅(Exploratory Testing):
테스터가 테스트 대상에 대해 배워가면서 테스트의 설계, 실행, 평가를 동시에 수행하는 기법

핵심 특징:

학습 + 테스트 설계 + 실행 + 평가 = 동시 진행
      ↓
지속적 개선 및 적응

세션 기반 탐색적 테스팅:

구조:

1. 테스트 차터(Charter) 작성
   - 테스트 목적 명시
   - 가이드라인 제공
   
2. 타임박스 세션
   - 정해진 시간 (예: 90분)
   - 집중적 탐색
   
3. 세션 진행
   - 차터 기반 테스트
   - 발견사항 기록
   - 테스트 세션 시트 작성
   
4. 세션 보고
   - 이해관계자와 결과 논의
   - 발견사항 공유
   - 다음 차터 결정

테스트 차터 예시:

차터: 결제 모듈의 보안 검증
범위: 결제 처리 및 민감 데이터 처리
영역:
- SQL Injection 취약점
- 신용카드 데이터 암호화
- HTTPS 연결 확인
리스크: 높음
시간: 90분

세션 시트 예시:

세션 #: 2024-001
차터: 결제 모듈 보안
시작: 14:00, 종료: 15:30
실제 소요: 90분

테스트 수행:
- SQL Injection 시도 (10분)
  → 모든 입력 필드 검증됨
- XSS 테스트 (15분)
  → 결제 금액 필드에 취약점 발견 (BUG-123)
- 암호화 확인 (20분)
  → 카드번호 평문 전송 발견 (BUG-124, 치명적)
...

발견사항:
- 2개 결함 (1개 치명적)
- 1개 개선 제안

다음 세션:
- 세션 관리 보안
- 타임아웃 처리

장점:

유연성
- 명세 부족/부적합 시 유용
- 변화하는 요구사항 대응
- 예: 애자일 프로젝트
시간 압박 대응
- 빠른 피드백
- 우선순위 동적 조정
- 예: 긴급 릴리스 전
보완적
- 공식 기법 보완
- 예상 못한 결함 발견
- 예: 스크립트 테스트 후 탐색적으로 추가 검증
학습과 발견
- 테스트 대상 이해 증진
- 문서화되지 않은 기능 발견
- 사용자 관점 확보

테스터 역량 의존:

풍부한 경험
높은 도메인 지식
분석 기술
호기심
창의성

다른 기법과 병용:

탐색적 테스팅 중
  ↓
동등 분할 적용: 금액 입력 범위 분할
  ↓
경계값 분석: 0원, 최대 금액
  ↓
오류 추정: 음수, 특수문자
  ↓
발견사항 기록

적용 시나리오:

신규 기능 탐색
복잡한 통합 시나리오
사용자 경험 평가
리스크 높은 영역 집중 검토
스크립트 테스트 보완

FL-4.4.3 (K2) 체크리스트 기반 테스팅을 설명할 수 있다

답변:

체크리스트 기반 테스팅:
체크리스트를 활용해 테스트 컨디션을 확인하는 테스트 설계, 구현, 실행하는 기법

체크리스트 작성 기반:

경험
사용자에게 중요한 것
소프트웨어 실패 이유/방법에 대한 이해

체크리스트 항목 특징:

좋은 항목:

✅ 질문 형식
✅ 개별적이고 독립적
✅ 직접적으로 확인 가능
✅ 구체적

나쁜 항목:

❌ 자동 점검 가능한 것
❌ 시작/종료 조건에 더 적합한 것
❌ 너무 일반적인 것

예시: 웹 로그인 체크리스트

로그인 기능 테스트 체크리스트 v1.2

□ 유효한 자격증명으로 로그인이 성공하는가?
□ 잘못된 비밀번호 입력 시 명확한 오류 메시지가 표시되는가?
□ 존재하지 않는 사용자 ID 입력 시 적절히 처리되는가?
□ 5회 실패 후 계정이 잠기는가?
□ 잠긴 계정에 대한 알림이 표시되는가?
□ 비밀번호 찾기 링크가 작동하는가?
□ HTTPS로 안전하게 통신하는가?
□ 세션 타임아웃(30분)이 작동하는가?
□ 로그아웃 후 뒤로가기 버튼 클릭 시 접근이 차단되는가?
□ 브라우저 쿠키가 제대로 설정/삭제되는가?
□ 모바일 브라우저에서 정상 작동하는가?
□ 화면 판독기로 접근 가능한가? (접근성)

체크리스트 유형:

유형	초점	예시
기능	요구사항 확인	사용자 등록 체크리스트
비기능	품질 특성	성능 테스트 체크리스트
도메인	특정 영역	의료기기 규제 체크리스트
플랫폼	환경	크로스 브라우저 체크리스트
보안	보안 점검	OWASP Top 10 체크리스트
사용성	UX	Nielsen의 10가지 휴리스틱

체크리스트 관리:

1. 주기적 업데이트

시간 경과 → 일부 항목 효과 감소
         → 개발자가 같은 오류 안 범함
         
신규 결함 발견 → 체크리스트에 항목 추가
              → 심각도 높은 결함 우선

예: "SQL Injection 발견"
→ 체크리스트 추가: "모든 입력 필드에 SQL Injection 테스트했는가?"

2. 길이 관리

너무 길면 → 사용 어려움
          → 중요 항목 놓침
          
적정 길이: 10-20개 항목
필요시 카테고리별 분리

3. 결함 분석 기반

정기 리뷰 (분기별/릴리스별)
  ↓
최근 결함 분석
  ↓
새 항목 추가 / 구식 항목 제거
  ↓
우선순위 재조정

장점:

일관성 제공
- 명확한 구조
- 체계적 접근
- 예: 여러 테스터가 같은 기준으로 테스트
지식 보존
- 조직 지식 축적
- 신입 테스터 교육
- 예: 베테랑 경험을 체크리스트로 문서화
빠른 적용
- 구체적 TC 없이도 가능
- 시간 절약
- 예: 긴급 핫픽스 검증

단점:

변동성
- 상위 수준 → 테스트 결과 다를 수 있음
- 테스터 해석 차이
- 예: "적절히 처리"의 의미 해석
재현성 낮음
- 구체적 TC보다 재현 어려움
- 결함 재현 시 정보 부족 가능
커버리지 측정 어려움
- 정량적 측정 곤란
- 완성도 판단 모호

활용 시나리오:

시나리오                     → 체크리스트 사용
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
구체적 TC 없음               → 가이드로 활용
시간 부족                    → 빠른 smoke test
여러 테스터 참여             → 일관성 확보
도메인 전문가 부족           → 지식 전달
탐색적 테스팅 가이드         → 방향성 제공

FL-4.5.1 (K2) 개발자 및 업무 대표자와 협업해 사용자 스토리를 작성하는 방법을 설명할 수 있다

답변:

사용자 스토리(User Story):
시스템 사용자 또는 구매자에게 가치를 제공하는 기능

3C 구조:

Card (카드): 사용자 스토리를 기술하는 매체
    ↓
Conversation (대화): 소프트웨어 사용 방법 설명
    ↓
Confirmation (확인): 인수 조건

기본 형식:

[역할]로서
[목표]를 달성해
[역할이 얻게 될 비즈니스 가치]를 얻기를 원한다

인수 조건:
- ...

예시:

온라인 쇼핑몰 고객으로서
장바구니에 상품을 추가해
나중에 구매 결정을 할 수 있기를 원한다

인수 조건:
- 상품 상세 페이지에서 "장바구니 담기" 버튼 클릭 시 장바구니에 추가됨
- 장바구니에 이미 있는 상품 추가 시 수량이 증가함
- 장바구니 아이콘에 담긴 상품 수가 표시됨
- 비로그인 사용자의 장바구니는 세션에 저장됨
- 로그인 사용자의 장바구니는 서버에 저장되어 다른 기기에서도 접근 가능

협업 기반 작성 과정:

1. 3 Amigos 세션

참여자:
- 비즈니스 담당자 (제품 소유자, 비즈니스 분석가)
- 개발자
- 테스터

협업 기법:
- 브레인스토밍
- 마인드 매핑
- 예제 매핑

2. 세 가지 관점 통합

비즈니스 관점:
- 왜 필요한가?
- 비즈니스 가치는?
- 우선순위는?

개발 관점:
- 어떻게 구현할 것인가?
- 기술적 제약은?
- 얼마나 걸리는가?

테스팅 관점:
- 어떻게 테스트할 것인가?
- 어떤 시나리오가 있는가?
- 잠재적 리스크는?

3. 예제 매핑(Example Mapping)

도구: 색상 카드

노란색 카드: 사용자 스토리
파란색 카드: 규칙(인수 조건)
초록색 카드: 예제(테스트 케이스)
빨간색 카드: 질문/리스크

진행:
1. 스토리 카드 중앙 배치
2. 규칙 카드 추가 (스토리 아래)
3. 각 규칙마다 예제 추가 (규칙 아래)
4. 질문/리스크 기록 (오른쪽)

결과:
- 시각적으로 복잡도 파악
- 많은 질문 → 스토리 분할 고려
- 명확한 인수 조건과 예제

4. INVEST 기준 검증

기준	의미	체크포인트	예시
Independent	독립적	다른 스토리에 의존하지 않는가?	"로그인" 스토리는 "회원가입"과 독립
Negotiable	협상 가능	세부사항이 고정되지 않았는가?	구체적 UI는 개발 중 협의
Valuable	가치 있음	사용자/비즈니스에 가치 제공하는가?	매출 증대, 사용자 편의
Estimable	추정 가능	개발 노력을 추정할 수 있는가?	스토리 포인트 부여 가능
Small	작음	한 스프린트에 완료 가능한가?	너무 크면 분할
Testable	테스트 가능	테스트 방법을 알고 있는가?	명확한 인수 조건

테스터의 역할:

테스트 가능성 확보

질문 예시:
- "어떻게 테스트할 수 있나요?"
- "성공의 기준이 무엇인가요?"
- "예외 상황은 어떻게 처리하나요?"

시나리오 탐색

- 긍정 시나리오 (Happy path)
- 부정 시나리오 (오류 처리)
- 경계 조건
- 예외 상황

불명확성 제거

모호한 표현 → 구체화 요청
예: "빠르게" → "2초 이내"
    "안전하게" → "HTTPS + 암호화"

리스크 식별

- 보안 취약점
- 성능 이슈
- 통합 복잡도
- 데이터 무결성

공유된 비전 형성:

협업 → 공통 이해 → 더 나은 제품
  ↓
- 요구사항 오해 방지
- 조기 문제 발견
- 개발 방향 명확화
- 테스트 전략 수립

FL-4.5.2 (K2) 인수 조건을 작성하는 여러가지 방법을 분류할 수 있다

답변:

인수 조건(Acceptance Criteria):
사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건

인수 조건의 용도:

사용자 스토리 범위 정의
- 무엇이 포함/제외되는지 명확화
이해관계자 간 합의 도출
- 공통 이해 형성
- 기대치 일치
긍정/부정 시나리오 설명
- 정상 동작
- 오류 처리
인수 테스팅 베이시스
- 테스트 케이스 도출 근거
계획 및 추정
- 개발 노력 산정
- 완료 판단 기준

두 가지 작성 방법:

1. 시나리오 기반 (Given/When/Then)

형식:

Given [전제 조건]
When [동작/이벤트]
Then [기대 결과]
And [추가 조건] (선택적)

예시 1: 로그인

Scenario: 유효한 자격증명으로 로그인

Given 사용자가 로그인 페이지에 있고
  And 등록된 계정을 가지고 있을 때
When 올바른 이메일과 비밀번호를 입력하고
  And "로그인" 버튼을 클릭하면
Then 메인 대시보드로 이동하고
  And 환영 메시지가 표시되고
  And 사용자 프로필 아이콘이 표시된다

Scenario: 잘못된 비밀번호로 로그인

Given 사용자가 로그인 페이지에 있을 때
When 올바른 이메일과 잘못된 비밀번호를 입력하고
  And "로그인" 버튼을 클릭하면
Then 로그인 페이지에 그대로 있고
  And "이메일 또는 비밀번호가 올바르지 않습니다" 오류 메시지가 표시되고
  And 로그인 시도 횟수가 증가한다

Scenario: 5회 실패 후 계정 잠김

Given 사용자가 4회 로그인 실패했을 때
When 5번째로 잘못된 자격증명을 입력하면
Then 계정이 15분간 잠기고
  And "계정이 일시적으로 잠겼습니다. 15분 후 다시 시도하세요" 메시지가 표시된다

장점:

명확한 인과관계
자동화 용이 (BDD 프레임워크)
이해하기 쉬움
비기술자도 작성 가능

2. 규칙 기반 (Rule-based)

A. 체크리스트 형식

사용자 스토리: 상품 검색

인수 조건:
☐ 검색창에 키워드 입력 시 자동완성 제안이 표시됨
☐ 검색 결과는 관련도 순으로 정렬됨
☐ 상품 이미지, 이름, 가격이 표시됨
☐ 검색 결과가 없으면 "검색 결과가 없습니다" 메시지 표시
☐ 페이지당 20개 상품 표시
☐ 페이지네이션 제공
☐ 필터(카테고리, 가격대) 적용 가능
☐ 검색 시간이 2초 이내

B. 입력-출력 매핑 (테이블 형식)

사용자 스토리: 할인 계산

| 구매액 | 회원 등급 | 예상 할인율 | 비고 |
|--------|----------|-----------|------|
| 0-9,999 | 일반 | 0% | 최소 구매액 미달 |
| 10,000-49,999 | 일반 | 5% | |
| 50,000+ | 일반 | 10% | |
| 0-9,999 | VIP | 5% | VIP 기본 할인 |
| 10,000-49,999 | VIP | 10% | 일반 5% + VIP 5% |
| 50,000+ | VIP | 15% | 일반 10% + VIP 5% |
| 음수 | 모두 | 오류 | "유효하지 않은 금액" |

C. 명시적 규칙 나열

사용자 스토리: 비밀번호 정책

규칙:
1. 최소 8자 이상
2. 대문자 최소 1개 포함
3. 소문자 최소 1개 포함
4. 숫자 최소 1개 포함
5. 특수문자 최소 1개 포함 (!@#$%^&*)
6. 연속된 3자 이상 금지 (abc, 123)
7. 사용자명과 동일 금지
8. 이전 3개 비밀번호와 다름
9. 사전 단어 금지
10. 조건 미충족 시 구체적 오류 메시지 표시

규칙 기반 장점:

명확한 베리피케이션 기준
복잡한 조건 조합 표현 용이
비즈니스 규칙 문서화

선택 기준:

상황	권장 방식	이유
사용자 워크플로우	Given/When/Then	시나리오가 명확, 자동화 용이
복잡한 비즈니스 규칙	규칙 기반 (테이블)	조건 조합이 많음
검증 항목 나열	규칙 기반 (체크리스트)	간단명료
비기술 이해관계자	Given/When/Then	이해하기 쉬움
API/백엔드 로직	규칙 기반 (입출력)	기술적 명확성

혼합 사용:

하나의 사용자 스토리에 두 방식 병용 가능

예: 결제 기능
- 주요 흐름: Given/When/Then
- 카드 유효성 규칙: 테이블
- 필수 확인 사항: 체크리스트

FL-4.5.3 (K3) ATDD를 사용해 테스트 케이스를 도출할 수 있다

답변:

ATDD (Acceptance Test-Driven Development):
인수 조건 기반의 테스트 우선 접근법

ATDD 프로세스:

1. 명세 워크숍
   ↓
2. 인수 조건 작성
   ↓
3. 테스트 케이스 작성 (구현 전)
   ↓
4. 테스트 자동화
   ↓
5. 구현
   ↓
6. 테스트 실행

1단계: 명세 워크숍

참가자: 고객, 개발자, 테스터

활동:

사용자 스토리 분석
인수 조건 정의 (아직 없다면)
불완전성, 모호성, 결함 해결

예시:

사용자 스토리: 비밀번호 재설정

워크숍 논의:
Q: "재설정 링크 유효 기간은?"
A: "24시간"

Q: "이메일이 존재하지 않으면?"
A: "보안상 같은 메시지 표시 (계정 정보 노출 방지)"

Q: "재설정 중 여러 번 요청하면?"
A: "마지막 링크만 유효"

2단계: 테스트 케이스 작성 (구현 전)

기본 원칙:

예제 = 테스트
실행 가능한 명세
자동화 가능한 형식

작성 순서:

A. 긍정 테스트 (Happy Path)

TC1: 유효한 재설정 링크로 비밀번호 변경

Given 사용자가 "test@example.com"로 비밀번호 재설정 요청했고
  And 재설정 이메일을 받았을 때
When 이메일의 재설정 링크를 클릭하고
  And 새 비밀번호 "NewPass123!"를 입력하고
  And "비밀번호 변경" 버튼을 클릭하면
Then 비밀번호가 성공적으로 변경되고
  And "비밀번호가 변경되었습니다" 메시지가 표시되고
  And 로그인 페이지로 리다이렉트된다

기대 결과:
- DB의 비밀번호 해시 업데이트됨
- 재설정 토큰 무효화됨
- 새 비밀번호로 로그인 가능

B. 부정 테스트 (오류 처리)

TC2: 만료된 재설정 링크

Given 사용자가 24시간 전에 비밀번호 재설정 요청했을 때
When 만료된 재설정 링크를 클릭하면
Then "이 링크는 만료되었습니다. 새로운 비밀번호 재설정을 요청하세요" 메시지가 표시되고
  And 재설정 요청 페이지로 이동한다

TC3: 이미 사용된 재설정 링크

Given 사용자가 재설정 링크로 비밀번호를 변경했을 때
When 같은 링크를 다시 클릭하면
Then "이 링크는 이미 사용되었습니다" 메시지가 표시된다

TC4: 잘못된 비밀번호 형식

Given 사용자가 유효한 재설정 링크에 접속했을 때
When 너무 짧은 비밀번호 "Pass1!"를 입력하면
Then "비밀번호는 최소 8자 이상이어야 합니다" 오류 메시지가 표시되고
  And 비밀번호가 변경되지 않는다

C. 비기능 테스트

TC5: 보안 - 계정 열거 방지

Given 존재하지 않는 이메일 "notexist@example.com"로 재설정 요청했을 때
Then "이메일이 등록되어 있다면 재설정 링크가 발송됩니다" 메시지가 표시되고
  And 실제 이메일은 발송되지 않지만
  And 응답은 유효한 이메일과 동일하다 (계정 존재 여부 노출 안 됨)

TC6: 성능 - 이메일 발송 시간

Given 사용자가 비밀번호 재설정을 요청했을 때
Then 요청 후 3초 이내에 이메일이 발송된다

3단계: 테스트 자동화

자동화 프레임워크 예시 (Cucumber/Gherkin)

Feature: 비밀번호 재설정

  Scenario: 유효한 재설정 링크로 비밀번호 변경
    Given 사용자 "test@example.com"가 등록되어 있음
    And 비밀번호 재설정 이메일이 발송됨
    When 사용자가 재설정 링크를 클릭함
    And 새 비밀번호 "NewPass123!"를 입력함
    And "비밀번호 변경" 버튼을 클릭함
    Then 성공 메시지가 표시됨
    And 새 비밀번호로 로그인 가능함

  Scenario: 만료된 재설정 링크
    Given 24시간 전에 재설정 이메일이 발송됨
    When 사용자가 만료된 링크를 클릭함
    Then "링크가 만료되었습니다" 메시지가 표시됨

Step Definitions (코드 구현):

Given('사용자 {string}가 등록되어 있음', async (email) => {
  await createUser(email, 'OldPass123!');
});

When('사용자가 재설정 링크를 클릭함', async () => {
  const token = await getResetToken();
  await browser.navigateTo(`/reset-password?token=${token}`);
});

Then('성공 메시지가 표시됨', async () => {
  const message = await getSuccessMessage();
  expect(message).toBe('비밀번호가 변경되었습니다');
});

4단계: 구현

개발자가 테스트를 통과하도록 코드 구현
  ↓
초기: 모든 테스트 실패 (Red)
  ↓
구현 진행
  ↓
테스트 하나씩 통과 (Green)
  ↓
리팩토링 (Refactor)
  ↓
모든 테스트 통과

5단계: 실행 가능한 명세

이점:

테스트 케이스 = 명세 = 문서

장점:
- 항상 최신 (코드와 동기화)
- 실행 가능 (자동 검증)
- 이해하기 쉬움 (자연어)
- 회귀 방지 (지속적 검증)

전체 흐름 예시:

Day 1: 명세 워크숍
- 사용자 스토리 검토
- 인수 조건 합의
- 시나리오 도출

Day 2: 테스트 작성
- 5개 시나리오 → Gherkin으로 작성
- Step definitions 골격 작성
- 실행 시 모두 실패 확인 (미구현)

Day 3-4: 구현
- 재설정 링크 생성 로직
- 이메일 발송
- 비밀번호 변경 API
- TC1 통과

Day 5: 완료
- 모든 TC 통과
- 리팩토링
- CI/CD 통합

ATDD vs TDD:

TDD (Test-Driven Development):
- 컴포넌트 레벨
- 개발자 중심
- 단위 테스트

ATDD (Acceptance Test-Driven Development):
- 시스템/인수 레벨
- 협업 (개발자+테스터+고객)
- 인수 테스트
- 비즈니스 가치 검증

제 5장: 테스트 활동 관리 (335분)

📌 핵심 용어

용어	설명
결함 관리(defect management)	결함의 발견부터 종료까지 처리하는 프로세스
결함 보고서(defect report)	결함의 상세 정보를 기록한 문서
시작 조건(entry criteria)	활동을 수행하기 위한 전제 조건
완료 조건(exit criteria)	활동의 종료를 선언하기 위한 조건
제품 리스크(product risk)	제품 품질 특성 관련 리스크
프로젝트 리스크(project risk)	프로젝트 관리 및 제어 관련 리스크
리스크(risk)	부정적 영향을 미칠 수 있는 잠재적 사건
리스크 분석(risk analysis)	리스크 식별과 평가로 구성된 활동
리스크 평가(risk assessment)	리스크를 분류하고 우선순위를 정하는 활동
리스크 제어(risk control)	리스크에 대응하는 조치
리스크 식별(risk identification)	리스크 목록을 생성하는 활동
리스크 수준(risk level)	리스크를 측정한 값 (발생 가능성 × 영향도)
리스크 관리(risk management)	리스크 분석과 제어로 구성된 활동
리스크 완화(risk mitigation)	리스크 수준을 낮추는 활동
리스크 모니터링(risk monitoring)	리스크 완화 조치의 효과성을 확인하는 활동
리스크 기반 테스팅	리스크 분석 결과로 테스트를 관리하는 접근법
테스트 접근법(test approach)	테스트 활동 선택 및 우선순위 지정 방식
테스트 완료 보고서	테스트 활동을 요약하는 보고서
테스트 제어(test control)	테스트 목적 달성을 위한 조치
테스트 모니터링(test monitoring)	테스팅 정보를 지속적으로 수집하는 활동
테스트 계획서(test plan)	테스트 목적, 자원, 프로세스를 설명하는 문서
테스트 계획(test planning)	테스트 목적 정의 및 접근법 선택 활동
테스트 진행 보고서	테스트 진행 상황을 전달하는 보고서
테스트 피라미드(test pyramid)	테스트 세분화 수준을 보여주는 모델
테스트 전략(test strategy)	조직 수준의 일반적 테스트 접근법
테스팅 사분면(testing quadrants)	테스트 레벨과 유형을 묶는 모델

🎯 학습 목표 및 답변

FL-5.1.1 (K2) 테스트 계획서의 목적과 내용을 예를 들어 설명할 수 있다

답변:

테스트 계획서의 목적:

목적 달성 방법/일정 문서화
- 언제, 어떻게 테스트할 것인가
- 자원 배분 계획
기준 충족 지원
- 정의된 기준 달성 확인
- 완료 조건 추적
의사소통 수단
- 팀원 간 정보 공유
- 이해관계자 보고
정책/전략 준수 입증
- 조직 표준 따름 증명
- 또는 편차 이유 설명

테스트 계획 활동의 가치:

미래 문제 사전 고민 (리스크, 일정, 인력, 도구, 비용, 노력)
테스트 목적 달성 노력 추론

테스트 계획서 내용:

항목	설명	예시
테스팅 정황	- 테스트 범위 - 테스트 목적 - 테스트 베이시스	- 범위: 결제 모듈 v2.0 - 목적: 기능 검증, 보안 확인 - 베이시스: 요구사항 명세 v1.5
가정 및 제약	- 가정 사항 - 제약 조건	- 가정: 테스트 환경 3일 전 준비 - 제약: 예산 500만원, 기간 2주
이해관계자	- 역할 및 책임 - 관련성 - 채용/훈련	- 테스트 리더: 김철수 - 테스터: 3명 - 교육: Selenium 2일
의사소통	- 방법 및 빈도 - 문서 양식	- 주간 진행 보고 - 완료 시 최종 보고 - Jira 대시보드
리스크 목록	- 제품 리스크 - 프로젝트 리스크	- 제품: 결제 실패 (높음) - 프로젝트: 테스터 부족 (중간)
테스트 접근법	- 테스트 레벨 - 테스트 유형 - 테스트 기법 - 산출물 - 시작/완료 조건 - 독립성 - 메트릭 - 데이터/환경 요구사항 - 정책/전략 편차	- 레벨: 시스템, 통합 - 유형: 기능, 보안, 성능 - 기법: 블랙박스, 경계값 - 산출물: TC 100개 이상 - 시작: 빌드 안정성 - 완료: 심각도 高 결함 0개 - 커버리지: 요구사항 90% - 메트릭: 결함 밀도, 실행률 - 데이터: 결제 테스트 데이터 50건 - 환경: 스테이징 서버
예산 및 일정	- 테스트 비용 - 마일스톤	- 예산: 인건비 400만원, 도구 100만원 - 일정: 설계 1주, 실행 1주

예시: 전자상거래 결제 모듈 테스트 계획서

테스트 계획서: 결제 모듈 v2.0

1. 테스팅 정황
   - 범위: 신용카드/계좌이체 결제 기능
   - 목적: 
     * 기능 정확성 검증
     * PCI-DSS 보안 표준 준수 확인
     * 동시 사용자 1000명 처리 확인
   - 테스트 베이시스: 
     * 결제 요구사항 명세 v2.0
     * API 설계 문서 v1.3
     * 보안 정책 문서

2. 가정 및 제약
   - 가정:
     * 개발 완료: 2024-11-01
     * 테스트 환경: 10월 28일 준비
   - 제약:
     * 예산: 500만원
     * 기간: 2주 (11/1~11/15)
     * 인력: 테스터 3명

3. 이해관계자
   - 테스트 리더: 김철수 (책임)
   - 테스터: 3명 (테스트 실행)
   - 보안 전문가: 박영희 (보안 검증)
   - 교육: Burp Suite 1일

4. 의사소통
   - 매일: 스탠드업 미팅
   - 주간: 진행 보고서 (관리자)
   - 완료 시: 최종 보고서
   - 도구: Jira 대시보드

5. 리스크
   - 제품 리스크:
     * 결제 실패 (높음)
     * 개인정보 유출 (높음)
     * 동시 처리 성능 (중간)
   - 프로젝트 리스크:
     * 테스터 경험 부족 (중간)
     * 환경 준비 지연 (낮음)

6. 테스트 접근법
   - 레벨: 시스템, 시스템 통합
   - 유형: 기능, 보안, 성능
   - 기법: 블랙박스 (동등분할, 경계값)
   - 시작 조건:
     * 빌드 안정성 (smoke test 통과)
     * 환경 준비 완료
   - 완료 조건:
     * 심각도 높음 결함 0개
     * 요구사항 커버리지 90%
     * 보안 취약점 0개
   - 메트릭:
     * 결함 밀도
     * 테스트 실행률
     * 커버리지
   - 데이터: 결제 시나리오 50건

7. 예산 및 일정
   - 예산: 총 500만원
     * 인건비: 400만원
     * 도구: 100만원
   - 일정:
     * 11/1-11/3: 테스트 설계
     * 11/4-11/10: 테스트 실행
     * 11/11-11/15: 결함 재테스트

최근 대화 내용을 확인해서 어떤 작업이 미완료 상태인지 알아보겠습니다.최근 대화를 확인해보니 ISTQB CTFL v4.0 문서의 용어 정리 및 학습목표 작성 작업이 진행 중이었던 것으로 보입니다.

해당 대화 내용을 더 자세히 확인해보겠습니다.네, 확인했습니다! ISTQB CTFL v4.0 문서의 용어 정리 및 학습목표 작성 작업이 진행 중이었고, FL-5.1.2 학습목표 부분에서 중단된 것으로 보입니다.

이전 대화 보기

끊긴 부분부터 마무리해드리겠습니다:

FL-5.1.2 (K1) 테스터가 반복 주기와 릴리스 계획에 가치를 더하는 방법

2. 반복 주기 계획 (Iteration Planning) - 계속

활동	가치	예시
테스트 용이성 판단	구현 가능성 평가 준비 상태 확인	"로그인 스토리는 DB 스키마 준비 필요" → 다음 스프린트로 이동
테스트 노력 추정	스프린트 용량 계획 현실적 목표 설정	스토리당 테스트: 2MD → 10개 스토리 가능
기능 테스트 설계	상세 테스트 케이스 작성 테스트 자동화 스크립트	로그인 기능: - 정상 로그인 TC - 실패 시나리오 TC
반복 주기 테스팅 계획	일별 테스트 일정 데일리 목표 설정	Day 1-3: 개발 Day 4: 통합 Day 5: 테스트
테스트 자동화 식별	자동화 대상 선정 자동화 우선순위	로그인/회원가입: 자동화 高 (회귀 빈도 높음)

결과:

반복 주기 계획서 (스프린트 백로그)
├─ 선택된 사용자 스토리 (우선순위)
├─ 구체적 리스크 및 대응
├─ 스토리별 테스트 케이스
├─ 일별 테스트 일정
├─ 자동화 계획
└─ 완료 조건 (Definition of Done)

릴리스 계획 vs 반복 주기 계획 비교

구분	릴리스 계획	반복 주기 계획
범위	전체 릴리스 (여러 스프린트)	단일 스프린트
기간	2-6개월	1-4주
추상화 수준	높음 (전략적)	낮음 (구체적)
테스트 활동	전반적 접근법, 전략	상세 TC, 자동화 스크립트
리스크 분석	제품 전체 리스크	스프린트 단위 리스크
예시	"결제 모듈: 40MD, 보안 중점"	"결제 API TC 20개, Day 4-5 실행"

테스터의 핵심 가치

품질 게이트키퍼
- 테스트 가능하지 않은 스토리 식별
- 명확하지 않은 인수 조건 개선
리스크 기반 의사결정 지원
- 고위험 기능 우선순위화
- 테스트 노력 최적 분배
협업 촉진
- 개발자-제품 소유자 간 소통 가교
- 3 Amigos (PO-개발자-테스터) 세션
지속적 개선
- 회고를 통한 프로세스 개선
- 자동화를 통한 효율성 향상

실무 예시:

스프린트 계획 미팅 (2시간)

1. 스토리 리뷰 (30분)
   테스터: "이 스토리의 인수 조건이 명확하지 않습니다"
   → 팀: 인수 조건 구체화

2. 리스크 분석 (20분)
   테스터: "결제 기능은 보안 리스크가 높습니다"
   → 팀: 보안 테스트 시간 추가 배정

3. 테스트 노력 추정 (30분)
   테스터: "각 스토리당 평균 2MD 필요"
   → 팀: 스프린트 용량 고려하여 8개 스토리 선택

4. 일정 계획 (30분)
   테스터: "통합 테스트는 Day 4부터 가능"
   → 팀: 개발 완료 목표 Day 3 설정

5. 자동화 논의 (10분)
   테스터: "로그인은 자동화 우선순위 높음"
   → 팀: 자동화 작업 백로그에 추가

네, 5.1.2 이후 내용을 계속 작성하겠습니다!

FL-5.1.3 (K2) 시작 조건과 완료 조건의 차이를 구별할 수 있다 (상세: 5.1.3절)

답변:

시작 조건 (Entry Criteria)

정의: 테스트를 시작하기 위해 충족해야 할 조건

목적:

조기 테스트 시작으로 인한 시간/비용 낭비 방지
테스트 가능한 상태 보장
품질 게이트 역할

예시:

테스트 레벨	시작 조건 예시
컴포넌트 테스트	- 코드 작성 완료 - 코드 리뷰 통과 - 정적 분석 도구 실행 완료 - 단위 테스트 환경 준비
통합 테스트	- 개별 컴포넌트 테스트 통과 - 통합 환경 구축 완료 - 인터페이스 명세 확정 - 테스트 데이터 준비
시스템 테스트	- 모든 통합 테스트 완료 - 시스템 빌드 안정성 확인 (smoke test 통과) - 테스트 환경 준비 완료 - 요구사항 추적 매트릭스 완성 - 테스트 케이스 리뷰 완료 - 심각도 높음 결함 0개
인수 테스트	- 시스템 테스트 통과 - 사용자 매뉴얼 준비 - 운영 환경과 유사한 환경 준비 - 사용자 교육 완료 - 크리티컬 결함 모두 수정

실무 예시:

전자상거래 시스템 테스트 시작 조건

✅ 필수 조건:
1. 개발 빌드 배포 완료 (v2.0-beta)
2. Smoke Test 통과 (주요 화면 로딩 확인)
3. 테스트 환경 DB 데이터 준비 완료
4. 테스트 계정 50개 생성 완료

✅ 권장 조건:
5. 알려진 블로킹 결함 0개
6. 성능 테스트 환경 부하 테스트 완료
7. 테스트 케이스 100개 리뷰 완료

→ 모든 필수 조건 충족 시 테스트 시작 승인

완료 조건 (Exit Criteria)

정의: 테스트를 종료하기 위해 충족해야 할 조건

목적:

테스트가 충분히 수행되었는지 판단
제품 릴리스 준비 상태 확인
잔여 리스크 파악

예시:

테스트 레벨	완료 조건 예시
컴포넌트 테스트	- 계획된 테스트 100% 실행 - 코드 커버리지 80% 이상 - 심각도 높음/중간 결함 0개
통합 테스트	- 인터페이스 테스트 완료 - 통합 시나리오 커버리지 90% - 데이터 흐름 검증 완료
시스템 테스트	- 요구사항 커버리지 95% 이상 - 심각도 높음 결함 0개 - 심각도 중간 결함 5개 이하 - 성능 기준 충족 - 보안 취약점 0개
인수 테스트	- 모든 인수 조건 충족 - 비즈니스 크리티컬 기능 100% 정상 - 사용자 만족도 80% 이상 - 알려진 결함 모두 문서화 - 이해관계자 서명

실무 예시:

전자상거래 시스템 테스트 완료 조건

✅ 필수 조건:
1. 계획된 테스트 케이스 150개 중 95% 이상 실행
2. 요구사항 커버리지 90% 이상
3. 심각도 높음 결함: 0개 ⭐
4. 심각도 중간 결함: 3개 이하 (모두 수정 일정 확정)
5. 결제 기능 100% 정상 작동
6. 성능: 동시 사용자 1000명 처리 가능

✅ 품질 메트릭:
7. 결함 밀도: 0.5개/KLOC 이하
8. 테스트 통과율: 92% 이상

✅ 문서:
9. 테스트 완료 보고서 작성
10. 알려진 결함 목록 및 회피책 문서화

→ 모든 필수 조건 충족 + 이해관계자 승인 → 릴리스

시작 조건 vs 완료 조건 비교

구분	시작 조건	완료 조건
영어	Entry Criteria	Exit Criteria
시점	테스트 시작 전	테스트 종료 시
목적	테스트 가능 여부 판단	테스트 충분성 판단
초점	준비 상태	달성 결과
측정 대상	환경, 산출물, 리소스	커버리지, 결함, 품질 메트릭
결정	Go / No-Go (테스트 시작)	Go / No-Go (릴리스)
예시	"빌드가 smoke test 통과했는가?"	"요구사항 커버리지 90% 달성했는가?"

Definition of Ready vs Definition of Done (애자일)

Definition of Ready (DoR) = 시작 조건

사용자 스토리가 스프린트에 들어가기 위한 조건

✅ 스토리가 명확하게 정의됨
✅ 인수 조건이 구체적으로 작성됨
✅ 테스트 가능함
✅ 의존성이 식별됨
✅ 스토리 포인트 추정 완료
✅ 팀이 이해함

→ 스프린트 백로그에 추가 가능

Definition of Done (DoD) = 완료 조건

사용자 스토리가 "완료"로 간주되기 위한 조건

✅ 코드 작성 및 리뷰 완료
✅ 단위 테스트 작성 및 통과
✅ 통합 테스트 통과
✅ 인수 테스트 통과
✅ 문서 업데이트
✅ 결함 수정 완료
✅ 제품 소유자 승인

→ 스토리 완료 (Done)

시작/완료 조건 정의 시 고려사항

1. 프로젝트 정황 반영

예: 규제 산업 (금융, 의료)
시작 조건:
- 규제 요구사항 매핑 완료
- 컴플라이언스 체크리스트 준비

완료 조건:
- 규제 요구사항 100% 커버리지
- 감사 준비 문서 완성

2. 리스크 수준 고려

고위험 프로젝트:
시작 조건: 더 엄격 (예: 리뷰 100% 완료)
완료 조건: 더 엄격 (예: 결함 0개)

저위험 프로젝트:
시작 조건: 완화 가능
완료 조건: 유연 가능

3. 측정 가능하고 명확하게

❌ 나쁜 예: "대부분의 테스트가 완료되었다"
✅ 좋은 예: "계획된 테스트의 95% 실행 완료"

❌ 나쁜 예: "주요 결함이 없다"
✅ 좋은 예: "심각도 높음 결함 0개, 중간 3개 이하"

4. 팀 합의

시작/완료 조건은:
- 테스터만 결정 ❌
- 팀 전체 합의 ✅
- 이해관계자 승인 ✅
- 문서화 ✅

실무 프로세스

시작 조건 체크

1. 체크리스트 작성
2. 팀 리뷰
3. 미충족 항목 → 개발팀 피드백
4. 모두 충족 → 테스트 시작 승인
5. 테스트 로그에 기록

완료 조건 체크

1. 메트릭 수집
2. 완료 조건 체크리스트 확인
3. 미충족 항목 → 리스크 평가
4. Go/No-Go 회의
5. 릴리스 결정
6. 테스트 완료 보고서 작성

완료 조건 미충족 시

옵션 1: 추가 테스팅 (일정 연장)
옵션 2: 리스크 수용 (조건부 릴리스)
옵션 3: 릴리스 연기
옵션 4: 범위 축소 (일부 기능 제외)

→ 이해관계자와 협의하여 결정

네, 5장의 나머지 학습목표들을 모두 완성하겠습니다!

FL-5.1.4 (K3) 필요한 테스트 노력의 계산을 위해 추정 기법을 활용할 수 있다 (상세: 5.1.4절)

답변:

테스트 노력 추정이란?

정의: 테스트 프로젝트의 테스트 목적을 달성하는 데 필요한 테스트 관련 작업량을 예측하는 것

핵심 원칙:

추정치는 여러 가정을 기반으로 함
추정에는 항상 오류가 있을 수 있음
작은 작업에 대한 추정이 더 정확
큰 작업은 여러 작은 작업으로 분할 후 추정

1. 비율 기반 추정 (Estimation based on ratios)

유형: 메트릭 기반 기법

방법:

조직의 과거 프로젝트 데이터 수집
표준 비율 도출
새 프로젝트에 적용

예시:

과거 프로젝트 데이터:
프로젝트 A: 개발 300MD, 테스트 200MD → 비율 3:2
프로젝트 B: 개발 450MD, 테스트 300MD → 비율 3:2
프로젝트 C: 개발 600MD, 테스트 400MD → 비율 3:2

→ 조직 표준 비율: 개발 : 테스트 = 3 : 2

새 프로젝트 추정:
개발 노력 = 600MD
테스트 노력 = 600 × (2/3) = 400MD ✅

장점:

조직 고유 데이터 활용
신뢰도 높음
간단한 계산

단점:

과거 데이터 필요
프로젝트 특성이 다르면 부정확

2. 외삽법 (Extrapolation)

유형: 메트릭 기반 기법

방법:

현재 프로젝트에서 조기 측정 시작
충분한 데이터 수집
수학적 모델로 나머지 노력 추정

예시:

애자일 프로젝트 (2주 스프린트)

스프린트 1: 테스트 노력 = 40MD
스프린트 2: 테스트 노력 = 45MD
스프린트 3: 테스트 노력 = 42MD

평균 = (40 + 45 + 42) / 3 = 42MD

스프린트 4-10 추정 (7개 스프린트):
42MD × 7 = 294MD ✅

전체 테스트 노력 = 127MD (완료) + 294MD (예상) = 421MD

활용:

반복적 SDLC에 매우 적합
스크럼, 칸반 등
지속적 개선 가능

장점:

실제 프로젝트 데이터 기반
지속적 정확도 향상

단점:

초기 데이터 필요 (cold start 문제)
프로젝트 특성 변화 시 부정확

3. 와이드밴드 델파이 (Wideband Delphi)

유형: 반복적, 전문가 기반 기법

방법:

1단계: 각 전문가 독립적으로 추정
   전문가 A: 50MD
   전문가 B: 80MD
   전문가 C: 60MD
   전문가 D: 45MD

2단계: 결과 수집 및 이상치 식별
   평균 = 58.75MD
   이상치 = 80MD (B), 45MD (D)

3단계: 논의
   B: "복잡한 통합 테스트 고려"
   D: "자동화 가정"
   → 팀: 자동화 일부, 통합 복잡도 중간

4단계: 재추정
   전문가 A: 55MD
   전문가 B: 65MD
   전문가 C: 60MD
   전문가 D: 58MD

5단계: 합의
   평균 = 59.5MD
   범위 좁아짐 → 합의 도달 ✅

플래닝 포커 (Planning Poker):

와이드밴드 델파이의 애자일 변형
카드 사용 (피보나치 수열: 1, 2, 3, 5, 8, 13...)
스토리 포인트 추정

플래닝 포커 예시:

사용자 스토리: "사용자 로그인 기능"

1라운드:
개발자 A: 5점
개발자 B: 13점 ← 이상치
테스터 C: 8점
개발자 D: 5점

논의:
B: "OAuth 통합이 복잡합니다"
팀: "이번엔 간단한 DB 인증만"

2라운드:
개발자 A: 5점
개발자 B: 8점
테스터 C: 8점
개발자 D: 5점

합의: 6-7점 정도 (평균 6.5)

장점:

전문가 경험 활용
팀 합의
다양한 관점 반영

단점:

시간 소요
전문가 필요

4. 3점 추정 (Three-point estimation)

유형: 전문가 기반 기법

방법:

세 가지 추정치:

a = 가장 낙관적 (Best case)
m = 가장 가능성 높은 (Most likely)
b = 가장 비관적 (Worst case)

계산식:

최종 추정치(E) = (a + 4×m + b) / 6
표준편차(SD) = (b - a) / 6

예시 1: 시스템 테스트

전문가 추정:
a (낙관적) = 30MD  "모든 것이 순조로우면"
m (가능성 높음) = 45MD  "일반적으로"
b (비관적) = 75MD  "많은 문제 발생 시"

계산:
E = (30 + 4×45 + 75) / 6
  = (30 + 180 + 75) / 6
  = 285 / 6
  = 47.5MD

SD = (75 - 30) / 6
   = 45 / 6
   = 7.5MD

최종 추정: 47.5 ± 7.5MD
→ 40MD ~ 55MD 범위 ✅

예시 2: 성능 테스트

a = 10시간 (간단한 시나리오)
m = 18시간 (표준 시나리오)
b = 30시간 (복잡한 환경 문제)

E = (10 + 4×18 + 30) / 6
  = (10 + 72 + 30) / 6
  = 112 / 6
  = 18.7시간

SD = (30 - 10) / 6
   = 20 / 6
   = 3.3시간

최종: 18.7 ± 3.3시간
→ 15.4 ~ 22시간 ✅

장점:

불확실성 정량화
리스크 고려
범위 제공

단점:

전문가 경험 필요
세 가지 추정 필요

추정 기법 비교

기법	유형	데이터	적합한 상황	예시
비율 기반	메트릭	과거 프로젝트	유사 프로젝트 반복	개발 600MD → 테스트 400MD
외삽법	메트릭	현재 프로젝트	반복적 SDLC	스프린트 평균 42MD
와이드밴드 델파이	전문가	전문가 경험	신규 프로젝트, 팀 합의	플래닝 포커 8점
3점 추정	전문가	전문가 경험	불확실성 높음	47.5 ± 7.5MD

실무 적용

시나리오: 전자상거래 프로젝트

프로젝트: 결제 모듈 개발 및 테스트

1️⃣ 비율 기반 (조직 표준):
   개발 노력: 300MD
   조직 비율: 개발:테스트 = 2:1
   → 테스트 노력: 150MD

2️⃣ 와이드밴드 델파이 (전문가 검증):
   1라운드: 120, 180, 150, 140MD
   논의 후 2라운드: 145, 155, 150, 148MD
   → 합의: 약 150MD

3️⃣ 3점 추정 (불확실성 고려):
   a = 120MD (자동화 잘 됨)
   m = 150MD (표준)
   b = 200MD (많은 결함)
   E = (120 + 4×150 + 200) / 6 = 153MD
   SD = (200-120) / 6 = 13MD
   → 140~166MD 범위

최종 추정: 150MD (±13MD)
예산: 여유 고려하여 170MD 확보 ✅

추정 시 고려사항

1. 작업 분할 (Work Breakdown)

❌ "시스템 테스트" → 너무 큼

✅ 세분화:
   - 기능 테스트: 60MD
   - 성능 테스트: 20MD
   - 보안 테스트: 15MD
   - 사용성 테스트: 10MD
   - 리그레션 테스트: 25MD
   ────────────────
   합계: 130MD

2. 추정치 업데이트

초기 추정: 150MD
2주 후 실제: 35MD 소요 (계획: 25MD)
→ 외삽: (35/25) × 150 = 210MD
→ 추정 재조정 필요 ⚠️

3. 버퍼 포함

기본 추정: 150MD
리스크 버퍼: 20% (30MD)
최종 예산: 180MD

FL-5.1.5 (K3) 테스트 케이스에 우선순위를 적용할 수 있다 (상세: 5.1.5절)

답변:

테스트 케이스 우선순위지정이란?

테스트 스위트를 테스트 일정으로 구성하여 테스트 실행 순서를 정의하는 것

1. 리스크 기반 우선순위지정 (Risk-based prioritization)

원칙: 리스크 분석 결과에 따라 실행 순서 결정

방법:

리스크 분석:

기능 A (결제): 리스크 수준 = 높음 (발생 가능성: 중, 영향: 매우 높음)
기능 B (검색): 리스크 수준 = 중간 (발생 가능성: 높음, 영향: 낮음)
기능 C (리뷰): 리스크 수준 = 낮음 (발생 가능성: 낮음, 영향: 낮음)

우선순위:
1순위: 결제 테스트 (TC-001 ~ TC-020)
2순위: 검색 테스트 (TC-021 ~ TC-035)
3순위: 리뷰 테스트 (TC-036 ~ TC-045)

실무 예시:

전자상거래 시스템

리스크 매트릭스:
┌─────────────┬──────┬──────┬───────┐
│   기능      │ 발생 │ 영향 │리스크 │
├─────────────┼──────┼──────┼───────┤
│ 결제        │  7   │  10  │  70   │ ← 1순위
│ 주문        │  6   │   9  │  54   │ ← 2순위
│ 장바구니    │  5   │   7  │  35   │ ← 3순위
│ 상품 검색   │  8   │   4  │  32   │ ← 4순위
│ 위시리스트  │  4   │   5  │  20   │ ← 5순위
└─────────────┴──────┴──────┴───────┘

테스트 실행 순서:
Week 1: 결제 테스트 (고위험)
Week 2: 주문 테스트 (고위험)
Week 3: 장바구니 + 검색 (중위험)
Week 4: 위시리스트 + 리그레션 (저위험)

2. 커버리지 기반 우선순위지정 (Coverage-based prioritization)

원칙: 가장 높은 커버리지를 달성하는 TC를 먼저 실행

방법:

기본 커버리지 우선순위:

코드 커버리지:

TC-001: 구문 커버리지 45% (함수 A, B, C)
TC-002: 구문 커버리지 30% (함수 D, E)
TC-003: 구문 커버리지 25% (함수 F)

우선순위:
1. TC-001 (커버리지 45%)
2. TC-002 (커버리지 30%)
3. TC-003 (커버리지 25%)

추가 커버리지 우선순위 (Additional Coverage):

초기 상태: 커버리지 0%

1단계:
TC-001 실행 → 45% 커버 (함수 A, B, C)

2단계 (남은 TC 중 선택):
TC-002: +30% → 총 75% (함수 D, E 추가)
TC-003: +10% → 총 55% (함수 F 일부만, A 중복)
→ TC-002 선택 ✅

3단계:
TC-003 실행 → +10% → 총 85%

최종 실행 순서: TC-001 → TC-002 → TC-003

실무 예시:

요구사항 커버리지:

10개 요구사항 (R1~R10)

TC-001: R1, R2, R3 커버 (30%)
TC-002: R2, R4, R5, R6 커버 (40%)
TC-003: R7, R8 커버 (20%)
TC-004: R3, R9, R10 커버 (30%)

추가 커버리지 방식:
1. TC-002 실행 → 40% (R2, R4, R5, R6)
2. TC-001 실행 → +20% (R1, R3 추가) → 60%
3. TC-004 실행 → +20% (R9, R10 추가) → 80%
4. TC-003 실행 → +20% (R7, R8 추가) → 100%

실행 순서: TC-002 → TC-001 → TC-004 → TC-003

3. 요구사항 기반 우선순위지정 (Requirement-based prioritization)

원칙: 요구사항의 우선순위(이해관계자 정의)에 따라 실행 순서 결정

방법:

이해관계자 우선순위:

요구사항 R1 (로그인): 우선순위 = 높음 (Must-have)
요구사항 R2 (결제): 우선순위 = 높음 (Must-have)
요구사항 R3 (알림): 우선순위 = 중간 (Should-have)
요구사항 R4 (테마): 우선순위 = 낮음 (Nice-to-have)

테스트 우선순위:
1순위: TC-001~010 (R1 로그인)
1순위: TC-011~025 (R2 결제)
2순위: TC-026~035 (R3 알림)
3순위: TC-036~040 (R4 테마)

MoSCoW 방법:

Must-have (필수):
- TC-001~020: 사용자 인증
- TC-021~040: 결제 처리
→ 1순위 실행

Should-have (권장):
- TC-041~055: 상품 추천
- TC-056~065: 리뷰 기능
→ 2순위 실행

Could-have (선택):
- TC-066~075: 소셜 공유
→ 3순위 실행

Won't-have (제외):
- (이번 릴리스에서 제외)

우선순위 지정 시 추가 고려사항

1. 종속성 (Dependencies)

이상적인 우선순위:
1. TC-결제 (고위험)
2. TC-주문 (중위험)
3. TC-로그인 (저위험)

실제 종속성:
TC-결제 → TC-주문에 의존 (주문 먼저 필요)
TC-주문 → TC-로그인에 의존 (로그인 먼저 필요)

실제 실행 순서:
1. TC-로그인 ✅ (종속성 없음)
2. TC-주문 ✅ (로그인 완료)
3. TC-결제 ✅ (주문 완료)

2. 자원 가용성 (Resource availability)

우선순위:
1. TC-성능 (고위험)
2. TC-보안 (고위험)
3. TC-기능 (중위험)

자원 제약:
- 성능 테스트: 특수 환경 필요 (Week 3만 가능)
- 보안 테스트: 전문가 필요 (Week 2만 가능)
- 기능 테스트: 항상 가능

실제 일정:
Week 1: TC-기능 (자원 가용)
Week 2: TC-보안 (전문가 가용)
Week 3: TC-성능 (환경 가용)

통합 우선순위 전략

복합 접근법:

프로젝트: 은행 앱

1단계: 리스크 분석
┌──────────┬────────┬────────┬────────┐
│   기능   │ 리스크 │ 요구사항│ 커버리지│
├──────────┼────────┼────────┼────────┤
│ 송금     │  9/10  │  Must  │  35%   │
│ 잔액조회 │  7/10  │  Must  │  20%   │
│ 거래내역 │  5/10  │ Should │  25%   │
│ 알림설정 │  3/10  │ Could  │  15%   │
└──────────┴────────┴────────┴────────┘

2단계: 종합 점수 계산
송금: (리스크 9 × 0.5) + (요구사항 3 × 0.3) + (커버리지 35 × 0.2) = 12.4
잔액조회: (7 × 0.5) + (3 × 0.3) + (20 × 0.2) = 8.4
거래내역: (5 × 0.5) + (2 × 0.3) + (25 × 0.2) = 8.1
알림설정: (3 × 0.5) + (1 × 0.3) + (15 × 0.2) = 4.8

3단계: 우선순위 결정
1순위: 송금 테스트 ⭐⭐⭐
2순위: 잔액조회 테스트 ⭐⭐
3순위: 거래내역 테스트 ⭐
4순위: 알림설정 테스트

실무 시나리오

시나리오: 2주 스프린트, 시간 부족

상황:
- 총 50개 TC
- 가용 시간: 3일 (모든 TC 불가능)
- 우선순위 필요

우선순위 매트릭스:
High Priority (P1): 20개 TC
  - 결제: TC-001~010
  - 로그인: TC-011~020

Medium Priority (P2): 20개 TC
  - 검색: TC-021~030
  - 장바구니: TC-031~040

Low Priority (P3): 10개 TC
  - 위시리스트: TC-041~050

실행 계획:
Day 1: P1 실행 (20개) - 필수
Day 2: P2 실행 가능한 만큼 (~15개)
Day 3: 리그레션 + P2 나머지

결과:
- P1: 100% 실행 ✅
- P2: 75% 실행
- P3: 0% 실행 (다음 스프린트로 이월)

계속 진행하겠습니다!

FL-5.1.6 (K1) 테스트 피라미드의 개념을 상기할 수 있다 (상세: 5.1.6절)

답변:

테스트 피라미드란?

정의: 테스트의 세분화 수준(granularity)이 다를 수 있음을 보여주는 모델

목적:

테스트 자동화 수준 결정 지원
테스트 노력 할당 가이드
효율적인 테스트 전략 수립

테스트 피라미드 구조

        ┌─────────────┐
        │   UI 테스트  │  ← 상위: 적은 수, 느림, 복잡
        │  (E2E)      │
        ├─────────────┤
        │             │
        │ 통합 테스트  │  ← 중간: 중간 수, 중간 속도
        │ (API)       │
        │             │
        ├─────────────┤
        │             │
        │             │
        │ 단위 테스트  │  ← 하위: 많은 수, 빠름, 단순
        │ (Unit)      │
        │             │
        │             │
        └─────────────┘

피라미드의 각 층 특징

특성	하위층 (단위)	중간층 (통합)	상위층 (E2E)
테스트 크기	작음 (Small)	중간 (Medium)	큼 (Large)
실행 속도	빠름 (초 단위)	중간 (분 단위)	느림 (시간 단위)
격리성	높음 (독립적)	중간	낮음 (의존적)
세분화	높음 (함수 단위)	중간 (컴포넌트)	낮음 (시스템)
테스트 수	많음 (수백~수천)	중간 (수십~수백)	적음 (수개~수십)
유지보수	쉬움	중간	어려움
실패 분석	쉬움	중간	어려움
자동화	필수	권장	선택적
피드백	즉각	빠름	느림

피라미드 층별 상세

1층: 단위(컴포넌트) 테스트

특징:
- 개별 함수/메서드 테스트
- 외부 의존성 모킹
- 초 단위 실행
- 개발자가 작성

예시:
✅ calculateTotal(items) 함수 테스트
✅ validateEmail(email) 함수 테스트
✅ User 클래스 메서드 테스트

테스트 수: 1000개
실행 시간: 2분
커버리지: 함수의 80%

2층: 통합(컴포넌트 통합) 테스트

특징:
- 컴포넌트 간 상호작용
- API/서비스 레벨
- 분 단위 실행
- 실제 DB/외부 서비스 일부 사용

예시:
✅ 결제 서비스 + DB 통합
✅ API 엔드포인트 테스트
✅ 마이크로서비스 간 통신

테스트 수: 100개
실행 시간: 15분
커버리지: 주요 통합 지점

3층: E2E(엔드-투-엔드) 테스트

특징:
- 전체 사용자 시나리오
- UI를 통한 테스트
- 시간 단위 실행
- 실제 환경과 유사

예시:
✅ 로그인 → 상품 검색 → 장바구니 → 결제 전체 플로우
✅ 사용자 가입부터 첫 주문까지
✅ 관리자 대시보드 주요 기능

테스트 수: 20개
실행 시간: 2시간
커버리지: 크리티컬 경로

피라미드 모델의 변형

원래 모델 (Cohn 2009):

┌──────────────┐
│  UI 테스트    │
├──────────────┤
│ 서비스 테스트 │
├──────────────┤
│  단위 테스트  │
└──────────────┘

일반적 모델:

┌──────────────┐
│ E2E 테스트    │
├──────────────┤
│ 통합 테스트   │
├──────────────┤
│ 단위 테스트   │
└──────────────┘

확장 모델 (4층):

┌──────────────┐
│ 수동 탐색적  │
├──────────────┤
│ E2E 자동화   │
├──────────────┤
│ 통합 테스트  │
├──────────────┤
│ 단위 테스트  │
└──────────────┘

실무 적용 예시

예시 1: 전자상거래 앱

단위 테스트 (700개):
- 가격 계산 로직
- 할인 적용 함수
- 유효성 검증 함수
- 데이터 변환 유틸
→ 매 커밋마다 실행 (CI)

통합 테스트 (80개):
- 결제 API + DB
- 주문 서비스 + 재고 서비스
- 인증 서비스 + 사용자 DB
→ PR마다 실행

E2E 테스트 (15개):
- 신규 사용자 가입 → 첫 구매
- 기존 사용자 로그인 → 재구매
- 관리자 상품 등록 → 판매
→ 배포 전 실행 (nightly)

결과:
✅ 빠른 피드백 (단위: 3분)
✅ 통합 검증 (통합: 20분)
✅ 엔드투엔드 확인 (E2E: 1시간)

예시 2: 마이크로서비스 아키텍처

                    E2E (10개)
                    1시간 실행
                 ┌──────────────┐
                 │ 전체 플로우   │
                 └──────────────┘
                        ↑
              통합 테스트 (120개)
              30분 실행
         ┌────────────────────────┐
         │ 서비스 A ↔ 서비스 B     │
         │ 서비스 B ↔ DB          │
         │ API Gateway            │
         └────────────────────────┘
                        ↑
          단위 테스트 (1500개)
          5분 실행
    ┌──────────────────────────────┐
    │ 서비스 A 함수들 (500개)       │
    │ 서비스 B 함수들 (600개)       │
    │ 공통 라이브러리 (400개)       │
    └──────────────────────────────┘

비율: 75% : 20% : 5%

피라미드가 주는 교훈

1. 아래층에 더 많은 테스트

❌ 안티패턴 (아이스크림 콘):
   E2E: 200개 ← 너무 많음
   통합: 50개
   단위: 30개 ← 너무 적음
   → 느림, 불안정, 유지보수 어려움

✅ 올바른 피라미드:
   E2E: 20개
   통합: 100개
   단위: 500개
   → 빠름, 안정적, 유지보수 쉬움

2. 적절한 커버리지 배분

전체 기능 100개

단위 테스트로 커버:
- 비즈니스 로직: 80개
- 유틸리티: 15개
→ 95% 기능의 핵심 로직 검증

통합 테스트로 커버:
- 주요 통합 지점: 70개
→ 70% 통합 시나리오 검증

E2E 테스트로 커버:
- 크리티컬 경로: 20개
→ 20% 중요 사용자 플로우 검증

결과: 중복 최소화, 효율 최대화

3. 실행 시간 최적화

목표: 개발자 피드백 10분 이내

피라미드 적용:
- 단위 (500개): 3분 ✅
- 통합 (50개): 7분 ✅
→ 총 10분, 목표 달성

피라미드 미적용:
- E2E 위주 (200개): 2시간 ❌
→ 개발자 생산성 저하

테스트 피라미드 vs 다른 모델

테스트 다이아몬드:

      ┌───┐
      │E2E│
     ┌─────┐
     │통합  │ ← 가장 많음
     └─────┘
      ┌───┐
      │단위│
      └───┘

- 통합 테스트 중심
- 마이크로서비스에 적합

테스트 트로피:

    ┌───────┐
    │ E2E   │
   ┌─────────┐
   │ 통합    │ ← 가장 많음
   └─────────┘
  ┌───────────┐
  │ 단위      │
  └───────────┘

- 통합 테스트 강조
- Kent C. Dodds 제안

FL-5.1.7 (K2) 테스팅 사분면과 그것이 테스트 레벨 및 유형과 갖는 관계를 요약할 수 있다 (상세: 5.1.7절)

답변:

테스팅 사분면이란?

정의: Brian Marick이 정의한 모델로, 애자일에서 테스트 레벨을 적합한 테스트 유형, 활동, 기법, 산출물과 연결

목적:

필요한 모든 테스트 유형을 SDLC에 포함
테스트 레벨별 테스트 유형 연관성 이해
개발자/테스터/비즈니스 담당자 간 의사소통 도구

사분면 구조

           비즈니스 측면 (Business-facing)
                    ↑
                    │
    ┌───────────────┼───────────────┐
    │               │               │
    │   Q2          │          Q3   │
    │  팀 지원      │       제품 평가│
    │               │               │
팀  ├───────────────┼───────────────┤ 제품
지원│               │               │평가
    │   Q1          │          Q4   │
    │  팀 지원      │       제품 평가│
    │               │               │
    └───────────────┼───────────────┘
                    │
                    ↓
           기술 측면 (Technology-facing)

Q1 사분면: 기술 측면, 팀 지원

특징:

개발을 가이드하는 테스트
기술적, 내부적 품질
자동화 필수
CI/CD 통합

테스트 유형:

✅ 컴포넌트 테스트 (단위 테스트)
   - 개별 함수/클래스 테스트
   - TDD 실천
   
✅ 컴포넌트 통합 테스트
   - 모듈 간 인터페이스
   - API 테스트

활동 및 기법:

- TDD (Test-Driven Development)
- 코드 커버리지 측정
- 복잡도 분석
- 정적 분석

실무 예시:

스프린트 작업:

Daily (개발 중):
┌─────────────────────────────┐
│ 1. 단위 테스트 작성 (TDD)   │
│    - 함수별 테스트           │
│    - Mock/Stub 활용         │
│                             │
│ 2. 매 커밋 시 CI 실행       │
│    - 1000개 단위 테스트     │
│    - 3분 내 완료            │
│                             │
│ 3. 코드 리뷰 시 확인        │
│    - 커버리지 80% 이상      │
│    - 복잡도 10 이하         │
└─────────────────────────────┘

결과: 코드 품질 보장, 리팩토링 자신감

Q2 사분면: 비즈니스 측면, 팀 지원

특징:

기능이 올바르게 구현되었는지 확인
비즈니스 요구사항 검증
수동 또는 자동화
인수 조건 확인

테스트 유형:

✅ 기능 테스트
   - 사용자 스토리 기반
   - 비즈니스 규칙 검증

✅ 예제 기반 테스트
   - 구체적 시나리오
   - Given-When-Then

✅ 사용자 경험 프로토타입
   - UI/UX 검증

✅ API 테스팅
   - 비즈니스 로직 API

✅ 시뮬레이션
   - 프로세스 플로우

활동 및 기법:

- ATDD (Acceptance Test-Driven Development)
- BDD (Behavior-Driven Development)
- 예제 매핑
- 3 Amigos 세션
- 인수 조건 작성

실무 예시:

스프린트 시작 (계획):
┌─────────────────────────────┐
│ 사용자 스토리:              │
│ "고객이 상품을 장바구니에   │
│  담을 수 있다"              │
│                             │
│ 3 Amigos 세션:              │
│ - PO: 비즈니스 규칙 설명    │
│ - 개발자: 기술적 제약        │
│ - 테스터: 테스트 시나리오   │
│                             │
│ 인수 조건 (예시):           │
│ Given 로그인한 사용자       │
│ When 상품 "담기" 클릭       │
│ Then 장바구니 개수 +1       │
│  And 총액 업데이트          │
└─────────────────────────────┘

스프린트 중 (개발):
- Cucumber/SpecFlow로 자동화
- 매일 실행하여 진행 상황 확인

스프린트 종료 (리뷰):
- PO가 직접 확인
- 데모 시연

Q3 사분면: 비즈니스 측면, 제품 평가

특징:

사용자 관점 평가
수동 테스트 중심
실제 사용자 피드백
발견적, 탐험적

테스트 유형:

✅ 탐색적 테스팅
   - 자유로운 탐험
   - 테스트 차터

✅ 사용성 테스팅
   - UX 평가
   - 사용 편의성

✅ 사용자 인수 테스팅 (UAT)
   - 실제 사용자 검증
   - 비즈니스 목표 달성

✅ 알파/베타 테스팅
   - 제한된 사용자 그룹
   - 실제 환경

활동 및 기법:

- 탐색적 테스트 세션
- 페르소나 기반 테스트
- A/B 테스팅
- 사용자 피드백 수집

실무 예시:

스프린트 종료 후:
┌─────────────────────────────┐
│ 탐색적 테스팅 (2시간):      │
│                             │
│ Charter:                    │
│ "결제 플로우의 사용성과     │
│  예상치 못한 동작 탐색"     │
│                             │
│ 발견사항:                   │
│ - 뒤로가기 시 데이터 손실   │
│ - 오류 메시지 불명확        │
│ - 로딩 시간 길게 느껴짐     │
│                             │
│ 액션:                       │
│ - 결함 보고: DEF-123        │
│ - 개선 제안: US-456         │
└─────────────────────────────┘

UAT (릴리스 전 1주):
- 실제 고객 5명 초대
- 실제 업무 시나리오 수행
- 피드백 수집 및 반영

Q4 사분면: 기술 측면, 제품 평가

특징:

비기능적 품질 특성
기술적 리스크 평가
자동화 권장
전문 도구 필요

테스트 유형:

✅ 스모크 테스트
   - 기본 동작 확인
   - 배포 후 즉시

✅ 비기능 테스트:
   - 성능 테스트 (응답 시간, 처리량)
   - 부하/스트레스 테스트
   - 보안 테스트 (취약점, 침투)
   - 안정성 테스트
   - 호환성 테스트
   - 복구 테스트

활동 및 기법:

- 성능 모니터링
- 보안 스캔
- 카오스 엔지니어링
- 인프라 테스트

실무 예시:

CI/CD 파이프라인:
┌─────────────────────────────┐
│ 1. 빌드 & Q1 테스트 (3분)   │
│    └→ 단위/통합 자동화      │
│                             │
│ 2. 배포 to Staging          │
│                             │
│ 3. 스모크 테스트 (5분)      │
│    - 주요 엔드포인트 확인   │
│    - 헬스체크               │
│                             │
│ 4. 성능 테스트 (30분)       │
│    - 동시 사용자 1000명     │
│    - 응답시간 < 2초         │
│    - CPU < 70%              │
│                             │
│ 5. 보안 스캔 (20분)         │
│    - OWASP Top 10 체크      │
│    - 취약점 스캔            │
│                             │
│ Pass → Production 배포      │
│ Fail → 알림 + 롤백          │
└─────────────────────────────┘

Nightly (매일 밤):
- 전체 리그레션 (2시간)
- 상세 성능 프로파일링
- 보안 심층 스캔

사분면 간 관계 및 균형

프로젝트 단계별 사분면 활용:

스프린트 시작:
├─ Q2: 인수 조건 정의 (3 Amigos)
└─ Q1: 테스트 케이스 작성 계획

스프린트 진행:
├─ Q1: TDD로 개발 (지속적)
├─ Q2: 기능 테스트 자동화 (지속적)
└─ Q4: CI/CD 파이프라인 실행 (매 커밋)

스프린트 종료:
├─ Q3: 탐색적 테스팅 (수동)
├─ Q3: UAT 준비
└─ Q4: 성능/보안 종합 테스트

릴리스 전:
├─ Q3: 사용자 인수 테스팅
├─ Q4: 최종 비기능 검증
└─ 모든 사분면 결과 종합 리뷰

사분면별 비중 (일반적 가이드)

노력 배분 예시:

전통적 프로젝트:
Q1: 30% (단위/통합)
Q2: 30% (기능 테스트)
Q3: 20% (수동 탐색)
Q4: 20% (비기능)

애자일 프로젝트:
Q1: 35% (TDD 강조)
Q2: 35% (ATDD/BDD)
Q3: 15% (탐색적)
Q4: 15% (자동화된 비기능)

DevOps 성숙 조직:
Q1: 40% (광범위 자동화)
Q2: 30% (BDD 완전 자동화)
Q3: 10% (최소 수동)
Q4: 20% (지속적 모니터링)

사분면과 테스트 레벨 매핑

┌──────────────┬────┬────┬────┬────┐
│ 테스트 레벨 │ Q1 │ Q2 │ Q3 │ Q4 │
├──────────────┼────┼────┼────┼────┤
│ 컴포넌트     │ ●● │ ○  │    │ ○  │
│ 통합         │ ●● │ ○  │    │ ○  │
│ 시스템       │ ○  │ ●● │ ●  │ ●● │
│ 인수         │    │ ●● │ ●● │ ○  │
└──────────────┴────┴────┴────┴────┘

●● = 주요 활동
●  = 일반 활동
○  = 일부 활동

실무 통합 예시: 전자상거래 스프린트

2주 스프린트: "장바구니 기능"

Week 1:
┌─ Day 1-2: 계획 & 설계
│  ├─ Q2: 3 Amigos - 인수 조건
│  └─ Q1: 단위 테스트 계획
│
├─ Day 3-8: 개발
│  ├─ Q1: TDD로 개발 (지속적)
│  │      - 500개 단위 테스트
│  │      - CI에서 3분 실행
│  │
│  ├─ Q2: BDD 시나리오 자동화
│  │      - 30개 Cucumber 시나리오
│  │      - 매일 실행
│  │
│  └─ Q4: 성능 체크 (매 커밋)
│         - 응답시간 모니터링
│
Week 2:
├─ Day 9: 통합 & 안정화
│  ├─ Q1: 통합 테스트 (100개)
│  └─ Q4: 부하 테스트 (1000 동시 사용자)
│
├─ Day 10: 탐색 & 검증
│  ├─ Q3: 탐색적 테스팅 (4시간)
│  │      - 예상치 못한 동작 발견
│  │      - 5개 개선사항 식별
│  │
│  └─ Q2: PO 최종 인수
│         - 모든 인수 조건 확인
│
└─ 릴리스 준비
   ├─ Q4: 최종 보안/성능 검증
   └─ Q3: UAT 계획

이제 5.2 리스크 관리로 넘어가겠습니다!

5.2 리스크 관리

FL-5.2.1 (K1) 리스크 발생 가능성과 리스크 영향도를 활용해 리스크 수준을 식별할 수 있다 (상세: 5.2.1절)

답변:

리스크의 정의

리스크: 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건, 위험, 위협 또는 상황

리스크의 두 가지 요소

1. 리스크 발생 가능성 (Likelihood/Probability)

리스크가 발생할 확률
0보다 크고 1보다 작은 값
또는 백분율 (0% ~ 100%)

2. 리스크 영향도 (Impact/Damage)

발생했을 때 생기는 피해의 크기
비즈니스, 기술, 재정적 영향

리스크 수준 계산

리스크 수준 (Risk Level) = 발생 가능성 × 영향도

리스크 수준: 리스크를 측정한 값
높을수록 → 조치의 중요도 ↑

정량적 접근법 예시

방법 1: 확률 × 금액

리스크: 결제 시스템 장애

발생 가능성: 5% (0.05)
영향도: 손실액 $100,000

리스크 수준 = 0.05 × $100,000 = $5,000

해석: 예상 손실액 $5,000

방법 2: 점수 × 점수

리스크: 개인정보 유출

발생 가능성: 3 (1~5 척도, 3=중간)
영향도: 5 (1~5 척도, 5=매우 높음)

리스크 수준 = 3 × 5 = 15

척도:
1-5: 낮음
6-10: 중간
11-15: 높음
16-25: 매우 높음

→ 이 리스크는 "높음" (15점)

정성적 접근법: 리스크 매트릭스

3x3 리스크 매트릭스:

영향도
  ↑
높음│  M    H    H
    │
중간│  L    M    H
    │
낮음│  L    L    M
    └──────────────→ 발생 가능성
      낮음  중간  높음

L = Low (낮음)
M = Medium (중간)
H = High (높음)

예시 적용:

리스크 1: 로그인 실패
- 발생 가능성: 중간
- 영향도: 낮음
→ 매트릭스: L (낮음)

리스크 2: 결제 오류
- 발생 가능성: 낮음
- 영향도: 높음
→ 매트릭스: M (중간)

리스크 3: 데이터베이스 손상
- 발생 가능성: 낮음
- 영향도: 높음
→ 매트릭스: M (중간)

리스크 4: 보안 취약점
- 발생 가능성: 높음
- 영향도: 높음
→ 매트릭스: H (높음) ⚠️

5x5 리스크 매트릭스 (더 세밀한 구분)

영향도
  ↑
 5│  M    H    H    VH   VH
  │
 4│  L    M    H    H    VH
  │
 3│  L    L    M    H    H
  │
 2│  VL   L    L    M    H
  │
 1│  VL   VL   L    L    M
  └────────────────────────→ 발생 가능성
    1    2    3    4    5

VL = Very Low (매우 낮음)
L = Low (낮음)
M = Medium (중간)
H = High (높음)
VH = Very High (매우 높음)

실무 예시: 은행 앱 프로젝트

리스크 목록 및 평가:

┌────┬─────────────────┬──────┬──────┬────────┬──────┐
│ ID │ 리스크          │ 발생 │ 영향 │ 수준   │ 우선 │
├────┼─────────────────┼──────┼──────┼────────┼──────┤
│ R1 │ 송금 오류       │  3   │  5   │   15   │  1   │
│ R2 │ 세션 타임아웃   │  4   │  3   │   12   │  2   │
│ R3 │ 비밀번호 강도   │  5   │  2   │   10   │  3   │
│ R4 │ UI 로딩 느림    │  3   │  2   │    6   │  4   │
│ R5 │ 도움말 링크 깨짐│  2   │  1   │    2   │  5   │
└────┴─────────────────┴──────┴──────┴────────┴──────┘

척도 (1-5):
발생 가능성: 1=거의없음, 5=매우높음
영향도: 1=미미, 5=치명적

리스크 수준 = 발생 × 영향

조치 우선순위:
1. R1 (송금 오류): 즉시 대응 ⚠️
2. R2 (세션): 중요
3. R3 (비밀번호): 중요
4. R4 (로딩): 낮음
5. R5 (도움말): 매우 낮음

리스크 수준별 대응 전략

매우 높음 (16-25점 또는 VH):
├─ 즉각적인 조치 필요
├─ 최고 우선순위 테스트
├─ 추가 자원 할당
└─ 경영진 에스컬레이션

높음 (11-15점 또는 H):
├─ 긴급 대응 계획
├─ 집중적인 테스트
└─ 정기 모니터링

중간 (6-10점 또는 M):
├─ 계획된 대응
├─ 표준 테스트
└─ 주기적 검토

낮음 (1-5점 또는 L/VL):
├─ 수용 또는 최소 대응
├─ 기본 테스트
└─ 필요시 재평가

실무 사례: 전자상거래 릴리스

릴리스 D-7일

리스크 평가 회의:

R1: 결제 게이트웨이 장애
    발생: 10% (0.1)
    영향: $500,000 손실
    수준: 0.1 × $500,000 = $50,000
    → 매우 높음 ⚠️

    조치:
    ├─ 결제 기능 집중 테스트 (40MD)
    ├─ 부하 테스트 추가 (10MD)
    ├─ 장애 복구 시나리오 테스트
    └─ 백업 게이트웨이 준비

R2: 상품 이미지 로딩 실패
    발생: 30% (0.3)
    영향: $5,000 손실 (이탈률 증가)
    수준: 0.3 × $5,000 = $1,500
    → 중간

    조치:
    ├─ CDN 테스트 (5MD)
    └─ 이미지 fallback 확인

R3: 추천 알고리즘 부정확
    발생: 40% (0.4)
    영향: $2,000 손실
    수준: 0.4 × $2,000 = $800
    → 낮음

    조치:
    ├─ 기본 검증만 수행
    └─ 다음 릴리스에서 개선

계속 진행하겠습니다!

FL-5.2.2 (K2) 프로젝트 리스크와 제품 리스크를 구별할 수 있다 (상세: 5.2.2절)

답변:

리스크의 두 가지 유형

1. 프로젝트 리스크 (Project Risk)

정의: 프로젝트 관리 및 제어와 관련된 리스크

영향: 프로젝트 일정, 예산, 범위에 영향 → 프로젝트 목표 달성 능력에 영향

범주 및 예시:

조직 문제:

- 작업 산출물 인도 지연
  예: 요구사항 명세서가 2주 늦게 제공됨
  
- 부정확한 추정
  예: 테스트 노력을 150MD로 예상했으나 실제 250MD 필요
  
- 예산 축소
  예: 테스트 예산이 30% 삭감됨

인력 문제:

- 기술 부족
  예: 성능 테스트 경험자가 팀에 없음
  
- 갈등
  예: 개발팀과 테스트팀 간 의사소통 문제
  
- 의사소통 문제
  예: 분산된 팀 간 시차로 인한 지연
  
- 직원 부족
  예: 핵심 테스터가 갑자기 퇴사

기술적 문제:

- 협의되지 않은 범위 증가 (Scope Creep)
  예: 릴리스 직전 새로운 기능 추가 요청
  
- 도구 지원 부족
  예: 자동화 도구가 신기술 스택 미지원
  
- 기술 부채
  예: 레거시 코드 때문에 테스트 어려움

공급업체 문제:

- 제3자 인도 실패
  예: 외주 개발사가 일정 지연
  
- 지원 기업의 파산
  예: 테스트 도구 공급업체 폐업
  
- 계약 이슈
  예: 라이선스 갱신 지연

2. 제품 리스크 (Product Risk)

정의: 제품 품질 특성과 관련된 리스크 (ISO 25010 품질 모델)

영향: 부정적인 결과 초래 (사용자 불만, 손실, 손해 등)

예시:

기능적 결함:

- 누락된 기능
  예: 비밀번호 재설정 기능 미구현
  
- 잘못된 기능
  예: 할인율 계산이 잘못됨
  
- 부정확한 계산
  예: 세금 계산 오류로 과소/과다 청구

비기능적 결함:

- 런타임 오류
  예: 메모리 누수로 앱 크래시
  
- 열악한 아키텍처
  예: 확장성 부족으로 트래픽 급증 시 다운
  
- 비효율적인 알고리즘
  예: O(n²) 알고리즘으로 성능 저하
  
- 부적절한 응답 시간
  예: 페이지 로드 10초 이상 소요
  
- 열악한 UX
  예: 복잡한 네비게이션으로 이탈률 증가
  
- 보안 취약점
  예: SQL Injection 취약점

제품 리스크 발현 시 부정적 결과

1. 사용자 불만족
   → 낮은 평점, 부정적 리뷰

2. 매출 손실
   예: 결제 실패로 거래 취소

3. 신뢰 손실
   예: 개인정보 유출 사고

4. 평판 손실
   예: SNS에서 부정적 확산

5. 제3자 피해
   예: 파트너사 시스템 다운

6. 높은 유지보수 비용
   예: 긴급 패치 반복 배포

7. 고객지원 부서 과부하
   예: 불만 전화 폭주

8. 형사 처벌
   예: 개인정보보호법 위반 벌금

9. 신체적 손상/부상/사망
   예: 의료기기 오작동

프로젝트 리스크 vs 제품 리스크 비교

구분	프로젝트 리스크	제품 리스크
관련	프로젝트 관리/제어	제품 품질
영향 대상	일정, 예산, 범위	최종 사용자, 비즈니스
발생 시점	프로젝트 진행 중	제품 출시 후 (주로)
책임	PM, 관리자	개발팀, 테스트팀
예방 방법	프로젝트 관리	테스팅
예시	테스터 부족	결제 오류

실무 예시 1: 모바일 뱅킹 앱

프로젝트 리스크:

R-P1: 보안 전문가 부족
├─ 카테고리: 인력 문제
├─ 발생 가능성: 높음 (4/5)
├─ 영향: 일정 2주 지연
├─ 리스크 수준: 높음
└─ 완화 조치:
    ├─ 외부 보안 컨설턴트 고용
    └─ 기존 팀원 교육

R-P2: 테스트 환경 구축 지연
├─ 카테고리: 조직 문제
├─ 발생 가능성: 중간 (3/5)
├─ 영향: 테스트 시작 1주 지연
├─ 리스크 수준: 중간
└─ 완화 조치:
    ├─ 클라우드 환경으로 대체
    └─ 병렬 환경 구축 추진

R-P3: 범위 증가 (새 기능 추가 요청)
├─ 카테고리: 기술적 문제
├─ 발생 가능성: 높음 (4/5)
├─ 영향: 예산 20% 초과
├─ 리스크 수준: 높음
└─ 완화 조치:
    ├─ 변경 관리 프로세스 강화
    └─ 범위 동결 시점 명확화

제품 리스크:

R-D1: 송금 기능 오류
├─ 카테고리: 기능적 결함
├─ 발생 가능성: 낮음 (2/5)
├─ 영향: 매우 높음 (5/5)
├─ 리스크 수준: 10 (중-높음)
└─ 완화 조치:
    ├─ 송금 기능 집중 테스트
    ├─ 경계값 분석 적용
    ├─ 보안 테스트 추가
    └─ UAT 필수

R-D2: 개인정보 유출
├─ 카테고리: 보안 취약점
├─ 발생 가능성: 낮음 (2/5)
├─ 영향: 매우 높음 (5/5)
├─ 리스크 수준: 10 (중-높음)
└─ 완화 조치:
    ├─ 침투 테스트 수행
    ├─ 암호화 검증
    └─ 보안 감사

R-D3: 응답 시간 지연
├─ 카테고리: 성능 문제
├─ 발생 가능성: 중간 (3/5)
├─ 영향: 중간 (3/5)
├─ 리스크 수준: 9 (중간)
└─ 완화 조치:
    ├─ 부하 테스트 수행
    ├─ 병목 지점 분석
    └─ 최적화 적용

실무 예시 2: 전자상거래 릴리스

프로젝트 상황:
- 목표: 블랙프라이데이 세일 전 출시 (D-30)
- 팀: 개발 5명, 테스트 3명
- 예산: $200,000

리스크 분석 결과:

┌─────────────────────────────────────────────┐
│ 프로젝트 리스크 (프로젝트 목표에 영향)      │
├─────────────────────────────────────────────┤
│ P1. 핵심 개발자 휴가 (2주)                  │
│     → 영향: 일정 지연                       │
│     → 조치: 지식 이전, 백업 인력            │
│                                             │
│ P2. 결제 API 통합 지연 (외부 업체)          │
│     → 영향: 핵심 기능 테스트 불가           │
│     → 조치: 목업 데이터로 선행 테스트       │
│                                             │
│ P3. 자동화 도구 라이선스 만료               │
│     → 영향: 회귀 테스트 수동으로 전환       │
│     → 조치: 긴급 구매 승인 요청             │
└─────────────────────────────────────────────┘

┌─────────────────────────────────────────────┐
│ 제품 리스크 (제품 품질에 영향)              │
├─────────────────────────────────────────────┤
│ D1. 동시 접속 폭주 시 서버 다운             │
│     → 영향: 매출 손실, 평판 손상            │
│     → 조치: 부하 테스트 집중                │
│                                             │
│ D2. 할인 쿠폰 중복 사용 가능                │
│     → 영향: 금전적 손실                     │
│     → 조치: 쿠폰 로직 집중 테스트           │
│                                             │
│ D3. 모바일 UI 깨짐                          │
│     → 영향: 사용자 경험 저하                │
│     → 조치: 다양한 디바이스 테스트          │
└─────────────────────────────────────────────┘

리스크 유형별 대응 전략

프로젝트 리스크 대응:

프로젝트 관리 강화:
├─ 일정 관리
│  ├─ 버퍼 시간 확보
│  ├─ 크리티컬 패스 모니터링
│  └─ 마일스톤 정기 리뷰
│
├─ 자원 관리
│  ├─ 백업 인력 계획
│  ├─ 외부 지원 옵션
│  └─ 교육 프로그램
│
└─ 의사소통 강화
   ├─ 데일리 스탠드업
   ├─ 주간 리스크 리뷰
   └─ 이해관계자 보고

제품 리스크 대응:

테스팅 강화:
├─ 테스트 범위 확대
│  ├─ 고위험 기능 집중
│  ├─ 비기능 테스트 추가
│  └─ 탐색적 테스팅
│
├─ 품질 활동 강화
│  ├─ 정적 분석
│  ├─ 코드 리뷰
│  └─ 페어 프로그래밍
│
└─ 모니터링 강화
   ├─ 결함 추세 분석
   ├─ 품질 메트릭 추적
   └─ 조기 경보 시스템

FL-5.2.3 (K2) 제품 리스크 분석이 철저함과 테스트 범위에 미치는 영향에 대해 설명할 수 있다 (상세: 5.2.3절)

답변:

제품 리스크 분석의 목표

목표: 잔존 제품 리스크 수준을 최소화하도록 테스트 노력 집중

시기: SDLC 초기에 시작하는 것이 이상적

제품 리스크 분석 프로세스

1. 리스크 식별 (Risk Identification)

목적: 포괄적인 리스크 목록 생성

기법:

브레인스토밍 (Brainstorming):
├─ 팀 전체가 자유롭게 아이디어 제시
├─ 비판 없이 모든 의견 수렴
└─ 30-60분 세션

워크숍 (Workshops):
├─ 구조화된 세션
├─ 퍼실리테이터 주도
└─ 여러 이해관계자 참여

인터뷰 (Interviews):
├─ 전문가/이해관계자 1:1
├─ 심층적 정보 수집
└─ 특수 영역 리스크 발굴

원인-결과 다이어그램 (Fishbone Diagram):
├─ 시각적 분석 도구
├─ 근본 원인 파악
└─ 연쇄 효과 이해

예시: 브레인스토밍

팀 세션: "결제 모듈 리스크는?"

참가자: PM, 개발자 3명, 테스터 2명, BA 1명

식별된 리스크:
1. 카드 번호 유효성 검증 오류
2. 동시 결제 처리 시 데이터 손상
3. 네트워크 타임아웃 처리 미흡
4. 환불 처리 로직 오류
5. PCI-DSS 규정 미준수
6. 외환 환율 계산 오류
7. 결제 내역 조회 성능 저하
8. 3D Secure 인증 실패
9. 부분 취소 처리 오류
10. 중복 결제 발생 가능
... (총 25개 식별)

2. 리스크 평가 (Risk Assessment)

활동:

리스크 분류
발생 가능성/영향/수준 결정
우선순위 지정
조치 방법 제안

정량적 방법:

리스크 수준 = 발생 가능성 × 영향도

예:
R1: 결제 오류
   발생: 0.05 (5%)
   영향: $100,000
   수준: $5,000

정성적 방법: 리스크 매트릭스

영향도
  ↑
높음│  M    H    H
    │
중간│  L    M    H
    │
낮음│  L    L    M
    └──────────────→ 발생 가능성
      낮음  중간  높음

리스크 분석이 테스팅에 미치는 영향

1. 테스트 범위 결정

리스크 분석 결과:
┌────────────────┬────────┬────────┐
│ 기능           │ 리스크 │ 테스트 │
├────────────────┼────────┼────────┤
│ 결제           │  높음  │ 100%   │
│ 주문           │  중간  │  80%   │
│ 검색           │  낮음  │  50%   │
│ 위시리스트     │ 매우낮 │  30%   │
└────────────────┴────────┴────────┘

테스트 범위 결정:
- 고위험: 모든 시나리오 + 경계값 + 예외
- 중위험: 주요 시나리오 + 일부 예외
- 저위험: 기본 시나리오만

예시:

결제 기능 (고위험):
✅ 정상 결제
✅ 다양한 카드사
✅ 국내/해외 카드
✅ 할인/쿠폰 적용
✅ 부분 취소
✅ 전체 취소
✅ 환불
✅ 네트워크 오류
✅ 타임아웃
✅ 동시 결제
✅ 중복 결제 방지
✅ 보안 (암호화)
✅ PCI-DSS 준수
→ 80개 테스트 케이스

위시리스트 (저위험):
✅ 추가
✅ 삭제
✅ 조회
→ 5개 테스트 케이스

2. 테스트 레벨 결정

리스크 수준에 따른 테스트 레벨:

고위험 기능:
├─ 컴포넌트 테스트 (개발자)
├─ 컴포넌트 통합 테스트
├─ 시스템 테스트 (테스터)
├─ 시스템 통합 테스트
└─ 사용자 인수 테스트 ✅ 모든 레벨

중위험 기능:
├─ 컴포넌트 테스트
├─ 시스템 테스트
└─ (선택적) 인수 테스트

저위험 기능:
├─ 컴포넌트 테스트
└─ (최소) 시스템 테스트

3. 테스트 유형 제안

리스크 → 테스트 유형 매핑:

보안 리스크 (높음):
├─ 침투 테스트
├─ 취약점 스캔
├─ 인증/권한 테스트
└─ 암호화 검증

성능 리스크 (중간):
├─ 부하 테스트
├─ 스트레스 테스트
└─ 응답시간 측정

사용성 리스크 (낮음):
├─ (간단한) 사용성 테스트
└─ 탐색적 테스팅

예시:

은행 앱 리스크 분석:

R1: 송금 오류 (리스크: 높음)
→ 테스트 유형:
   ✅ 기능 테스트 (모든 시나리오)
   ✅ 보안 테스트 (인증/권한)
   ✅ 성능 테스트 (대용량 처리)
   ✅ 복구 테스트 (장애 시나리오)
   ✅ 사용자 인수 테스트

R2: 거래내역 조회 느림 (리스크: 중간)
→ 테스트 유형:
   ✅ 성능 테스트 (응답시간)
   ✅ 기능 테스트 (주요 시나리오)

R3: 알림 설정 UI 복잡 (리스크: 낮음)
→ 테스트 유형:
   ✅ 사용성 테스트 (간단히)
   ✅ 기능 테스트 (기본만)

4. 테스트 기법과 커버리지 결정

리스크 → 테스트 기법:

고위험:
├─ 동등 분할 + 경계값 분석
├─ 결정 테이블
├─ 상태 전이 테스팅
├─ 유스케이스 테스팅
└─ 목표 커버리지: 95%+

중위험:
├─ 동등 분할
├─ 경계값 분석
└─ 목표 커버리지: 80%

저위험:
├─ 동등 분할 (대표값만)
└─ 목표 커버리지: 60%

예시:

결제 금액 입력 (고위험):

동등 분할:
- 유효: 1원 ~ 1,000,000원
- 무효: 0원 이하, 1,000,000원 초과

경계값 분석:
- 0원 (무효)
- 1원 (유효 - 최소)
- 1,000,000원 (유효 - 최대)
- 1,000,001원 (무효)

추가 테스트:
- 소수점 입력
- 음수 입력
- 문자 입력
- 특수문자 입력
- 공백
- NULL

→ 20개 테스트 케이스

5. 테스트 노력 추정

리스크 기반 노력 배분:

총 테스트 노력: 200MD

고위험 (3개 기능):
- 배분: 60% (120MD)
- 기능당: 40MD

중위험 (5개 기능):
- 배분: 30% (60MD)
- 기능당: 12MD

저위험 (10개 기능):
- 배분: 10% (20MD)
- 기능당: 2MD

비교:

리스크 분석 없이 (균등 배분):
18개 기능 × 11MD = 198MD
→ 비효율적

리스크 기반 배분:
- 결제 (고위험): 40MD ✅
- 위시리스트 (저위험): 2MD ✅
→ 효율적, 리스크 최소화

6. 테스트 우선순위 지정

리스크 기반 테스트 우선순위:

Week 1 (고위험):
├─ 결제 기능
├─ 로그인/인증
└─ 개인정보 처리

Week 2 (중위험):
├─ 주문 관리
├─ 재고 관리
└─ 배송 추적

Week 3 (저위험):
├─ 추천 시스템
├─ 리뷰 기능
└─ 위시리스트

Week 4 (리그레션):
└─ 전체 통합 테스트

7. 테스팅 외 활동 판단

리스크 완화 옵션:

테스팅으로 완화:
├─ 집중적인 테스트 수행
├─ 추가 테스트 레벨
└─ 자동화 투자

테스팅 외 방법:
├─ 설계 개선
├─ 코드 리뷰 강화
├─ 페어 프로그래밍
├─ 프로토타입 작성
├─ 정적 분석
└─ 아키텍처 리뷰

리스크 수용:
├─ 낮은 리스크
├─ 비용-효과 낮음
└─ 문서화 및 모니터링

리스크 전가:
├─ 보험
├─ 외부 서비스 활용
└─ 계약 조항

예시:

고위험: 결제 시스템 장애
└─ 완화:
    ├─ 집중 테스팅 (테스팅)
    ├─ 코드 리뷰 2회 (테스팅 외)
    ├─ 보안 감사 (테스팅 외)
    └─ 백업 시스템 (테스팅 외)

중위험: 검색 성능
└─ 완화:
    ├─ 성능 테스트 (테스팅)
    └─ 알고리즘 최적화 (테스팅 외)

저위험: 도움말 링크 깨짐
└─ 수용:
    └─ 기본 테스트만, 다음 릴리스에서 수정

철저함에 미치는 영향

철저함 (Thoroughness) = 테스트의 깊이와 범위

리스크 분석 적용 전:
- 모든 기능 동등하게 테스트
- 제한된 자원으로 피상적 테스트
- 중요 결함 놓칠 위험 ↑

리스크 분석 적용 후:
- 고위험 영역 집중 테스트
- 자원을 효율적으로 배분
- 중요 결함 발견 확률 ↑

예시:
Before: 20개 기능 × 10 TC = 200 TC (균등)
After:  
  - 고위험 3개 × 40 TC = 120 TC (깊이)
  - 중위험 5개 × 12 TC =  60 TC
  - 저위험 12개 × 2 TC =  24 TC
  총 204 TC (리스크 기반)

실무 종합 예시

프로젝트: 의료 진단 시스템

리스크 분석 결과:
┌────────────────────┬──────┬──────┬──────┐
│ 기능               │ 리스크│ 노력 │ 기법 │
├────────────────────┼──────┼──────┼──────┤
│ 진단 알고리즘      │  VH  │ 60MD │ 전부 │
│ 환자 데이터 관리   │  H   │ 40MD │ 전부 │
│ 의사 대시보드      │  M   │ 20MD │ 주요 │
│ 통계 리포트        │  L   │  5MD │ 기본 │
└────────────────────┴──────┴──────┴──────┘

진단 알고리즘 (매우 높음):
├─ 테스트 레벨: 모든 레벨
├─ 테스트 유형:
│  ├─ 기능 (100%)
│  ├─ 정확도 검증
│  ├─ 경계 조건
│  └─ 오진 시나리오
├─ 테스트 기법:
│  ├─ 동등 분할
│  ├─ 경계값
│  ├─ 결정 테이블
│  └─ 유스케이스
├─ 커버리지: 100%
├─ 추가 활동:
│  ├─ 전문가 리뷰
│  ├─ FDA 검증
│  └─ 임상 시험
└─ 노력: 60MD (전체의 48%)

통계 리포트 (낮음):
├─ 테스트 레벨: 시스템만
├─ 테스트 유형: 기능 (기본)
├─ 테스트 기법: 동등 분할
├─ 커버리지: 60%
└─ 노력: 5MD (전체의 4%)

결과:
✅ 생명에 영향 주는 기능 집중
✅ 자원 효율적 배분
✅ 규제 요구사항 충족

계속 진행하겠습니다!

FL-5.2.4 (K2) 분석한 제품 리스크에 대응해 어떤 조치를 취할 수 있는지 설명할 수 있다 (상세: 5.2.4절)

답변:

제품 리스크 제어 (Product Risk Control)

정의: 식별 및 평가된 제품 리스크에 대응해 취하는 모든 조치

구성:

리스크 완화 (Risk Mitigation): 리스크 수준을 낮추는 활동
리스크 모니터링 (Risk Monitoring): 완화 조치의 효과 확인 및 새 리스크 식별

리스크 대응 전략 (4가지)

1. 테스팅을 통한 리스크 완화 (Risk Mitigation through Testing)

가장 일반적인 방법

2. 리스크 수용 (Risk Acceptance)

리스크를 인지하고 받아들임

3. 리스크 전가 (Risk Transfer)

리스크를 다른 주체에게 이전

4. 대안 계획 (Contingency Plan)

리스크 발현 시 대응 계획

1. 테스팅을 통한 리스크 완화

A. 적절한 테스터 선정

원칙: 리스크 유형에 맞는 경험과 기술을 가진 테스터 배치

예시:

리스크: 보안 취약점 (SQL Injection, XSS)
→ 조치: 보안 전문 테스터 배정
   ├─ 자격: CEH, OSCP 보유
   ├─ 경험: 침투 테스트 5년 이상
   └─ 활동: 보안 테스트 전담

리스크: 성능 저하 (고부하 시 응답 느림)
→ 조치: 성능 테스트 전문가 배정
   ├─ 자격: 성능 테스트 도구 전문
   ├─ 경험: JMeter, LoadRunner 활용
   └─ 활동: 부하/스트레스 테스트

리스크: 복잡한 비즈니스 로직 오류
→ 조치: 도메인 전문가 참여
   ├─ 자격: 해당 업무 경험
   ├─ 경험: 비즈니스 프로세스 이해
   └─ 활동: 비즈니스 규칙 검증

B. 적절한 테스팅 독립성 적용

독립성 수준:

레벨 0 (독립성 없음):
- 작성자가 직접 테스트
- 예: 개발자 자가 테스트
- 적용: 저위험 컴포넌트

레벨 1 (동료):
- 같은 팀 동료가 테스트
- 예: 페어 테스팅
- 적용: 중위험 기능

레벨 2 (팀 내 테스터):
- 전담 테스터가 테스트
- 예: 개발팀 내 테스터
- 적용: 일반 기능

레벨 3 (독립 테스트 팀):
- 별도 테스트 조직
- 예: QA 부서
- 적용: 고위험 기능

레벨 4 (외부 조직):
- 제3자 테스트
- 예: 외부 보안 업체
- 적용: 매우 고위험 (보안, 규제)

예시:

프로젝트: 금융 거래 시스템

저위험 (로깅 기능):
└─ 레벨 0: 개발자 자가 테스트

중위험 (거래 내역 조회):
└─ 레벨 2: 팀 내 테스터

고위험 (거래 실행):
└─ 레벨 3: 독립 QA 팀

매우 고위험 (보안):
└─ 레벨 4: 외부 보안 감사

C. 리뷰 및 정적 분석 수행

정적 테스팅 활용

예시:

리스크: 복잡한 알고리즘 오류
→ 조치: 코드 리뷰 + 정적 분석
   ├─ 인스펙션: 알고리즘 로직 검증
   ├─ 워크쓰루: 작성자 설명
   ├─ 정적 분석 도구: SonarQube
   │  ├─ 복잡도 체크 (>10 경고)
   │  ├─ 코드 중복 탐지
   │  └─ 잠재적 버그 식별
   └─ 결과: 코딩 전 결함 제거

리스크: 요구사항 누락/오해
→ 조치: 요구사항 리뷰
   ├─ 이해관계자 참여
   ├─ 체크리스트 사용
   ├─ 테스트 가능성 검증
   └─ 결과: 명확한 요구사항 확정

리스크: 보안 취약점
→ 조치: 보안 코드 리뷰 + 정적 분석
   ├─ OWASP 가이드라인 준수 확인
   ├─ 정적 보안 스캔 (SAST)
   ├─ 민감 데이터 처리 검증
   └─ SQL Injection 패턴 탐지

D. 적절한 테스트 기법 및 커버리지 적용

리스크별 테스트 기법

고위험:
├─ 동등 분할
├─ 경계값 분석
├─ 결정 테이블
├─ 상태 전이
├─ 유스케이스 테스팅
└─ 목표 커버리지: 95-100%

중위험:
├─ 동등 분할
├─ 경계값 분석
└─ 목표 커버리지: 80%

저위험:
├─ 동등 분할
└─ 목표 커버리지: 60%

예시:

리스크: 결제 금액 계산 오류 (고위험)
→ 조치:
   ├─ 동등 분할:
   │  - 유효 클래스: 1-1,000,000원
   │  - 무효 클래스: ≤0, >1,000,000원
   │
   ├─ 경계값 분석:
   │  - 0원, 1원, 1,000,000원, 1,000,001원
   │
   ├─ 결정 테이블:
   │  - 할인 조합 (쿠폰 + 포인트 + 멤버십)
   │
   └─ 코드 커버리지:
      - 구문 커버리지: 100%
      - 분기 커버리지: 95%

E. 적절한 테스트 유형 적용

품질 특성별 테스트 유형

리스크 → 테스트 유형 매핑:

기능 정확성 리스크:
└─ 기능 테스트 (모든 시나리오)

성능 리스크:
├─ 성능 테스트 (응답시간)
├─ 부하 테스트 (처리량)
├─ 스트레스 테스트 (한계)
└─ 안정성 테스트 (장시간)

보안 리스크:
├─ 보안 기능 테스트
├─ 침투 테스트
├─ 취약점 스캔
└─ 암호화 검증

사용성 리스크:
├─ 사용성 테스트
├─ 접근성 테스트
└─ 사용자 경험 테스트

호환성 리스크:
├─ 브라우저 호환성
├─ OS 호환성
├─ 디바이스 호환성
└─ 통합 호환성

신뢰성 리스크:
├─ 안정성 테스트
├─ 복구 테스트
└─ 장애 허용 테스트

예시:

리스크: 모바일 앱 크래시 (고위험)
→ 조치:
   ├─ 안정성 테스트 (24시간 실행)
   ├─ 스트레스 테스트 (메모리 부족 상황)
   ├─ 호환성 테스트 (다양한 디바이스)
   ├─ 복구 테스트 (앱 재시작)
   └─ 몽키 테스트 (무작위 입력)

F. 리그레션 테스팅 수행

동적 테스팅의 핵심

리스크: 기존 기능 손상 (회귀 결함)
→ 조치:
   ├─ 리그레션 테스트 스위트 구축
   │  ├─ 고위험 기능 TC
   │  ├─ 자주 사용되는 기능 TC
   │  └─ 과거 결함 재현 TC
   │
   ├─ 자동화
   │  ├─ CI/CD 통합
   │  ├─ 매 커밋마다 실행
   │  └─ Nightly 전체 실행
   │
   └─ 영향도 분석
      ├─ 변경 범위 파악
      ├─ 관련 TC 선택
      └─ 우선순위 기반 실행

예시:

변경: 결제 API 버전 업그레이드

리그레션 테스트 계획:
┌─────────────────────────────┐
│ 1. 직접 영향 (필수)         │
│    - 결제 처리 (50 TC)      │
│    - 결제 취소 (20 TC)      │
│    - 환불 처리 (15 TC)      │
│                             │
│ 2. 간접 영향 (중요)         │
│    - 주문 완료 (30 TC)      │
│    - 포인트 적립 (10 TC)    │
│                             │
│ 3. 일반 기능 (샘플)         │
│    - 로그인 (5 TC)          │
│    - 상품 조회 (5 TC)       │
│                             │
│ 총 135 TC (자동화 90%)      │
│ 실행 시간: 45분             │
└─────────────────────────────┘

2. 리스크 수용 (Risk Acceptance)

정의: 리스크를 인지하고 받아들임

적용 상황:

리스크 수준이 낮음
완화 비용이 리스크보다 큼
기술적으로 완화 불가능
비즈니스 결정으로 수용

예시:

리스크: 도움말 페이지 링크 깨짐
├─ 발생 가능성: 낮음 (1/5)
├─ 영향: 매우 낮음 (1/5)
├─ 리스크 수준: 1
└─ 결정: 수용
   ├─ 이유:
   │  ├─ 사용자에게 미치는 영향 미미
   │  ├─ 완화 비용 > 리스크 손실
   │  └─ 긴급 릴리스 일정
   ├─ 조치:
   │  ├─ 결함 보고서 작성
   │  ├─ 백로그에 등록
   │  ├─ 다음 릴리스에서 수정 계획
   │  └─ 알려진 이슈로 문서화
   └─ 모니터링:
      └─ 사용자 피드백 추적

문서화:

리스크 수용 문서:

리스크 ID: R-042
제목: 도움말 링크 깨짐
수준: 낮음 (1/25)
수용 사유:
- 핵심 기능 아님
- 사용자 우회 가능
- 수정 비용 2MD vs 리스크 손실 $100
승인자: 제품 오너 (김철수)
승인일: 2024-11-15
조건:
- 다음 릴리스(v2.1)에서 수정
- 사용자 불만 발생 시 재검토

3. 리스크 전가 (Risk Transfer)

정의: 리스크를 다른 주체에게 이전

방법:

A. 보험

리스크: 데이터 센터 화재로 시스템 전체 다운
└─ 조치: 사이버 보험 가입
   ├─ 보장 내용:
   │  ├─ 데이터 복구 비용
   │  ├─ 비즈니스 중단 손실
   │  └─ 법적 책임
   └─ 보험료: 연 $50,000

B. 외부 서비스 활용 (SaaS)

리스크: 결제 시스템 장애
└─ 조치: 외부 결제 서비스 사용
   ├─ 업체: Stripe, PayPal
   ├─ 장점:
   │  ├─ PCI-DSS 준수 책임 전가
   │  ├─ 보안 책임 전가
   │  ├─ 가용성 보장 (SLA 99.9%)
   │  └─ 유지보수 부담 없음
   └─ 비용: 거래액의 2.9% + $0.30

리스크: 대용량 파일 저장 관리
└─ 조치: 클라우드 스토리지 (AWS S3)
   ├─ 데이터 내구성 99.999999999%
   ├─ 백업/복구 책임 전가
   └─ 확장성 문제 해결

C. 계약 조항

리스크: 외주 개발사의 품질 문제
└─ 조치: 계약서에 명시
   ├─ 품질 기준 명확화
   │  ├─ 결함 밀도 < 2개/KLOC
   │  ├─ 코드 커버리지 > 80%
   │  └─ 성능 요구사항 충족
   ├─ 페널티 조항
   │  ├─ 품질 미달 시 비용 공제
   │  └─ 무상 수정 의무
   └─ 보증 기간
      └─ 인수 후 6개월 무상 지원

4. 대안 계획 (Contingency Plan)

정의: 리스크 발현 시 대응 계획

예시:

리스크: 주 데이터베이스 장애
└─ 대안 계획:
   ├─ 사전 준비:
   │  ├─ 백업 DB 서버 구축
   │  ├─ 자동 failover 설정
   │  └─ 복구 절차서 작성
   ├─ 감지:
   │  ├─ 헬스체크 (30초마다)
   │  ├─ 알림 (SMS, Email, Slack)
   │  └─ 자동 failover 트리거
   ├─ 대응:
   │  ├─ 5분 내 백업 DB로 전환
   │  ├─ 사용자 공지
   │  └─ 긴급 복구 팀 소집
   └─ 복구:
      ├─ 주 DB 문제 해결
      ├─ 데이터 동기화
      └─ 주 DB로 복귀

리스크: 핵심 개발자 이탈
└─ 대안 계획:
   ├─ 사전 준비:
   │  ├─ 지식 문서화
   │  ├─ 페어 프로그래밍
   │  └─ 코드 리뷰 의무화
   ├─ 대응:
   │  ├─ 백업 인력 투입
   │  ├─ 외부 컨설턴트 고용
   │  └─ 일정 재조정
   └─ 장기:
      └─ 신규 인력 채용

리스크: 제3자 API 서비스 중단
└─ 대안 계획:
   ├─ 백업 서비스 준비
   │  ├─ 대체 API 업체 계약
   │  └─ 전환 코드 준비
   ├─ 우아한 실패 (Graceful Degradation)
   │  ├─ 캐시된 데이터 사용
   │  ├─ 기본값 제공
   │  └─ 사용자 안내 메시지
   └─ 모니터링
      ├─ API 상태 체크
      └─ 자동 전환

리스크 모니터링 (Risk Monitoring)

목적:

완화 조치 효과 확인
추가 정보 수집
새로운 리스크 식별

활동:

1. 메트릭 추적:
   ├─ 결함 발견율
   ├─ 결함 심각도 분포
   ├─ 테스트 커버리지
   └─ 잔여 리스크 수준

2. 정기 리뷰:
   ├─ 주간 리스크 회의
   ├─ 스프린트 회고
   └─ 릴리스 후 분석

3. 트렌드 분석:
   ├─ 결함 증가 추세
   ├─ 특정 영역 문제 집중
   └─ 조기 경보 신호

4. 새 리스크 식별:
   ├─ 기술 변경
   ├─ 요구사항 변경
   └─ 팀 변경

예시:

주간 리스크 모니터링 보고:

Week 3 Status:
┌────────────────────┬────────┬──────────┐
│ 리스크             │ 초기   │ 현재     │
├────────────────────┼────────┼──────────┤
│ R1: 결제 오류      │ 높음   │ 중간 ↓   │
│    완화: 80 TC 통과│        │          │
│                    │        │          │
│ R2: 성능 저하      │ 중간   │ 낮음 ↓   │
│    완화: 부하 테스트│        │          │
│                    │        │          │
│ R3: 보안 취약점    │ 높음   │ 높음 →   │
│    ⚠️ 조치 필요    │        │          │
│                    │        │          │
│ R4: 신규 리스크!   │ -      │ 중간 ⚠️  │
│    제3자 API 변경  │        │          │
└────────────────────┴────────┴──────────┘

액션:
1. R3 보안: 침투 테스트 추가 배정
2. R4 신규: API 호환성 긴급 테스트
3. 전체: 다음 주 재평가

종합 예시: 은행 앱 프로젝트

리스크 제어 계획:

R1: 송금 오류 (리스크: 매우 높음)
└─ 완화 전략: 테스팅
   ├─ 테스터: 금융 도메인 전문가 배정
   ├─ 독립성: 레벨 3 (독립 QA팀)
   ├─ 정적: 송금 로직 코드 인스펙션
   ├─ 기법:
   │  ├─ 동등 분할
   │  ├─ 경계값 분석
   │  ├─ 결정 테이블
   │  └─ 상태 전이
   ├─ 테스트 유형:
   │  ├─ 기능 테스트 (100개 TC)
   │  ├─ 보안 테스트 (인증/권한)
   │  ├─ 성능 테스트 (대량 처리)
   │  └─ 복구 테스트
   ├─ 커버리지: 100%
   └─ 리그레션: 자동화 80 TC

R2: 데이터베이스 장애 (리스크: 높음)
└─ 복합 전략:
   ├─ 완화 (테스팅):
   │  ├─ 장애 시나리오 테스트
   │  ├─ 복구 테스트
   │  └─ 부하 테스트
   ├─ 전가:
   │  └─ AWS RDS 사용 (고가용성)
   └─ 대안 계획:
      ├─ 읽기 전용 레플리카
      ├─ 자동 failover
      └─ 백업 (매시간)

R3: UI 응답 느림 (리스크: 중간)
└─ 완화 전략:
   ├─ 성능 테스트
   ├─ 프론트엔드 최적화
   └─ 모니터링

R4: 도움말 오타 (리스크: 낮음)
└─ 수용:
   ├─ 다음 릴리스 수정
   └─ 백로그 등록

모니터링:
├─ 주간 리스크 리뷰
├─ 메트릭 대시보드
└─ 이슈 트래킹

이제 5.3 테스트 모니터링, 제어, 완료로 넘어가겠습니다!

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

FL-5.3.1 (K1) 테스팅에 사용하는 메트릭을 상기할 수 있다 (상세: 5.3.1절)

답변:

테스트 메트릭이란?

정의: 테스트 활동을 측정하고 평가하기 위해 수집하는 정량적 데이터

목적:

계획 대비 진행 상황 파악
테스트 대상의 품질 평가
테스트 활동의 효과 측정
테스트 제어 및 완료 활동 지원

테스트 메트릭 유형

1. 프로젝트 진행 상황 메트릭 (Project Progress Metrics)

작업 완료율:

완료율 = (완료된 작업 / 전체 작업) × 100%

예:
계획: 테스트 케이스 작성 200개
완료: 150개
완료율 = 150 / 200 × 100% = 75%

자원 사용률:

사용률 = (실제 투입 시간 / 계획 시간) × 100%

예:
계획: 테스터 3명 × 10일 = 30MD
실제: 25MD 투입
사용률 = 25 / 30 × 100% = 83%

테스트 노력 투입률:

투입률 = 실제 노력 / 계획 노력

예:
Week 1 계획: 40MD
Week 1 실제: 45MD
투입률 = 45 / 40 = 1.125 (12.5% 초과)
→ 일정 지연 위험 ⚠️

2. 테스트 진행 상황 메트릭 (Test Progress Metrics)

테스트 케이스 구현 진행률:

진행률 = (구현 완료 TC / 전체 TC) × 100%

예:
전체: 500 TC
완료: 375 TC
진행률 = 375 / 500 × 100% = 75%

테스트 환경 준비 진행률:

체크리스트:
☑ 서버 설치
☑ DB 구축
☑ 네트워크 설정
☐ 테스트 데이터 로드
☐ 도구 설치

진행률 = 3 / 5 × 100% = 60%

실행/미실행 테스트 케이스 수:

┌──────────┬───────┬──────┐
│ 상태     │ 개수  │ 비율 │
├──────────┼───────┼──────┤
│ 실행     │  450  │ 90%  │
│ 미실행   │   50  │ 10%  │
│ 합계     │  500  │100%  │
└──────────┴───────┴──────┘

합격/불합격 테스트 케이스 수:

실행 TC 450개 중:
- 합격 (Pass): 420개 (93%)
- 불합격 (Fail): 30개 (7%)

통과율 = 420 / 450 × 100% = 93%

테스트 실행 시간:

일일 실행 시간:
- 단위 테스트: 5분
- 통합 테스트: 30분
- 시스템 테스트: 2시간
- 리그레션: 3시간
총: 5시간 35분/일

3. 제품 품질 메트릭 (Product Quality Metrics)

가용성 (Availability):

가용성 = (가동 시간 / 전체 시간) × 100%

예:
한 달 (30일 = 720시간)
다운타임: 3시간
가용성 = (720-3) / 720 × 100% = 99.58%

목표: 99.9% (연간 8.76시간 다운)

응답 시간 (Response Time):

측정:
- 평균 응답 시간: 1.2초
- 중간값 (Median): 0.8초
- 95 백분위수: 2.5초
- 99 백분위수: 5초

목표: 평균 < 2초, 95% < 3초

평균 장애 시간 (MTBF - Mean Time Between Failures):

MTBF = 총 가동 시간 / 장애 발생 횟수

예:
720시간 동안 장애 6회
MTBF = 720 / 6 = 120시간

해석: 평균 120시간마다 장애 발생

4. 결함 메트릭 (Defect Metrics)

발견/수정한 결함의 수:

주별 결함 추이:
┌──────┬──────┬──────┬────────┐
│ 주차 │ 발견 │ 수정 │ 미해결 │
├──────┼──────┼──────┼────────┤
│  1   │  15  │   8  │   7    │
│  2   │  22  │  18  │  11    │
│  3   │  18  │  20  │   9    │
│  4   │  12  │  15  │   6    │
└──────┴──────┴──────┴────────┘

트렌드: 발견↓, 수정↑, 미해결↓ ✅

심각도/우선순위별 결함:

심각도 분포:
┌──────────┬───────┬──────┐
│ 심각도   │ 개수  │ 비율 │
├──────────┼───────┼──────┤
│ 치명적   │   2   │  3%  │
│ 높음     │  12   │ 18%  │
│ 중간     │  35   │ 53%  │
│ 낮음     │  17   │ 26%  │
│ 합계     │  66   │100%  │
└──────────┴───────┴──────┘

릴리스 기준:
- 치명적/높음: 0개 ✅

결함 밀도 (Defect Density):

결함 밀도 = 결함 수 / 코드 크기

예:
총 결함: 66개
코드 크기: 50 KLOC
결함 밀도 = 66 / 50 = 1.32 결함/KLOC

벤치마크:
- 우수: < 1.0
- 양호: 1.0 - 2.0
- 주의: > 2.0

결함 발견 비율:

결함 발견율 = 신규 결함 / 테스트 노력

예:
Week 3:
신규 결함: 18개
테스트 노력: 45MD
발견율 = 18 / 45 = 0.4 결함/MD

트렌드 분석:
Week 1: 0.6 결함/MD
Week 2: 0.5 결함/MD
Week 3: 0.4 결함/MD ↓
→ 결함 발견이 줄어듦 (안정화) ✅

결함 제거 효율 (DRE - Defect Removal Efficiency):

DRE = (개발 중 발견 / 전체 결함) × 100%

예:
개발 중 발견: 80개
릴리스 후 발견: 5개
전체: 85개
DRE = 80 / 85 × 100% = 94%

목표: > 95%

5. 리스크 메트릭 (Risk Metrics)

잔여 리스크 수준:

초기 리스크 평가:
- 고위험: 5개
- 중위험: 10개
- 저위험: 15개

완화 후 잔여 리스크:
- 고위험: 1개 (테스트 진행 중)
- 중위험: 3개 (부분 완화)
- 저위험: 10개 (수용)

잔여 리스크 점수:
= (1×높음) + (3×중간) + (10×낮음)
= 1×15 + 3×10 + 10×5
= 15 + 30 + 50 = 95점

초기: 225점
잔여: 95점
감소율: 58% ✅

6. 커버리지 메트릭 (Coverage Metrics)

요구사항 커버리지:

커버리지 = (테스트된 요구사항 / 전체) × 100%

예:
전체 요구사항: 150개
테스트 케이스 매핑: 142개
커버리지 = 142 / 150 × 100% = 95%

미커버 요구사항 8개 분석:
- 기술적 제약: 3개
- 낮은 우선순위: 5개

코드 커버리지:

구문 커버리지 = (실행된 구문 / 전체) × 100%

예:
전체 구문: 5,000줄
실행된 구문: 4,200줄
구문 커버리지 = 4,200 / 5,000 × 100% = 84%

분기 커버리지:
전체 분기: 800개
실행된 분기: 640개
분기 커버리지 = 640 / 800 × 100% = 80%

목표:
- 구문: > 80% ✅
- 분기: > 75% ✅

7. 비용 메트릭 (Cost Metrics)

테스팅 비용:

직접 비용:
- 인건비: 3명 × 2개월 × $5,000 = $30,000
- 도구 라이선스: $5,000
- 환경 구축: $3,000
- 교육: $2,000
소계: $40,000

간접 비용:
- 관리 오버헤드: $5,000
- 인프라: $3,000
소계: $8,000

총 테스팅 비용: $48,000

조직의 품질 비용 (CoQ - Cost of Quality):

예방 비용 (Prevention):
- 교육: $10,000
- 프로세스 개선: $15,000
소계: $25,000

평가 비용 (Appraisal):
- 테스팅: $48,000
- 리뷰: $12,000
소계: $60,000

내부 실패 비용 (Internal Failure):
- 재작업: $20,000
- 디버깅: $15,000
소계: $35,000

외부 실패 비용 (External Failure):
- 고객 지원: $5,000
- 패치 배포: $3,000
소계: $8,000

총 품질 비용: $128,000

품질 비용 비율:
- 예방: 20%
- 평가: 47%
- 내부 실패: 27%
- 외부 실패: 6%

목표: 예방↑, 외부 실패↓

메트릭 활용 예시

주간 테스트 대시보드 (Week 3):

┌───────────────────────────────────┐
│ 진행 상황                         │
├───────────────────────────────────┤
│ TC 구현: 375/500 (75%)            │
│ TC 실행: 450/500 (90%)            │
│ TC 통과: 420/450 (93%)            │
│ 환경 준비: 100% ✅                │
└───────────────────────────────────┘

┌───────────────────────────────────┐
│ 품질 지표                         │
├───────────────────────────────────┤
│ 요구사항 커버리지: 95% ✅          │
│ 코드 커버리지: 84% ✅              │
│ 평균 응답시간: 1.2초 ✅           │
│ 가용성: 99.8% ✅                  │
└───────────────────────────────────┘

┌───────────────────────────────────┐
│ 결함 현황                         │
├───────────────────────────────────┤
│ 신규 발견: 18개                   │
│ 미해결: 9개 (치명적 0, 높음 1)    │
│ 결함 밀도: 1.32/KLOC ✅           │
│ DRE: 94% ⚠️ (목표 95%)           │
└───────────────────────────────────┘

┌───────────────────────────────────┐
│ 리스크 & 비용                     │
├───────────────────────────────────┤
│ 잔여 고위험: 1개 (테스트 중)      │
│ 예산 사용: $38K/$48K (79%)        │
│ 일정: On track ✅                 │
└───────────────────────────────────┘

액션:
1. DRE 95% 달성 위해 탐색적 테스팅 추가
2. 고위험 리스크 테스트 완료 목표: 금요일
3. 미완료 TC 50개 다음 주 월요일까지 구현

계속 진행하겠습니다!

FL-5.3.2 (K2) 테스트 보고서의 목적, 내용, 대상을 요약할 수 있다 (상세: 5.3.2절)

답변:

테스트 보고의 정의

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

1. 테스트 진행 상황 보고서 (Test Progress Report)

목적

- 지속적인 테스트 제어 지원
- 계획 이탈 시 조정 가능한 정보 제공
- 이해관계자에게 현재 상황 전달
- 의사결정 지원

작성 빈도

- 매일 (Daily Stand-up)
- 매주 (Weekly Report)
- 매 스프린트 (Sprint Review)
- 기타 주기 (프로젝트 특성에 따라)

내용

1) 테스팅 기간

보고 기간: 2024년 11월 11일 ~ 11월 15일 (Week 3)

2) 테스트 진행 상황

계획 대비:
- 예정보다 빠름 ✅
- 예정대로 진행 중 ✅
- 예정보다 늦음 ⚠️

주목할 만한 편차:
- TC 실행: 계획 400개 vs 실제 450개 (12% 초과)
- 일정: 계획 대비 1일 앞섬 ✅

3) 테스팅 진행 방해 요소와 대응

방해 요소:
1. 테스트 환경 불안정 (DB 다운 2회)
   → 대응: 백업 DB 사용, 모니터링 강화

2. 요구사항 변경 (결제 API 수정)
   → 대응: TC 20개 재작성, 일정 조정

3. 테스터 1명 병가
   → 대응: 나머지 팀원 업무 재분배

4) 테스트 메트릭

실행 현황:
- TC 구현: 500개 (100%)
- TC 실행: 450/500 (90%)
- TC 통과: 420/450 (93%)

결함 현황:
- 신규 발견: 18개
- 수정 완료: 15개
- 미해결: 9개 (치명적 0, 높음 1)

커버리지:
- 요구사항: 95%
- 코드 (구문): 84%

5) 신규 및 변경된 리스크

신규 리스크:
- R-NEW1: 제3자 API 응답 지연 (중간)
  → 조치: 타임아웃 처리 테스트 추가

변경된 리스크:
- R-001: 결제 오류 (높음 → 중간으로 감소)
  → 이유: 집중 테스트 80% 완료

6) 다음 주기 예정 테스팅

다음 주 (Week 4):
- 남은 TC 50개 실행
- 리그레션 테스트 (자동화)
- 탐색적 테스팅 (2일)
- 성능 테스트 (최종 검증)

보고서 예시

┌─────────────────────────────────────┐
│ 테스트 진행 상황 보고서             │
│ 프로젝트: 전자상거래 시스템 v2.0   │
│ 보고 기간: 2024.11.11 - 11.15      │
│ 작성자: 김테스터                    │
│ 작성일: 2024.11.15                 │
└─────────────────────────────────────┘

■ 요약
- 전체 진행률: 90% (계획: 85%) ✅
- 상태: 예정보다 1일 앞섬
- 주요 이슈: 테스트 환경 불안정 (해결)

■ 테스트 실행
┌──────────┬────────┬────────┬──────┐
│ 항목     │ 계획   │ 실제   │ 상태 │
├──────────┼────────┼────────┼──────┤
│ TC 실행  │  400   │  450   │  ✅  │
│ TC 통과  │  370   │  420   │  ✅  │
│ 통과율   │  92%   │  93%   │  ✅  │
└──────────┴────────┴────────┴──────┘

■ 결함 현황
신규 발견: 18개
수정 완료: 15개
미해결: 9개
  - 치명적: 0개 ✅
  - 높음: 1개 (DEF-089, 수정 중)
  - 중간: 5개
  - 낮음: 3개

■ 방해 요소 및 대응
1. DB 다운타임 (2회, 총 4시간)
   대응: 백업 DB로 전환, 원인 조사 완료
   
2. 요구사항 변경 (결제 API)
   대응: TC 20개 재작성, 2일 추가 소요

■ 리스크
- 고위험 1개 → 테스트 진행 중
- 신규 리스크: API 응답 지연 (중간)

■ 다음 주 계획
- 잔여 TC 50개 완료
- 리그레션 테스트 (자동화)
- 탐색적 테스팅
- 최종 성능 테스트

■ 권고사항
- 환경 모니터링 강화 필요
- 고위험 리스크 테스트 우선 완료

2. 테스트 완료 보고서 (Test Completion Report)

목적

- 특정 테스트 활동 요약
  (테스트 레벨, 주기, 반복 주기 완료 시)
- 후속 테스팅을 위한 정보 제공
- 프로젝트 종료 문서화
- 교훈 및 개선사항 공유

작성 시점

- 테스트 레벨 완료 시 (예: 시스템 테스트 종료)
- 테스트 주기 완료 시
- 반복 주기 완료 시 (스프린트 종료)
- 프로젝트 종료 시
- 완료 조건 충족 시

내용

1) 테스트 요약

프로젝트: 전자상거래 시스템 v2.0
테스트 레벨: 시스템 테스트
기간: 2024.10.21 - 2024.11.15 (4주)
팀: 테스터 3명, 자동화 엔지니어 1명

2) 테스트 계획 대비 평가

원래 테스트 목적:
✅ 기능 정확성 검증
✅ 성능 요구사항 충족 (응답시간 < 2초)
✅ 보안 취약점 0개
⚠️ 사용성 개선 (부분 달성)

완료 조건 충족 여부:
✅ 요구사항 커버리지 95% 이상
✅ 심각도 높음 결함 0개
✅ 코드 커버리지 80% 이상
⚠️ 성능 목표 95% 달성 (목표 100%)

3) 계획과의 편차

일정:
- 계획: 4주
- 실제: 4주
- 편차: 없음 ✅

공수:
- 계획: 120 MD
- 실제: 135 MD
- 편차: +15 MD (12.5% 초과)
- 원인: 요구사항 변경, 환경 이슈

비용:
- 계획: $48,000
- 실제: $52,500
- 편차: +$4,500 (9.4% 초과)

4) 테스팅 방해 요소와 대응

주요 이슈:
1. 테스트 환경 불안정 (총 10시간 다운)
   영향: 일정 2일 지연
   대응: 백업 환경 구축
   결과: 추가 비용 $3,000

2. 요구사항 변경 2회
   영향: TC 재작성 35개
   대응: 변경 관리 프로세스 강화
   
3. 제3자 API 문제
   영향: 통합 테스트 지연
   대응: Mock 서버 사용

5) 테스트 메트릭 (최종)

실행 메트릭:
- 총 TC: 500개
- 실행: 500개 (100%)
- 통과: 485개 (97%)
- 실패: 15개 (결함 수정 완료)

결함 메트릭:
- 총 발견: 87개
- 수정 완료: 82개
- 수정 예정: 5개 (낮은 우선순위)
- 결함 밀도: 1.74/KLOC
- DRE: 94.5%

커버리지:
- 요구사항: 96%
- 코드 구문: 84%
- 코드 분기: 78%

품질 메트릭:
- 평균 응답시간: 1.3초 ✅
- 가용성: 99.8% ✅
- 동시 사용자: 1200명 처리 ✅

6) 미완화 리스크, 미수정 결함

미완화 리스크:
- R-042: 모바일 브라우저 호환성 (중간)
  이유: 시간 부족
  계획: v2.1에서 해결
  회피책: 지원 브라우저 명시

미수정 결함:
- DEF-145: 도움말 링크 깨짐 (낮음)
- DEF-167: 검색 결과 정렬 오류 (낮음)
- DEF-201: 위시리스트 아이콘 정렬 (낮음)
- DEF-223: 알림 설정 UI 개선 (낮음)
- DEF-245: 푸터 정보 업데이트 필요 (낮음)

영향 평가: 비즈니스 영향 미미
계획: 다음 마이너 릴리스에서 수정

7) 테스팅 관련 교훈

잘된 점:
✅ 리스크 기반 테스팅으로 고위험 조기 발견
✅ 자동화 투자로 리그레션 효율 향상
✅ 3 Amigos 세션으로 요구사항 명확화

개선 필요:
⚠️ 테스트 환경 안정성 개선 필요
⚠️ 변경 관리 프로세스 강화
⚠️ 성능 테스트 조기 시작 필요

권고사항:
1. 다음 프로젝트에서 전용 환경 사전 구축
2. 자동화 커버리지 90%로 확대
3. 성능 테스트를 개발 초기부터 통합

보고서 예시 (ISO/IEC/IEEE 29119-3 양식 기반)

┌─────────────────────────────────────┐
│ 테스트 완료 보고서                  │
│ 프로젝트: 전자상거래 시스템 v2.0   │
│ 테스트 레벨: 시스템 테스트          │
│ 기간: 2024.10.21 - 2024.11.15      │
│ 작성자: 테스트 매니저 김철수        │
│ 승인자: 프로젝트 매니저 이영희      │
│ 작성일: 2024.11.16                 │
└─────────────────────────────────────┘

■ 요약
시스템 테스트가 계획된 4주 일정 내 완료되었습니다.
총 500개 테스트 케이스를 실행하여 97% 통과율을 달성했습니다.
모든 치명적 및 높은 심각도 결함이 수정되었으며,
주요 품질 목표를 충족했습니다.

■ 테스트 목적 달성 여부
┌────────────────────────┬──────┬────────┐
│ 목적                   │ 목표 │ 달성   │
├────────────────────────┼──────┼────────┤
│ 기능 정확성            │ 100% │  100%  │
│ 요구사항 커버리지      │  95% │   96%  │
│ 평균 응답시간          │  <2s │  1.3s  │
│ 동시 사용자 처리       │ 1000 │  1200  │
│ 심각도 높음 결함       │    0 │     0  │
│ 코드 커버리지          │  80% │   84%  │
└────────────────────────┴──────┴────────┘

평가: 모든 주요 목표 달성 ✅

■ 계획 vs 실제
┌──────────┬──────────┬──────────┬────────┐
│ 항목     │ 계획     │ 실제     │ 편차   │
├──────────┼──────────┼──────────┼────────┤
│ 기간     │ 4주      │ 4주      │  0%    │
│ 공수     │ 120 MD   │ 135 MD   │ +12.5% │
│ 비용     │ $48,000  │ $52,500  │ +9.4%  │
│ TC 수    │ 500개    │ 500개    │  0%    │
└──────────┴──────────┴──────────┴────────┘

편차 원인:
- 요구사항 변경 2회 (추가 15 MD)
- 환경 이슈 대응 (추가 비용 $3,000)

■ 최종 메트릭

테스트 실행:
- 총 TC: 500개
- 실행 완료: 500개 (100%)
- 통과: 485개 (97%)
- 자동화율: 75%

결함:
- 총 발견: 87개
- 수정 완료: 82개 (94%)
- 미수정: 5개 (모두 낮은 우선순위)
- 결함 밀도: 1.74/KLOC
- DRE: 94.5%

심각도별 결함:
- 치명적: 2개 (수정 완료)
- 높음: 18개 (수정 완료)
- 중간: 42개 (수정 완료)
- 낮음: 25개 (5개 미수정)

커버리지:
- 요구사항: 96% (144/150)
- 코드 구문: 84%
- 코드 분기: 78%

■ 미수정 결함 (5개)
모두 낮은 우선순위, v2.1에서 수정 예정
- DEF-145: 도움말 링크
- DEF-167: 검색 정렬
- DEF-201: 아이콘 정렬
- DEF-223: UI 개선
- DEF-245: 푸터 정보

영향: 핵심 기능에 영향 없음
릴리스 승인: 가능 ✅

■ 교훈 및 권고사항

성공 요인:
1. 리스크 기반 접근으로 고위험 조기 발견
2. 자동화 투자 (리그레션 3시간 → 30분)
3. 개발팀과 긴밀한 협업

개선 영역:
1. 테스트 환경 안정성 (10시간 다운타임)
2. 성능 테스트 조기 시작 필요
3. 변경 관리 프로세스 강화

다음 프로젝트 권고:
1. 전용 테스트 환경 사전 구축
2. 자동화 커버리지 90% 목표
3. 성능 테스트 스프린트 1부터 시작
4. 환경 모니터링 도구 도입

■ 결론
시스템 테스트가 성공적으로 완료되었으며,
제품이 릴리스 기준을 충족합니다.
미수정 결함 5개는 비즈니스 영향이 미미하며
다음 릴리스에서 해결 예정입니다.

릴리스 권고: Go ✅

승인:
테스트 매니저: 김철수 (서명)
프로젝트 매니저: 이영희 (서명)
날짜: 2024.11.16

3. 보고 대상별 맞춤화

같은 팀 구성원

형식: 비공식, 간결
빈도: 매일 (Stand-up)
내용:
- 어제 한 일
- 오늘 할 일
- 방해 요소

예:
"어제 결제 TC 30개 실행, 2개 결함 발견.
오늘 나머지 20개 실행 예정.
환경이 느려서 시간이 더 걸림."

테스트 리더/매니저

형식: 구조화된 이메일/문서
빈도: 주간
내용:
- 진행 상황 (%)
- 메트릭
- 이슈 및 리스크
- 조치 필요 사항

예: 주간 진행 보고서

프로젝트 매니저

형식: 요약 대시보드
빈도: 주간 또는 마일스톤
내용:
- 전체 진행률
- Red/Yellow/Green 상태
- 일정/비용 편차
- 릴리스 가능 여부

예:
"진행률 90%, 일정 준수, 릴리스 준비 OK"

경영진

형식: 고급 요약 (Executive Summary)
빈도: 마일스톤 또는 월간
내용:
- 핵심 메시지 (1-2문장)
- 주요 리스크
- 비즈니스 영향
- 의사결정 필요 사항

예:
"시스템 테스트 완료. 모든 기준 충족.
11월 20일 릴리스 가능."

고객/외부 이해관계자

형식: 공식 보고서 (템플릿 기반)
빈도: 계약 조건에 따라
내용:
- 계약 기준 충족 여부
- 품질 보증
- 알려진 이슈
- 인수 준비 상태

예: 테스트 완료 보고서 (공식)

보고서 비교 요약

구분	진행 상황 보고서	완료 보고서
시점	테스팅 중 (정기적)	테스팅 완료 후 (1회)
목적	진행 상황 공유, 제어	최종 요약, 교훈
빈도	매일/매주	1회
형식	간결, 현재 중심	상세, 전체 회고
내용	현재~다음 주기	전체 기간 요약
대상	팀, 관리자	모든 이해관계자
조치	즉각 대응 필요	향후 개선 참고

계속 진행하겠습니다!

FL-5.3.3 (K2) 테스팅 상황을 전달하는 방법을 예를 들어 설명할 수 있다 (상세: 5.3.3절)

답변:

테스팅 상황 전달 방법

결정 요소:

테스트 관리자의 관심사
조직의 테스트 전략
규제 표준
자율 조직 팀의 특성

1. 대화 (Verbal Communication)

팀원 및 기타 이해관계자와의 대화

형태:

A. 일대일 대화

장소: 책상 옆, 복도, 휴게실
시간: 즉시, 비공식
내용: 빠른 업데이트, 즉각적인 피드백

예시:
테스터 → 개발자:
"방금 로그인 기능 테스트했는데, 
비밀번호 5번 틀렸을 때 계정 잠금이 
안 되네요. 확인 부탁드려요."

개발자 → 테스터:
"아, 그 기능은 다음 빌드에 포함될 
예정이에요. 내일 오전에 배포됩니다."

B. 팀 미팅

데일리 스탠드업 (Daily Stand-up):

형식: 15분 이내, 모든 팀원 참석
시간: 매일 같은 시간 (예: 오전 10시)

각자 공유:
1. 어제 한 일
2. 오늘 할 일  
3. 방해 요소 (Blockers)

예시:
테스터 김철수:
"어제: 결제 모듈 TC 30개 실행, 2개 결함 발견
오늘: 남은 20개 TC 실행 예정
방해: 테스트 환경이 느려서 시간 지연"

스크럼 마스터:
"환경 이슈는 DevOps 팀에 에스컬레이션 
하겠습니다. 오늘 오후에 해결 예정."

스프린트 리뷰 (Sprint Review):

형식: 1-2시간, 이해관계자 참석
빈도: 스프린트 종료 시 (2주마다)

내용:
- 완료된 작업 데모
- 테스트 결과 공유
- 품질 상태 보고
- 피드백 수집

예시:
테스트 리더:
"이번 스프린트에서 결제 기능 
테스트를 완료했습니다.
- 50개 TC 모두 통과
- 결함 3개 발견 및 수정 완료
- 성능 목표 달성 (응답시간 1.2초)
데모를 보여드리겠습니다."

(실제 결제 플로우 시연)

회고 (Retrospective):

형식: 1시간, 팀만 참석
빈도: 스프린트 종료 시

내용:
- 잘된 점
- 개선할 점
- 액션 아이템

예시:
테스터:
"잘된 점: 자동화로 리그레션 시간 
50% 단축
개선: 테스트 데이터 준비에 시간 
많이 소요. 다음 스프린트에서는 
데이터 생성 스크립트 만들자."

2. 대시보드 (Dashboards)

시각적, 실시간 정보 제공

A. CI/CD 대시보드

┌─────────────────────────────────────┐
│ Jenkins CI Dashboard                │
├─────────────────────────────────────┤
│ Build #234                          │
│ Status: ✅ Success                  │
│ Duration: 8m 32s                    │
│                                     │
│ Unit Tests:       1,250 ✅          │
│ Integration:        120 ✅          │
│ Code Coverage:      84% ✅          │
│                                     │
│ Last Failed: Build #231 (2일 전)    │
│ Success Rate: 98.5%                 │
└─────────────────────────────────────┘

특징:
- 실시간 업데이트
- 빌드 상태 즉시 확인
- 트렌드 그래프
- 알림 연동 (Slack, Email)

B. 태스크 보드 (Task Board)

Jira Board:

┌────────────┬────────────┬────────────┬──────────┐
│ To Do      │ In Progress│ Testing    │   Done   │
├────────────┼────────────┼────────────┼──────────┤
│            │            │            │          │
│ [TC-101]   │ [TC-089]   │ [TC-045]   │ [TC-001] │
│ 상품 검색  │ 결제 처리  │ 로그인     │ 회원가입 │
│            │            │            │          │
│ [TC-102]   │ [TC-090]   │ [TC-046]   │ [TC-002] │
│ 장바구니   │ 주문 확인  │ 비밀번호   │ 로그아웃 │
│            │            │ 재설정     │          │
│            │            │            │ [TC-003] │
│ (15개)     │ (8개)      │ (12개)     │ (65개)   │
└────────────┴────────────┴────────────┴──────────┘

특징:
- 칸반 스타일 시각화
- 드래그 앤 드롭
- 병목 지점 즉시 파악
- 팀 전체 진행 상황 공유

C. 번다운 차트 (Burndown Chart)

스프린트 번다운:

남은 작업 (TC)
100 │╲
    │ ╲
 75 │  ╲____
    │      ╲___
 50 │         ╲___
    │            ╲___
 25 │               ╲___ 이상적
    │                  ╲___
  0 │___________________╲___▼ 실제
    └─────────────────────────→
    1  3  5  7  9  11  13 일

해석:
- 이상적 진행보다 약간 느림
- Day 7-9 정체 (환경 이슈)
- Day 10 이후 회복
- 완료 예상: Day 14 (계획 Day 13)

D. 품질 대시보드

┌─────────────────────────────────────┐
│ Quality Metrics Dashboard           │
├─────────────────────────────────────┤
│ 🎯 커버리지                         │
│   요구사항:  [████████░░] 95%       │
│   코드:      [████████░░] 84%       │
│                                     │
│ 🐛 결함 현황                        │
│   미해결: 9개                       │
│   ├─ 치명적: 0 ✅                   │
│   ├─ 높음:   1 ⚠️                  │
│   ├─ 중간:   5                      │
│   └─ 낮음:   3                      │
│                                     │
│ 📊 트렌드 (지난 4주)                │
│   결함 발견율: ↓ 감소 (안정화)      │
│   테스트 통과율: ↑ 증가 (93%)       │
│   DRE: 94.5% (목표 95%)             │
│                                     │
│ ⚡ 성능                              │
│   평균 응답: 1.3s ✅ (목표 <2s)     │
│   가용성: 99.8% ✅                  │
└─────────────────────────────────────┘

특징:
- 한눈에 품질 상태 파악
- 색상 코드 (Red/Yellow/Green)
- 자동 업데이트
- 드릴다운 가능

3. 전자 통신 채널 (Electronic Communication)

A. 이메일

제목: [주간 테스트 보고] Week 3 진행 상황

수신: 프로젝트팀, 관리자
발신: 테스트 리더 김철수
날짜: 2024.11.15

안녕하세요,

Week 3 테스트 진행 상황을 공유드립니다.

■ 요약
- 진행률: 90% (계획 85%) ✅
- 상태: 예정보다 1일 앞섬
- 주요 이슈: 없음

■ 주요 메트릭
- TC 실행: 450/500 (90%)
- 통과율: 93%
- 미해결 결함: 9개 (치명적 0개)

■ 다음 주 계획
- 잔여 TC 50개 완료
- 리그레션 테스트
- 탐색적 테스팅

상세 내용은 첨부 파일 참조 부탁드립니다.

감사합니다.
김철수

B. 채팅 (Slack, Teams)

#project-ecommerce 채널

김테스터 [10:23 AM]
@channel 결제 모듈 테스트 완료했습니다! 🎉
- 80 TC 모두 통과 ✅
- 성능도 목표 달성 (평균 0.9초)
- 다음은 주문 모듈 시작합니다.

이개발 [10:25 AM]
👍 수고하셨습니다!

박매니저 [10:27 AM]
Great! 일정 준수 중이네요 👏

김테스터 [2:45 PM]
⚠️ 긴급: 테스트 환경 다운되었습니다.
@DevOps 확인 부탁드립니다.

최데브옵스 [2:47 PM]
확인 중입니다. 10분 내 복구 예상.

최데브옵스 [2:55 PM]
✅ 복구 완료. DB 재시작 이슈였습니다.

장점:

즉각적인 소통
비공식적
팀 전체 투명성
검색 가능
통합 (Jira, GitHub 알림)

4. 온라인 문서 (Online Documentation)

A. Confluence 위키

페이지: "프로젝트 상태"

# 전자상거래 v2.0 프로젝트

## 현재 상태
🟢 전체: On Track
🟢 개발: 95% 완료
🟡 테스팅: 90% 완료 (약간 지연)

## 이번 주 하이라이트
- ✅ 결제 모듈 테스트 완료
- ✅ 성능 목표 달성
- ⚠️ 환경 이슈 2회 (해결)

## 다음 주 계획
- 리그레션 테스트
- UAT 준비

## 상세 보고서
- [주간 테스트 보고서](링크)
- [결함 현황](링크)
- [메트릭 대시보드](링크)

최종 업데이트: 2024.11.15 by 김철수

B. Google Docs / SharePoint

실시간 협업 문서:

"테스트 계획 및 진행 상황"

팀원들이 동시에 편집 가능:
- 테스터 A: TC 실행 상태 업데이트
- 테스터 B: 결함 로그 추가
- 테스트 리더: 주간 요약 작성

댓글 기능으로 토론:
박매니저: "이 결함은 긴급한가요?"
김테스터: "아니요, 낮은 우선순위입니다."

5. 공식 테스트 보고서 (Formal Test Reports)

상황: 규제 산업, 계약 요구사항, 경영진 보고

ISO/IEC/IEEE 29119-3 표준 양식:

┌─────────────────────────────────────┐
│ 테스트 완료 보고서                  │
│ (공식, 승인 필요)                   │
└─────────────────────────────────────┘

작성자: 테스트 매니저
검토자: 프로젝트 매니저, QA 디렉터
승인자: CTO

양식:
- 표지
- 목차
- 요약 (Executive Summary)
- 테스트 범위 및 목적
- 테스트 접근법
- 테스트 결과
- 결함 요약
- 리스크 평가
- 권고사항
- 부록 (상세 데이터)

배포:
- 경영진
- 프로젝트 이해관계자
- 규제 기관 (필요시)
- 아카이브

상황별 최적 방법

1. 물리적으로 같은 장소 (Co-located Team)

우선순위:
1. 대화 (즉각적, 효과적)
2. 태스크 보드 (벽면 물리적 보드 또는 모니터)
3. 데일리 스탠드업
4. 간단한 채팅/이메일

예:
애자일 팀실:
- 벽면에 큰 태스크 보드
- 번다운 차트 게시
- 매일 오전 10시 스탠드업
- 필요 시 즉시 대화

2. 분산된 팀 (Distributed Team)

우선순위:
1. 온라인 대시보드 (Jira, Confluence)
2. 화상 회의 (Zoom, Teams)
3. 채팅 (Slack, Teams)
4. 이메일 (공식 기록)
5. 공유 문서

시차 고려:
- 비동기 소통 중시
- 문서화 강화
- 정기 화상 회의 (모두가 가능한 시간)

예:
한국-미국 분산 팀:
- Jira로 진행 상황 공유
- Slack으로 일상 소통
- 주 2회 화상 회의 (한국 저녁 = 미국 아침)
- Confluence에 모든 것 문서화

3. 규제 산업 (의료, 금융, 항공)

우선순위:
1. 공식 보고서 (필수, 감사 추적)
2. 승인된 도구 (검증된 시스템)
3. 문서 버전 관리
4. 전자 서명

내부 팀:
- 대화, 채팅 (비공식)
- 대시보드 (진행 상황)

외부/감사:
- 공식 보고서
- 증적 자료

예:
의료기기 소프트웨어:
- 내부: Jira, Slack
- FDA 제출: 정식 테스트 보고서 + 증적

4. 애자일 vs 전통적

애자일:
├─ 대화 우선
├─ 시각적 도구 (보드, 차트)
├─ 일일 스탠드업
├─ 스프린트 리뷰/회고
└─ 간결한 문서

전통적 (Waterfall):
├─ 공식 보고서
├─ 주간/월간 회의
├─ 상세한 문서
├─ 승인 프로세스
└─ 이메일 중심

종합 예시: 하이브리드 접근

프로젝트: 은행 앱 (분산 팀 + 규제 산업)

일일 (Daily):
└─ Slack: 빠른 업데이트, 이슈 공유
   "환경 다운, 복구 중"

주간 (Weekly):
├─ 화상 스탠드업 (월/수/금, 30분)
│  └─ 각자 진행 상황, 방해 요소
│
├─ Jira 대시보드 업데이트
│  └─ 모든 TC 상태 실시간 반영
│
└─ 주간 보고 이메일 (금요일)
   └─ 경영진, PM에게 요약

스프린트 (2주):
├─ 스프린트 리뷰 (화상)
│  └─ 데모, 결과 공유
│
└─ 회고
   └─ 개선 사항 논의

마일스톤:
├─ 공식 테스트 완료 보고서
│  └─ ISO/IEC/IEEE 29119-3 표준
│
└─ 경영진 프레젠테이션
   └─ 릴리스 승인

규제 감사:
└─ 증적 패키지 (모든 공식 문서)
   ├─ 테스트 계획서
   ├─ 테스트 케이스
   ├─ 실행 로그
   ├─ 결함 보고서
   └─ 완료 보고서

효과적인 의사소통 원칙

1. 대상 맞춤화:
   - 개발자: 기술적 상세
   - 관리자: 진행률, 일정
   - 경영진: 요약, 리스크

2. 적시성:
   - 긴급: 즉시 (채팅, 전화)
   - 일상: 일일/주간
   - 공식: 마일스톤

3. 명확성:
   - 사실 기반
   - 액션 아이템 명확
   - 다음 단계 제시

4. 일관성:
   - 정기적 업데이트
   - 동일 양식/채널
   - 예측 가능한 주기

5. 투명성:
   - 좋은 소식과 나쁜 소식 모두
   - 문제 조기 공유
   - 팀 전체 접근 가능

이제 5.4 형상 관리로 넘어가겠습니다!

5.4 형상 관리

FL-5.4.1 (K2) 형상 관리가 테스팅을 어떻게 지원하는지 요약할 수 있다 (상세: 5.4절)

답변:

형상 관리 (Configuration Management, CM)란?

정의: 테스팅 작업 산출물을 형상 항목으로 식별, 제어, 추적하는 지침

형상 항목 (Configuration Item):

테스트 계획서
테스트 전략서
테스트 컨디션
테스트 케이스
테스트 스크립트
테스트 결과
테스트 로그
테스트 보고서

형상 관리의 핵심 활동

1. 식별 (Identification)

고유 식별자 부여

테스트 케이스:
TC-2024-PAY-001
 │    │    │   │
 │    │    │   └─ 순번
 │    │    └───── 모듈 (결제)
 │    └────────── 연도
 └─────────────── 유형 (TC)

버전 관리:
TC-2024-PAY-001 v1.0
TC-2024-PAY-001 v1.1
TC-2024-PAY-001 v2.0

예시:
TC-2024-PAY-001 v1.0 (초기 작성)
├─ 작성자: 김테스터
├─ 작성일: 2024-10-15
└─ 상태: 승인됨

TC-2024-PAY-001 v1.1 (수정)
├─ 수정자: 박테스터
├─ 수정일: 2024-11-05
├─ 변경 사유: 결제 API 변경 반영
└─ 상태: 검토 중

2. 제어 (Control)

베이스라인 (Baseline)

정의: 승인된 형상 항목의 스냅샷

베이스라인 생성:
1. 테스트 케이스 작성
2. 리뷰 및 승인
3. 베이스라인 설정 ✅
4. 이후 변경은 공식 프로세스 필요

예시:
┌──────────────────────────────────┐
│ Baseline: Release v2.0 Test Suite│
│ 생성일: 2024-11-01               │
│ 승인자: 테스트 매니저            │
├──────────────────────────────────┤
│ 포함 항목:                       │
│ - 테스트 계획서 v1.0             │
│ - TC 500개 (v1.0)                │
│ - 자동화 스크립트 (commit #a3b2)│
│ - 테스트 데이터 세트 v1.0        │
└──────────────────────────────────┘

변경 제어:
베이스라인 이후 변경 시:
1. 변경 요청서 (CR) 작성
2. 영향도 분석
3. 승인자 검토
4. 승인 후 변경
5. 새 버전 생성
6. 변경 이력 기록

변경 제어 프로세스

변경 요청:
┌─────────────────────────────────┐
│ Change Request #CR-2024-089     │
├─────────────────────────────────┤
│ 대상: TC-2024-PAY-001           │
│ 현재 버전: v1.0                 │
│ 요청자: 박개발                  │
│ 요청일: 2024-11-10              │
│                                 │
│ 변경 사유:                      │
│ 결제 API 엔드포인트 변경        │
│ (POST /api/v1/pay → v2/payment) │
│                                 │
│ 영향도:                         │
│ - TC-2024-PAY-001~005 수정 필요 │
│ - 자동화 스크립트 업데이트      │
│                                 │
│ 승인: 테스트 매니저 (김철수)    │
│ 승인일: 2024-11-11              │
└─────────────────────────────────┘

변경 실행:
1. 테스트 케이스 업데이트
2. 버전 → v1.1
3. Git commit & push
4. 변경 이력 업데이트
5. 관련자에게 통지

3. 추적 (Tracking)

변경사항 추적

테스트 케이스 이력:

TC-2024-PAY-001
├─ v1.0 (2024-10-15)
│  ├─ 초기 작성
│  └─ 승인: 김매니저
│
├─ v1.1 (2024-11-05)
│  ├─ API 엔드포인트 변경
│  ├─ 수정: 박테스터
│  └─ CR-2024-089
│
└─ v2.0 (2024-11-20)
   ├─ 테스트 데이터 추가
   ├─ 검증 단계 보강
   ├─ 수정: 김테스터
   └─ CR-2024-145

변경 조회:
$ git log TC-2024-PAY-001.md

commit a3b2c1d
Date: 2024-11-20
변경: v2.0 - 테스트 데이터 추가
CR: #145

commit f8e7d6c
Date: 2024-11-05
변경: v1.1 - API 변경 반영
CR: #089

commit 1234abc
Date: 2024-10-15
변경: v1.0 - 초기 작성

4. 추적성 유지 (Traceability)

테스트웨어와 테스트 베이시스 간 연결

추적성 매트릭스:

┌────────────┬──────────────┬──────────────┐
│ 요구사항   │ 테스트 케이스│ 결함         │
├────────────┼──────────────┼──────────────┤
│ REQ-001    │ TC-001       │ -            │
│ 로그인     │ TC-002       │ DEF-023      │
│            │ TC-003       │ -            │
│            │              │              │
│ REQ-002    │ TC-004       │ -            │
│ 결제       │ TC-005       │ DEF-045      │
│            │ TC-006       │ DEF-046      │
│            │ ...          │ -            │
│            │ TC-025       │ -            │
└────────────┴──────────────┴──────────────┘

양방향 추적:
REQ-002 (결제) →
  ├─ TC-004 (정상 결제)
  ├─ TC-005 (취소) → DEF-045
  ├─ TC-006 (환불) → DEF-046
  └─ ... TC-025

DEF-045 (결제 취소 오류) ←
  ├─ TC-005 (실패)
  └─ REQ-002 (결제)

형상 관리가 테스팅을 지원하는 방법

1. 모든 형상 항목에 고유 식별자 및 버전 관리

테스트 항목 (Test Item) 관리

테스트 대상 소프트웨어:

App v2.0.1 (Build #234)
├─ 빌드 일시: 2024-11-15 14:23
├─ Git Commit: a3b2c1d
├─ 변경사항: 결제 API 수정
└─ 테스트 환경: staging-01

테스트 실행 로그:
Test Run #TR-2024-1115-001
├─ 테스트 대상: App v2.0.1
├─ 테스트 스위트: Payment v1.1
├─ 실행자: 김테스터
├─ 실행 환경: staging-01
└─ 결과: 80 Pass, 2 Fail

이점:
✅ 정확히 어떤 버전을 테스트했는지 명확
✅ 결함 재현 가능
✅ 결과의 정확성 보장

2. 모든 항목 버전 관리 및 변경사항 추적

Git을 통한 버전 관리

테스트 저장소 구조:

test-automation/
├─ test-plans/
│  └─ test-plan-v2.0.md (v1.0, v1.1, ...)
├─ test-cases/
│  ├─ TC-001-login.md
│  ├─ TC-002-payment.md
│  └─ ...
├─ test-scripts/
│  ├─ login_test.py
│  └─ payment_test.py
├─ test-data/
│  └─ payment_testdata.csv
└─ test-results/
   └─ 2024-11-15/

Git 브랜치 전략:
main
├─ develop
├─ feature/payment-api-update
└─ release/v2.0

변경 추적:
$ git diff v1.0 v1.1 test-cases/TC-002-payment.md

- POST /api/v1/pay
+ POST /api/v2/payment

이점:
✅ 변경 이력 완전 보존
✅ 이전 버전으로 롤백 가능
✅ 누가, 언제, 왜 변경했는지 추적

3. 다른 형상 항목과의 연관성 식별

관계 관리

테스트 케이스와 의존성:

TC-2024-PAY-005 (결제 취소)
├─ 테스트 베이시스:
│  └─ REQ-002 (결제 요구사항 v1.2)
│
├─ 선행 조건:
│  ├─ TC-2024-PAY-001 (결제 실행) 통과
│  └─ 테스트 데이터: payment_data.csv v1.0
│
├─ 테스트 환경:
│  ├─ App: v2.0.1
│  ├─ DB: PostgreSQL 13.4
│  └─ Payment Gateway: Mock v1.5
│
└─ 관련 결함:
   └─ DEF-045 (결제 취소 오류)

이점:
✅ 영향도 분석 용이
✅ 의존성 파악
✅ 변경 시 연쇄 영향 확인

4. 테스트웨어 내에서 문서와 소프트웨어 항목 명확히 참조

명확한 참조

테스트 케이스 문서:

# TC-2024-PAY-005: 결제 취소

## 참조
- 요구사항: REQ-002 v1.2
- 테스트 계획: TP-2024-001 v1.0
- 선행 TC: TC-2024-PAY-001 v1.0
- 테스트 데이터: payment_data.csv v1.0
- API 명세: API-Spec-Payment v2.0

## 테스트 대상
- 애플리케이션: ecommerce-app v2.0.1
- 빌드: #234
- 엔드포인트: POST /api/v2/payment/cancel

## 절차
1. TC-2024-PAY-001 실행 (결제 완료 상태)
2. 결제 취소 API 호출
3. 결과 검증

## 테스트 데이터
- 파일: test-data/payment_data.csv
- Row: #5 (정상 결제 데이터)

이점:
✅ 정확한 참조로 혼선 방지
✅ 올바른 버전 사용 보장
✅ 테스트 재현성 향상

5. 복잡한 형상 항목 관리

테스트 환경 관리

테스트 환경 형상:

Environment: staging-01
├─ ID: ENV-STAGING-01
├─ 버전: v2.0.1-staging
├─ 구성 항목:
│  ├─ App Server:
│  │  ├─ OS: Ubuntu 22.04
│  │  ├─ App: ecommerce-app v2.0.1
│  │  └─ Java: OpenJDK 17
│  ├─ Database:
│  │  ├─ PostgreSQL: 13.4
│  │  ├─ Schema: v2.0.1
│  │  └─ 테스트 데이터: seed-data-v1.0.sql
│  ├─ 외부 서비스:
│  │  ├─ Payment Gateway: Mock v1.5
│  │  └─ Email Service: Mock v1.2
│  └─ 네트워크:
│     ├─ Load Balancer: Nginx 1.20
│     └─ SSL: Let's Encrypt
├─ 항목 간 관계:
│  └─ App ↔ DB ↔ Payment Gateway
└─ 변경 이력:
   ├─ 2024-11-01: 초기 구축
   ├─ 2024-11-10: DB 스키마 업데이트
   └─ 2024-11-15: App 버전 업그레이드

Infrastructure as Code (IaC):
```yaml
# staging-environment-config.yml v1.2
version: 2.0.1
app_version: 2.0.1
db_version: 13.4
db_schema: v2.0.1

이점:
✅ 복잡한 환경도 정확히 재현 가능
✅ 환경 설정 변경 추적
✅ 문제 발생 시 이전 설정으로 복구


---

### **6. 이전 베이스라인으로 복구 (재현성)**

**테스트 결과 재현**

시나리오: 2주 전 결함 재현 필요

형상 정보 확인:
┌─────────────────────────────┐
│ Test Run #TR-2024-1101-042 │
├─────────────────────────────┤
│ 일시: 2024-11-01 15:30 │
│ 결과: Fail (DEF-045) │
│ App: v2.0.0 (Build #210) │
│ TC: TC-2024-PAY-005 v1.0 │
│ 데이터: payment_data.csv v1.0│
│ 환경: staging-01 (snapshot-A)│
└─────────────────────────────┘
베이스라인 복구:
$ git checkout tags/v2.0.0-build-210
$ docker-compose up -f env-snapshot-A.yml
$ cp backup/payment_data_v1.0.csv ./
테스트 재실행:
$ pytest TC-2024-PAY-005_v1.0.py
결과:
✅ 동일한 결함 재현 성공
✅ 근본 원인 분석 가능

이점:
✅ 과거 상태 정확히 재현
✅ 결함 재현 가능
✅ 회귀 검증


---

### **CI/CD와 통합된 자동화된 형상 관리**

DevOps 파이프라인:

코드 커밋 (Git)
├─ 개발자: feature/payment-api
└─ 자동 트리거: Jenkins
CI 빌드
├─ Build #235
├─ Version: v2.0.2-dev
└─ Artifact 생성
자동 배포 (Staging)
├─ Environment: staging-01
├─ Config: staging-config v1.3
└─ DB Migration: v2.0.2
자동 테스트 실행
├─ Test Suite: Full Regression v1.1
├─ 실행 환경 기록
├─ 결과 저장: test-results/2024-11-16/
└─ Report 생성
형상 기록
├─ Git Tag: v2.0.2-build-235
├─ Docker Image: app:v2.0.2-build-235
├─ Test Result: archived
└─ Traceability: 자동 링크
통지
└─ Slack: "✅ Build #235 테스트 통과"

자동화 이점:
✅ 수동 오류 제거
✅ 완전한 추적성
✅ 빠른 피드백
✅ 재현성 보장


---

### **형상 관리 도구 예시**

버전 관리:

Git, GitLab, GitHub
SVN, Perforce

테스트 관리:

Jira, TestRail, qTest
Azure DevOps

CI/CD:

Jenkins, GitLab CI, GitHub Actions
TeamCity, Bamboo

환경 관리:

Docker, Kubernetes
Terraform, Ansible

통합:
모든 도구 연동으로 완전한 추적성


---

### **형상 관리의 핵심 이점 요약**

✅ 재현성 (Reproducibility)
→ 동일 조건에서 테스트 재실행 가능

✅ 추적성 (Traceability)
→ 요구사항 ↔ TC ↔ 결함 연결

✅ 제어 (Control)
→ 승인된 변경만 허용

✅ 일관성 (Consistency)
→ 모든 팀원이 올바른 버전 사용

✅ 감사 가능성 (Auditability)
→ 모든 변경 이력 보존

✅ 협업 지원 (Collaboration)
→ 분산 팀 효율적 작업

✅ 리스크 완화 (Risk Mitigation)
→ 문제 발생 시 빠른 복구


---

이제 5.5 결함 관리로 넘어가겠습니다!

---

## **5.5 결함 관리**

---

#### **FL-5.5.1 (K3) 결함 보고서를 작성할 수 있다 (상세: 5.5절)**

**답변:**

### **결함 관리 프로세스**

**정의:** 결함을 발견부터 종료까지 처리하는 작업 흐름과 분류 기준

**작업 흐름:**
1. 이상 사항 기록
2. 분석 및 분류
3. 대응책 결정 (수정/유지/거부)
4. 결함 보고 종료

---

### **결함 보고서의 목적**

문제 해결을 위한 충분한 정보 제공
→ 개발자가 결함 재현 및 수정 가능
작업 산출물 품질 추적 수단 제공
→ 메트릭, 트렌드 분석
프로세스 개선 아이디어 제공
→ 근본 원인 분석, 예방책


---

### **동적 테스팅 중 결함 보고서 내용**

### **1. 고유 식별자 (Unique ID)**

형식: DEF-YYYY-NNN

예시:
DEF-2024-001
DEF-2024-002
...
DEF-2024-145

자동 생성 (Jira, Bugzilla):
PROJ-123
BUG-456


---

### **2. 제목 (Title/Summary)**

**원칙:** 간결하고 명확하게

❌ 나쁜 예:

"버그"
"결제가 안 됨"
"문제 발생"

✅ 좋은 예:

"신용카드 결제 시 금액이 2배로 청구됨"
"로그인 후 세션 타임아웃이 5분으로 설정됨 (설계: 30분)"
"장바구니에서 상품 삭제 시 총액이 업데이트되지 않음"


---

### **3. 날짜, 조직, 작성자**

발견 날짜: 2024-11-16
보고 날짜: 2024-11-16 15:30
보고 조직: QA Team
작성자: 김테스터 (Tester)
이메일: kim.tester@company.com


---

### **4. 테스트 대상 및 테스트 환경**

**테스트 대상:**

애플리케이션: 전자상거래 웹앱
버전: v2.0.1
빌드: #234
Git Commit: a3b2c1d
모듈: 결제 (Payment Module)


**테스트 환경:**

환경: Staging
URL: https://staging.example.com
OS: Windows 11
브라우저: Chrome 119.0.6045.105
데이터베이스: PostgreSQL 13.4
외부 서비스: Payment Gateway Mock v1.5
네트워크: 회사 내부망


---

### **5. 결함의 정황 (Context)**

테스트 활동: 시스템 테스트
테스트 주기: Sprint 5
테스트 레벨: System Testing
실행 테스트 케이스: TC-2024-PAY-015 v1.2
테스트 기법: 경계값 분석
테스트 데이터: payment_testdata.csv (Row #23)
SDLC 단계: 테스트 단계
관련 요구사항: REQ-PAY-003 "결제 금액 검증"


---

### **6. 재현 절차 (Steps to Reproduce)**

**가장 중요한 부분 - 상세하고 명확하게**

전제 조건:
1. 사용자가 로그인되어 있음 (ID: testuser01)
2. 장바구니에 상품 3개 있음 (총 ₩50,000)

재현 단계:
1. 장바구니 페이지로 이동
URL: /cart

"결제하기" 버튼 클릭
결제 정보 입력:
- 카드 번호: 1234-5678-9012-3456
- 유효기간: 12/25
- CVC: 123
- 결제 금액 확인: ₩50,000 표시됨 ✅
"결제 완료" 버튼 클릭
결제 완료 페이지로 이동
URL: /payment/complete

실제 결과 (Actual):

결제 완료 메시지: "₩100,000 결제가 완료되었습니다"
주문 상세에서도 ₩100,000로 표시됨
실제 청구 금액: ₩100,000 (2배)

기대 결과 (Expected):

결제 완료 메시지: "₩50,000 결제가 완료되었습니다"
주문 상세에서도 ₩50,000로 표시됨
실제 청구 금액: ₩50,000

차이점:
결제 금액이 예상의 2배로 청구됨


---

### **7. 증적 자료 (Evidence)**

첨부 파일:
1. 스크린샷:

screenshot_cart_page.png (장바구니, ₩50,000)
screenshot_payment_page.png (결제 입력)
screenshot_complete_page.png (완료, ₩100,000) ⚠️

테스트 로그:
- test_log_2024-11-16_15-30.txt
네트워크 로그:
- network_trace.har
- API 요청/응답 캡처
데이터베이스 덤프:
- order_table_dump.sql (주문 레코드)
화면 녹화:
- screen_recording.mp4 (전체 재현 과정)

로그 발췌:

[2024-11-16 15:30:42] POST /api/v2/payment
Request: {"amount": 50000, "orderId": "ORD-12345"}
Response: {"status": "success", "chargedAmount": 100000}
                                                 ^^^^^^^^


---

### **8. 기대 결과와 실제 결과**

구분:
┌─────────────┬──────────────┬──────────────┐
│ 항목 │ 기대 결과 │ 실제 결과 │
├─────────────┼──────────────┼──────────────┤
│ 결제 금액 │ ₩50,000 │ ₩100,000 ⚠️ │
│ 완료 메시지 │ ₩50,000 표시 │ ₩100,000 표시│
│ 주문 상세 │ ₩50,000 │ ₩100,000 │
│ DB 레코드 │ 50000 │ 100000 │
└─────────────┴──────────────┴──────────────┘


---

### **9. 심각도 (Severity)**

**이해관계자의 이익/요구사항에 끼치는 영향**

분류:

S1 - 치명적 (Critical):

시스템 크래시, 데이터 손실
핵심 기능 완전 불가
보안 취약점 (높음)
금전적 손실 직결

S2 - 높음 (High):

주요 기능 오작동
데이터 정확성 오류
사용자 경험 심각한 저하
회피책 없음

S3 - 중간 (Medium):

일부 기능 오작동
회피책 존재하나 불편
사용자 불편

S4 - 낮음 (Low):

사소한 오류
UI/UX 개선 사항
회피책 쉬움

본 결함 평가:
심각도: S1 - 치명적
이유:

금전적 손실 직결 (2배 과금)
고객 신뢰 손상
법적 문제 가능성
핵심 비즈니스 기능 (결제)


---

### **10. 우선순위 (Priority)**

**수정 우선순위 (개발 관점)**

분류:

P1 - 긴급 (Urgent):

즉시 수정 필요
릴리스 차단 (Blocker)
다른 작업 중단하고 처리

P2 - 높음 (High):

릴리스 전 반드시 수정
다음 빌드에 포함

P3 - 중간 (Medium):

다음 스프린트/릴리스
계획된 일정 내 수정

P4 - 낮음 (Low):

시간 날 때 수정
마이너 릴리스에 포함

본 결함 평가:
우선순위: P1 - 긴급
이유:

릴리스 차단
고객 영향 심각
즉시 핫픽스 필요


**심각도 vs 우선순위 매트릭스:**

     │  S1     S2     S3     S4
     │ 치명적  높음   중간   낮음

─────────┼─────────────────────────
P1 긴급 │ ● ● ○
P2 높음 │ ● ● ● ○
P3 중간 │ ○ ● ●
P4 낮음 │ ○ ●

● = 일반적 조합
○ = 가능한 조합

예:
S1 + P1 = 결제 2배 청구 (본 결함)
S4 + P3 = 도움말 오타
S1 + P3 = 보안 취약점이나 영향 범위 제한적


---

### **11. 결함 상태 (Status)**

**작업 흐름 (Workflow)**

상태 전이:

신규 (New)
↓
할당됨 (Assigned) → 개발자에게 배정
↓
분석 중 (In Analysis) → 원인 조사
↓
수정 대기 (Open) → 수정 대기열
↓
수정 중 (In Progress) → 개발자 작업 중
↓
수정 완료 (Fixed) → 수정 완료, 빌드 배포
↓
확인 테스트 대기 (Ready for Retest)
↓
재테스트 중 (Retesting) → 테스터 검증
↓
├─ 완료 (Closed) → 수정 확인 ✅
├─ 재오픈 (Reopened) → 여전히 발생 ⚠️
├─ 거부 (Rejected) → 결함 아님
├─ 연기 (Deferred) → 다음 릴리스
└─ 중복 (Duplicate) → 기존 결함과 동일

본 결함 상태:
현재: 신규 (New)
배정 대상: 결제 모듈 개발자 (박개발)


---

### **12. 참조 사항 (References)**

(ISTQB) 자격증 정리 문서

다음 포스트