📌 핵심 용어 정리

ISTQB F/L Syllabus

🧩 제 1 장 테스팅의 기초(Fundamentals of Testing)

• 커버리지 (coverage): 특정 커버리지 항목(요구사항, 코드 구문 등)이 테스트에 의해 다뤄진 정도. 백분율로 표시
• 디버깅 (debugging): 장애의 원인(결함)을 찾고, 분석하고, 제거하는 개발 활동. 테스팅과는 별개의 활동임 (테스팅은 결함을 찾고, 디버깅은 결함을 고침)
• 결함 (defect): 작업 산출물에 존재하는 결점이나 흠. 실행되면 장애를 유발할 수 있음. '버그'라고도 함
• 오류 (error): 사람이 저지르는 실수. 시간 압박, 복잡성, 피로, 훈련 부족 등으로 발생하며, 결함으로 이어짐
• 장애 (failure): 결함이 실행되어 실제로 시스템이 요구된 기능을 수행하지 못하거나, 수행하지 않아야 할 동작을 하는 것
• 품질 (quality): 소프트웨어 산출물이 명시된/암묵적인 요구사항, 필요, 기대를 충족하는 정도
• 품질 보증 (QA, Quality Assurance): 프로세스 중심의 예방적 접근법. 좋은 프로세스를 준수하면 좋은 제품이 나온다는 가정 하에 프로세스 구현/개선에 초점 (테스팅=교정적, QA=예방적 → 둘은 다름)
• 근본 원인 (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): 시스템이 명시된 요구사항을 충족하는지 확인하는 것 (시스템을 올바르게 만들었는가?)

---

Root Cause → Error → Defect → Failure

• Error = 사람의 실수
• Defect = 산출물에 생긴 결함
• Failure = 실행 시 나타난 잘못된 동작

Test Analysis → Test Design → Test Implementation

• Analysis = 무엇을 테스트?
• Design = 어떻게 테스트?
• Implementation = 실행할 수 있게 준비

Monitoring ↔ Control

• Monitoring = 계획 대비 진행 상황 확인
• Control = 필요한 조치 수행

Verification ↔ Validation

• Verification = 요구사항대로 만들었나?
• Validation = 실제 사용자가 원하는 걸 만들었나?

🧩 제 2 장 소프트웨어 개발수명주기(SDLC)와 테스팅

• 인수 테스팅 (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): 테스트를 소프트웨어 개발수명주기 초기에 더 일찍 수행하는 접근법
• 시스템 통합 테스팅 (system integration testing): 테스트 대상 시스템과 다른 시스템 또는 외부 서비스 간의 인터페이스를 테스트하는 데 중점을 둔 테스트 레벨
• 시스템 테스팅 (system testing): 전체 시스템 또는 제품의 전반적인 동작과 기능에 중점을 둔 테스트 레벨. 기능 테스팅과 비기능 테스팅을 포함
• 테스트 레벨 (test level): 특정 개발 단계의 소프트웨어와 관련해 수행하는, 함께 구성하고 관리하는 테스트 활동의 집합
• 테스트 대상 (test object): 테스트의 대상이 되는 작업 산출물
• 테스트 유형 (test type): 특정 품질 특성과 관련된 테스트 활동의 집합. 대부분의 테스트 레벨에서 수행 가능
• 화이트박스 테스팅 (white-box testing): 구조 기반이며, 시스템의 구현 또는 내부 구조(코드, 아키텍처 등)에서 테스트를 도출하는 테스트 유형

---

Confirmation Testing ↔ Regression Testing

• Confirmation = 원래 결함이 제대로 고쳐졌는지 확인
• Regression = 변경으로 인해 다른 곳에 부작용이 없는지 확인

Component → Component Integration → System → System Integration → Acceptance

• 테스트 레벨은 소프트웨어 규모가 커지는 순서로 진행 (컴포넌트 → 컴포넌트 통합 → 시스템 → 시스템 통합 → 인수)

Functional ↔ Non-functional

• Functional = 무엇을 하는가 (What)
• Non-functional = 얼마나 잘하는가 (How well)

Black-box ↔ White-box

• Black-box = 명세 기반, 내부 구조를 참조하지 않고 명세·요구사항·기대 동작을 기반으로 테스트 도출
• White-box = 구조 기반, 내부 코드/구현 참조

🧩 제 3 장 정적 테스팅(Static Testing)

• 이상 사항 (anomaly): 표준, 명세, 기대치, 사용자 인식 등에서 벗어난 상태. 결함일 수도, 아닐 수도 있음
• 동적 테스팅 (dynamic testing): 테스트 대상 소프트웨어를 실제로 실행해서 수행하는 테스팅
• 공식 리뷰 (formal review): 정의된 프로세스(계획, 착수, 개별 리뷰, 논의, 수정, 보고)를 철저히 따르는 리뷰. 인스펙션이 대표적
• 비공식 리뷰 (informal review): 정의된 프로세스를 따르지 않으며, 공식적인 결과 문서도 요구하지 않는 리뷰. 이상 사항 식별이 주 목적
• 인스펙션 (inspection): 가장 공식적인 리뷰 유형. 저자가 리뷰 리더나 서기가 될 수 없으며, 이상 사항을 최대한 많이 찾는 것이 목적
• 리뷰 (review): 작업 산출물을 이해관계자들이 평가해 이상 사항을 찾고 개선하는 정적 테스팅 기법
• 정적 분석 (static analysis): 도구를 사용해 코드나 산출물을 실행하지 않고 분석하는 것
• 정적 테스팅 (static testing): 테스트 대상 소프트웨어를 실행하지 않고 수행하는 테스팅 (리뷰, 정적 분석 포함)
• 기술 리뷰 (technical review): 기술적 자격을 갖춘 리뷰어가 수행하며, 중재자가 리더가 되는 리뷰. 기술적 합의 도출이 목적
• 워크쓰루 (walkthrough): 저자가 리더가 되어 진행하는 리뷰. 신뢰 구축, 교육, 아이디어 창출 등 다양한 목적

---

Static Testing ↔ Dynamic Testing

• Static = 실행 안 함 (리뷰, 정적 분석)
• Dynamic = 실행함

Informal Review → Walkthrough → Technical Review → Inspection

• 공식성이 낮은 순서에서 높은 순서로 (Inspection이 가장 공식적)

리뷰 주요 역할

• 관리자 = 리뷰 자원 제공
• 저자 = 산출물 작성/수정
• 중재자(퍼실리테이터) = 회의 운영
• 서기(기록자) = 이상 사항 기록
• 리뷰어 = 리뷰 수행
• 리뷰 리더 = 전반적 책임

저자가 리더/서기를 못 맡는 리뷰

• Inspection (가장 공식적이므로 객관성 유지를 위해)

🧩 제 4 장 테스트 분석과 설계(Test Analysis and Design)

4.1 테스트 기법 개요

• 테스트 기법 (test technique): 테스트 분석과 설계를 지원하는 절차. 블랙박스, 화이트박스, 경험 기반으로 분류

4.2 블랙박스 테스트 기법

• 블랙박스 테스트 기법 (black-box test technique): 명세 기반 기법. 내부 구조를 참조하지 않고 명시된 동작을 기반으로 테스트 도출
• 동등 분할 (equivalence partitioning): 테스트 대상 데이터를 동일하게 처리될 것으로 예상되는 분할(파티션) 단위로 나누는 기법
• 경계값 분석 (boundary value analysis): 동등 분할의 경계에 있는 값을 테스트하는 기법. 두 개 선택(2-value)과 세 개 선택(3-value) 방식이 있음
• 결정 테이블 테스팅 (decision table testing): 조건들의 다양한 조합과 그에 따른 결과(동작)를 표로 정리해 테스트하는 기법
• 상태 전이 테스팅 (state transition testing): 시스템의 상태와 상태 간 전이(이벤트에 의한 변화)를 기반으로 테스트를 도출하는 기법
• 커버리지 (coverage): 테스트 케이스가 실행한 커버리지 항목 수를 전체 커버리지 항목 수로 나눈 값
• 커버리지 항목 (coverage item): 테스트 기법에 따라 정의되는 테스트 대상(예: 동등 분할에서는 분할, 결정 테이블에서는 규칙 열)

4.3 화이트박스 테스트 기법

• 화이트박스 테스트 기법 (white-box test technique): 구조 기반 기법. 테스트 대상의 내부 구조와 처리 로직을 기반으로 테스트 도출
• 구문 커버리지 (statement coverage): 코드의 실행 가능한 구문이 테스트 케이스에 의해 실행된 비율
• 분기 커버리지 (branch coverage): 코드의 분기(조건의 참/거짓 결과 등)가 테스트 케이스에 의해 실행된 비율. 구문 커버리지를 포함함

4.4 경험 기반 테스트 기법

• 경험 기반 테스트 기법 (experience-based test technique): 테스터의 지식과 경험을 활용해 테스트 케이스를 설계하는 기법
• 오류 추정 (error guessing): 테스터의 지식(과거 동작, 흔한 오류 유형 등)을 기반으로 오류·결함·장애 발생을 예측하는 기법
• 탐색적 테스팅 (exploratory testing): 테스트의 설계, 실행, 평가를 동시에 하며 배워가는 테스팅. 세션 기반 테스팅으로 구조화하기도 함
• 체크리스트 기반 테스팅 (checklist-based testing): 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계·실행하는 기법

4.5 협업 기반 테스트 접근법

• 협업 기반 테스트 접근법 (collaboration-based test approach): 결함 예방을 위해 협업과 커뮤니케이션에 초점을 둔 테스트 접근법
• 인수 조건 (acceptance criteria): 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건
• 인수 테스트 주도 개발 (ATDD, acceptance test-driven development): 사용자 스토리 구현 전에 인수 조건을 기반으로 테스트 케이스를 먼저 만드는 테스트 우선 접근법

---

블랙박스 vs 화이트박스 vs 경험 기반

• 블랙박스 = 명세 기반, 내부 구조 모름
• 화이트박스 = 구조 기반, 내부 코드 참조
• 경험 기반 = 테스터의 지식·경험 기반

경계값 분석: 2-value vs 3-value

• 2-value = 경계값 + 인접값 1개 (경계값당 커버리지 항목 2개)
• 3-value = 경계값 + 양쪽 인접값 (경계값당 커버리지 항목 3개, 더 엄격함)

구문 커버리지 ⊂ 분기 커버리지

• 분기 커버리지 100% 달성 → 구문 커버리지도 100% (역은 성립 안 함)

상태 전이 테스팅 커버리지 강도

• 모든 상태 커버리지 < 유효 전이 커버리지 < 모든 전이 커버리지

사용자 스토리의 3C

• Card(카드) = 설명 매체
• Conversation(대화) = 사용 방법 설명
• Confirmation(확인) = 인수 조건

좋은 사용자 스토리 = INVEST

• Independent, Negotiable, Valuable, Estimable, Small, Testable

🧩 제 5 장 테스트 활동 관리(Test Management)

5.1 테스트 계획

• 테스트 접근법 (test approach): 테스트 목적 달성을 위해 선택하는 방법(테스트 레벨, 유형, 기법 등을 포함)
• 테스트 계획 (test planning): 테스트 목적을 정의하고 그것을 달성할 접근법을 선택하는 활동
• 테스트 계획서 (test plan): 테스트 프로젝트의 테스트 목적, 자원, 프로세스를 설명하는 문서
• 시작 조건 (entry criteria): 어떤 활동을 수행하기 위한 전제 조건
• 완료 조건 (exit criteria): 특정 활동의 종료를 선언하기 위해 달성해야 하는 사항
• 테스트 피라미드 (test pyramid): 테스트의 세분화 수준이 다르다는 것을 보여주는 모델. 아래층일수록 작고 빠르고 많은 테스트, 위층일수록 크고 느리고 적은 테스트
• 테스팅 사분면 (testing quadrants): 테스트 레벨을 적합한 테스트 유형·활동·기법과 묶어 시각화한 모델 (브라이언 마릭 정의)

5.2 리스크 관리

• 리스크 (risk): 발생 시 부정적인 영향을 미칠 수 있는 잠재적인 사건·위험·위협·상황
• 리스크 분석 (risk analysis): 리스크 식별과 리스크 평가로 구성되는 활동
• 리스크 평가 (risk assessment): 식별한 리스크를 분류하고 발생 가능성·영향·수준을 결정하는 활동
• 리스크 제어 (risk control): 식별·평가된 리스크에 대응해 취하는 조치 (리스크 완화 + 리스크 모니터링)
• 리스크 식별 (risk identification): 포괄적인 리스크 목록을 생성하는 활동
• 리스크 수준 (risk level): 리스크 발생 가능성과 리스크 영향(피해)의 조합으로 결정되는 리스크의 측정값
• 리스크 관리 (risk management): 리스크 분석과 리스크 제어를 포괄하는 전체 활동
• 리스크 완화 (risk mitigation): 리스크 평가 때 제안된 조치를 실행해 리스크 수준을 낮추는 활동
• 리스크 모니터링 (risk monitoring): 리스크 완화 조치의 효과 확인 및 새로운 리스크 식별
• 리스크 기반 테스팅 (risk-based testing): 리스크 분석과 리스크 제어를 기반으로 테스트 활동의 우선순위를 정해 관리하는 접근법
• 프로젝트 리스크 (project risk): 프로젝트 관리 및 제어와 관련된 리스크 (일정, 인력, 예산 등)
• 제품 리스크 (product risk): 제품의 품질 특성과 관련된 리스크 (잘못된 기능, 성능 문제, 보안 취약점 등)

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

• 테스트 모니터링 (test monitoring): 테스트 정보를 수집해 진행 상황을 평가하고 완료 조건 충족 여부를 측정하는 활동
• 테스트 제어 (test control): 모니터링 정보를 기반으로 효과적인 테스팅을 위한 지침·수정 조치를 제공하는 활동
• 테스트 진행 보고서 (test progress report): 지속적인 테스트 제어를 지원하기 위해 정기적으로 작성하는 보고서
• 테스트 완료 보고서 (test completion report): 특정 테스트 활동(레벨, 주기 등)을 요약하고 후속 테스팅 정보를 제공하는 보고서

5.4 형상 관리

• (형상 관리 자체는 용어集에는 없지만) 테스트 계획서, 케이스, 결과 등의 작업 산출물을 식별·제어·추적하는 활동. 베이스라인 설정과 변경 제어를 통해 테스트 재현성을 보장

5.5 결함 관리

• 결함 관리 (defect management): 결함이나 이상 사항을 발견부터 종료까지 처리하는 프로세스
• 결함 보고서 (defect report): 결함(이상 사항)을 문서화해 담당자에게 전달하는 보고서

---

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

• 발생 가능성(Probability) × 영향/피해(Impact) → 리스크 수준 결정

Project Risk ↔ Product Risk

• Project Risk = 프로젝트를 못 끝낼 리스크 (일정, 인력, 예산)
• Product Risk = 제품 품질이 나쁠 리스크 (기능, 성능, 보안)

Risk Analysis = Identification + AssessmentRisk Control = Mitigation + Monitoring

• 분석(식별→평가) 후 제어(완화+모니터링)로 이어지는 흐름

Test Monitoring ↔ Test Control (1장에서 나온 것과 동일 개념, 5장에서 심화)

• Monitoring = 정보 수집·측정
• Control = 그에 따른 조치

추정 기법 4가지

• 비율 기반 추정 (Estimation based on ratios)
• 외삽법 (Extrapolation)
• 와이드밴드 델파이 (Wideband Delphi) — 플래닝 포커가 애자일 변형
• 3점 추정 (Three-point estimation) — E=(a+4m+b)/6

테스트 케이스 우선순위지정 3가지

• 리스크 기반 / 커버리지 기반 / 요구사항 기반

테스트 피라미드 vs 테스팅 사분면

• 피라미드 = 테스트 자동화 수준·세분화에 따른 구조
• 사분면 = 테스트 레벨을 비즈니스/기술 × 팀지원/제품평가 축으로 분류

🧩 제 6 장 테스트 도구(Test Tools)

• 테스트 자동화 (test automation): 테스트 활동(주로 테스트 실행)을 도구를 사용해 자동으로 수행하는 것

6.1 테스팅 지원 도구 유형

• 테스트 관리 도구: SDLC, 요구사항, 테스트, 결함, 형상 관리를 지원
• 정적 테스팅 도구: 리뷰와 정적 분석 수행을 지원
• 테스트 설계 및 구현 도구: 테스트 케이스, 데이터, 절차 생성을 지원
• 테스트 실행 및 커버리지 도구: 자동 테스트 실행 및 커버리지 측정을 지원
• 비기능 테스팅 도구: 수동으로 하기 어려운 비기능 테스트(성능 등) 수행을 지원
• 데브옵스 도구: 배포 파이프라인, 지속적 통합/배포 등을 지원
• 협업 도구: 팀 간 커뮤니케이션 지원
• 확장성/배포 표준화 도구: 가상 머신, 컨테이너화 도구 등

6.2 테스트 자동화의 효과와 리스크

효과

• 반복적 수작업 감소로 시간 절약
• 일관성·재현성 향상
• 객관적 평가·측정치 제공
• 테스트 정보 접근성 향상
• 테스트 실행 시간 단축
• 테스터가 더 심층적인 테스트 설계에 집중 가능

리스크

• 도구 효과에 대한 비현실적 기대
• 도입·유지보수 비용/노력의 부정확한 추정
• 수동이 더 적합한 곳에 도구 사용
• 도구에 대한 과도한 의존
• 도구 공급업체 종속성
• 오픈소스 소프트웨어의 지원 중단 리스크
• 개발 플랫폼과의 호환성 문제
• 규제·안전 표준 미준수 도구 선택

---

도구 유형 암기 팁

• 관리 / 정적 / 설계·구현 / 실행·커버리지 / 비기능 / 데브옵스 / 협업 / 확장성

자동화 효과 vs 리스크

• 효과 = 시간·일관성·객관성·접근성·속도
• 리스크 = 기대·비용·의존·종속성·호환성