ISTQB 4.0 Foundation level 간략정리

ISTQB Foundation Level 4.0 Syllabus Summary

Chapter 1: Fundamentals of Testing

Concept (English) 설명 (Korean 설명)

Testing🔹 (테스팅)	소프트웨어 품질을 평가하고 결함을 찾아내어 위험을 줄이는 과정. 결과가 명세와 부합하는지 확인(검증)하고 사용자 요구사항을 충족하는지 검증하는 활동을 포함합니다. 동적 테스트(실행)와 정적 테스트(코드/문서 검토)로 수행될 수 있습니다.
Debugging (디버깅)	테스트 중 발견된 결함(버그)의 원인을 찾아 수정하는 활동. 테스트가 실패를 유발하면 디버깅은 이 실패의 원인을 찾아 결함을 제거하고 수정사항의 정합성을 확인합니다.
Testing vs Quality Assurance (테스트 vs QA)	Testing은 제품 중심의 활동으로 결함을 찾아 수정하는 교정적 접근입니다. 반면 *Quality Assurance (QA)*는 프로세스 중심의 활동으로 예방적 접근을 통해 프로세스 품질을 보장합니다. 테스트 결과는 QA와 테스트 모두에 피드백으로 활용됩니다.
Error/Defect/Failure/Root Cause (오류/결함/실패/근본원인)	사람의 실수(오류)로 소프트웨어에 결함이 생기고, 코드 실행 시 결함이 실제 실패를 유발할 수 있습니다. *결함(defect)*은 코드나 요구사항의 결함이며, 실행 시 시스템이 예상한 동작을 하지 않을 때 *실패(failure)*가 발생합니다. *근본원인(root cause)*은 이러한 문제가 발생한 근원으로, 근본원인 분석을 통해 결함 재발을 방지합니다.

Testing Principles

Principle (English) 설명 (Korean)

🔹 1. Presence, not absence of defects (결함 존재만 확인 가능)	테스트는 결함이 있음을 보여줄 수 있지만, 없음을 증명할 수는 없습니다. 아무리 결함이 발견되지 않아도 테스트만으로 시스템 완전 무결성을 보장할 수 없습니다.
🔹 2. Exhaustive testing is impossible (포괄적 테스트 불가능)	모든 입력이나 시나리오를 테스트하는 것은 사실상 불가능합니다. 효과적인 테스트를 위해 기술, 우선순위, 위험 기반 접근으로 테스트 범위를 좁혀야 합니다.
🔹 3. Early testing (초기 테스팅)	가능한 한 개발 초기에 테스트를 시작하면 이후 단계에서 생길 결함과 비용을 줄일 수 있습니다. 정적 리뷰와 동적 테스트를 조기에 수행하면 SDLC 후반의 품질 비용을 절감합니다.
🔹 4. Defect clustering (결함 집중 현상)	소수의 컴포넌트/영역에 대부분의 결함이 집중되는 경향이 있습니다 (파레토 원칙). 예측된 또는 실제 발견된 결함 클러스터를 통해 위험 기반 테스트 범위를 결정할 수 있습니다.
🔹 5. Tests wear out (테스트의 노후화)	동일한 테스트를 반복하면 점점 새로운 결함 탐지에 비효율적이 됩니다. 테스트와 데이터를 갱신하거나 새로운 테스트를 추가해야 하며, 자동화된 회귀 테스트는 반복 실시에 유용할 수 있습니다.
🔹 6. Context-dependent testing (상황 의존적 테스팅)	보편적으로 모든 상황에 적용할 수 있는 단일 테스트 방식은 없습니다. 프로젝트 환경, 제품 특성에 따라 최적의 테스트 접근법은 달라지므로 상황에 맞게 계획해야 합니다.
🔹 7. Absence-of-defects fallacy (결함 없음 착각)	결함이 없다고 시스템이 성공적일 것이라는 것은 잘못된 생각입니다. 모든 요구사항을 테스트하고 모든 결함을 고친다 해도 고객 가치나 사용자의 요구를 충족하지 못할 수 있습니다. 검증에 더해 검증(Validation)도 필요합니다.

Test Process, Artifacts, and Roles

Concept (English) 설명 (Korean)

Test Process / Activities (테스트 프로세스)	테스트는 상황에 따라 달라지지만 공통 활동으로 기획, 분석·설계, 구현, 실행, 완료가 있습니다. 각 활동은 순차적이거나 반복적으로 이루어지며, 문맥에 맞게 조정합니다.
Test Plan (테스트 계획)	테스트 목표, 범위, 리소스, 일정, 접근법 등을 문서화한 계획서. 테스트 목적 달성을 위한 방법과 일정을 정의하며, 팀과 이해관계자 간의 커뮤니케이션 수단이 됩니다.
Entry/Exit Criteria (사전/종료 기준)	Entry Criteria는 테스트를 시작하기 위한 전제조건(환경, 테스트베이스, 테스터 확보 등)이며, Exit Criteria는 테스트 종료를 선언하기 위한 조건(커버리지 수준, 알려진 결함 수 등)입니다. 프로젝트나 레벨별로 정의해둡니다.
Testware (테스트웨어)	테스트 활동의 산출물들을 의미합니다. 예: 테스트 계획서, 테스트 케이스, 테스트 스크립트, 로그, 보고서 등. 모든 테스트산출물을 관리하고 버전 관리하며 변경 이력을 남겨야 합니다.
Traceability (추적성)	테스트 근거(요구사항, 설계 등)와 테스트웨어(테스트 케이스, 리스크 등) 간의 관계를 기록하고 유지하는 것. 추적성은 커버리지 평가에 필수적이며, 테스트 커버리지 기준 설정과 테스트 목표 달성도를 관리합니다.
Roles in Testing (테스트 역할)	주된 역할은 테스트 관리자(테스트 기획/모니터링/통제)와 테스터(분석/설계/실행)입니다. 관리자 역할은 테스트 전반을 총괄하고 일정·리소스 관리를 담당하며, 테스터 역할은 기술적 테스트 수행에 집중합니다.
Whole Team Approach (전체 팀 접근)	모든 팀원이 품질에 책임을 지고, 필요시 누구나 테스트 업무를 수행하는 협업 방식입니다. 팀원들은 공동의 공간에서 소통하며, 비즈니스·개발·테스트 관점을 결합해 인수를 만족시킬 수 있는 사용자 스토리를 만듭니다.
Independence of Testing (테스트 독립성)	적정 수준의 독립성은 개발자와 테스터의 편향 차이로 새로운 결함 탐지에 도움을 줍니다. 동일 팀 내 동료에 의한 테스트(일부 독립)나 별도 팀/외부 테스터(고독립) 등 다양한 수준을 활용하여 결함 감지를 극대화합니다.

Chapter 2: Testing Throughout the Software Development Lifecycle

Concept (English) 설명 (Korean)

SDLC Models (개발 생명주기 모델)	워터폴, V-모델(순차적)과 스파이럴, XP(반복적/애자일) 같은 다양한 SDLC 모델이 있습니다. 모델에 따라 테스트 시점과 방법이 달라집니다.
Waterfall/V-model	순차적 개발 모델로 초기 단계에 테스트 계획과 설계, 이후 단계에서 코드 실행 테스트가 이뤄집니다. 테스트는 개발 단계별로 분리되어 순서대로 진행됩니다.
Agile/DevOps	애자일 개발은 잦은 변화를 가정하며, 경량 문서화, 광범위한 자동화, 경험 기반 테스트를 강조합니다. 지속적 통합(CI)/지속적 전달(CD)을 통해 빠른 피드백과 회귀 테스트를 지원합니다.
Shift Left (쉬프트 레프트)	가능한 한 SDLC 초기에 테스트를 배치하는 전략입니다. 사양 검토, 코드 개발 전 테스트케이스 작성, CI 도입 등으로 결함 탐지 시점을 앞당겨 이후 단계의 재작업 비용을 줄입니다.
Test Levels (테스트 레벨)	개발 단계에 따른 테스트 단계를 말합니다. 예: 컴포넌트 테스트(단위 기능 검증), 통합 테스트(모듈 간 인터페이스 검증), 시스템 테스트(전체 시스템 기능 검증), 시스템 통합 테스트(시스템 간 상호연계 검증), 인수 테스트(사용자 요구 충족 검증). 각 레벨은 목표와 범위가 다릅니다.
Test Types (테스트 유형)	기능 테스트: 시스템이 수행해야 할 기능을 검증. 비기능 테스트: 성능, 보안 등 동작 특성이 기준에 맞는지 검증. 블랙박스 테스트: 명세 기반 테스트, 내부 구조는 고려하지 않음. 화이트박스 테스트: 코드 구조 기반 테스트, 코드 내부 로직을 검증.
Confirmation Testing (확인 테스트)	결함 수정 후 해당 결함이 실제로 해결되었는지 확인하는 테스트입니다. 이전에 실패했던 테스트를 재실행하거나 수정된 영역을 중점 검증합니다.
Regression Testing (회귀 테스트)	소프트웨어 변경(새기능 추가 또는 버그 수정)으로 인해 기존 기능이 망가지지 않았는지 확인하는 테스트. 변경된 컴포넌트는 물론 관련 다른 영역까지 영향을 받지 않았는지 검증합니다.
Maintenance Testing (유지보수 테스트)	운영 중인 시스템의 변경사항(수정, 환경 전환, 데이터 마이그레이션 등)에 대한 테스트. 변경사항이 올바르게 구현되었는지와 함께 변경되지 않은 부분이 영향을 받지 않았는지(회귀) 확인합니다. 변경 리스크, 시스템 규모, 변경 범위에 따라 테스트 범위가 결정됩니다.

Chapter 3: Static Testing

Concept (English) 설명 (Korean)

Static Testing (정적 테스트)	소프트웨어를 실행하지 않고 코드, 설계, 문서 등을 검토하여 결함을 찾는 방법. 초기 단계에 결함을 발견하여 품질을 높이며, 가독성·완결성 같은 속성도 평가합니다. 동적 테스트와 상호보완적이며, 시빅 CI 자동화에 통합되기도 합니다.
Work Products Examinable by Static Testing	요구사항 문서, 디자인/설계 문서, 소스코드, 테스트 케이스 등 거의 모든 산출물이 검토 대상이 될 수 있습니다. 사람이 읽을 수 있으면 리뷰하고, 구조가 있으면(코드/모델) 도구 검사가 가능합니다.
Value of Static Testing	SDLC 초기에 결함을 발견해 비용 절감과 품질 향상에 기여합니다. 구현 전에 문제를 찾아내 고객의 요구사항이 잘 반영되도록 조기 이해와 의사소통을 돕습니다. 다양한 이해관계자를 참여시켜 공유된 이해를 구축합니다.
Review Process (리뷰 프로세스)	계획 → 준비 → 개별검토 → 분석·토론 → 수정 순으로 이루어지는 체계적 검토 절차입니다. 목표와 범위를 정하고, 검토자가 개별적으로 결함을 식별한 후 회의에서 토론하여 수정 및 후속 조치를 결정합니다. 이 과정에서 매니저, 작성자, 중재자, 기록자, 검토자 등의 역할이 참여합니다.
Review Types (검토 유형)	비공식 리뷰: 절차에 구애받지 않고 간단히 수행하여 결함만 탐색. 워크스루: 작성자가 주도하며 이해증진과 합의 도출을 목적으로 함. 기술 리뷰/인스펙션 등 공식 리뷰는 IEEE 표준을 따르며 더 엄격하게 진행됩니다.

Chapter 4: Test Analysis and Design

Concept (English) 설명 (Korean)

Equivalence Partitioning (EP)🔹	입력 범위를 동치 클래스(Partition)로 나누고 각 클래스에서 대표값만 테스트하는 기법. 같은 클래스로 분류된 값들은 동일하게 처리되므로, 클래스당 하나의 테스트로 충분합니다.
Boundary Value Analysis (BVA)🔹	동치 클래스의 경계값(최소/최대)과 그 인접값을 중점적으로 테스트하는 기법. 개발자는 경계값 처리에서 실수를 많이 하므로, 경계 근처 값들을 포함해 테스트합니다. 2-값(BVA2)과 3-값(BVA3) 방식이 있으며, 경계-이웃 값까지 포함할수록 엄격합니다.
Decision Table Testing	입력 조건의 조합과 결과를 표로 작성해 모든 조합을 테스트하는 기법. 각 열(Column)이 하나의 조건 조합(규칙)을 나타내며, 해당 조합에 따른 동작을 검증합니다. 복잡한 비즈니스 규칙을 누락 없이 검증할 수 있습니다.
State Transition Testing	시스템의 상태(State)와 상태 전이(Transition)를 모델로 테스트하는 기법. 이벤트에 따라 상태가 어떻게 변하는지 설계 다이어그램/테이블로 표현하고, 상태 변화 시나리오를 따라가며 전이와 결과 동작을 확인합니다.
Statement Coverage (구문 커버리지)	코드의 모든 실행 문장을 최소 한 번은 실행하여 테스트하는 방식. 100% 달성 시 코드상의 결함은 실행되어 발견 가능하지만, 분기 로직까지 완전히 검증하지는 못할 수 있습니다.
Branch Coverage (분기 커버리지)	코드의 모든 분기(조건 true/false)를 테스트하는 방식. 조건문의 참/거짓 경로를 모두 실행하여 결함을 찾습니다. 분기 커버리지는 구문 커버리지를 포함하며, 100% 분기 커버는 100% 구문 커버를 보장하지만 그 반대는 아닙니다.
Error Guessing (에러 추측)	테스터의 경험과 직관을 활용하여, 과거 결함 유형이나 도메인 지식을 바탕으로 결함이 있을 법한 부분을 직접 예상하고 테스트합니다. 특정 알고리즘, 과거 버그 이력 등을 참고하여 테스트 케이스를 작성합니다.
Exploratory Testing (탐색적 테스트)	테스트 계획과 설계 없이 테스터가 실행하면서 학습하고 동적으로 테스트를 설계하는 방식입니다. 제한된 문서나 시간 내에 빠르게 오류를 찾아내고, 필요한 테스트 아이디어를 즉석에서 생성하여 적용합니다.
User Story/Acceptance Criteria	사용자 스토리: 역할·목표·이유로 구성된 기능 설명(예: As a [role], I want [goal], so that [value]). 수용 기준(AC): 스토리가 충족해야 하는 조건으로, 테스트 조건으로 활용됩니다. 협업으로 작성하며, 명확(Independent, Negotiable, Valuable, Estimable, Small, Testable)해야 합니다.
Acceptance Test-driven Dev. (ATDD)	기능 구현 전에 테스터·개발자·고객이 함께 수용 테스트 케이스를 작성한 후 개발하는 방식. 사용자 스토리의 수용 기준 기반으로 테스트 케이스를 먼저 작성하고, 이를 만족하도록 코드를 구현합니다. 이로써 스토리의 불완전/모호함을 조기에 해소합니다.

Chapter 5: Managing the Test Activities

Concept (English) 설명 (Korean)

Test Planning & Estimation (테스트 계획/추정)	테스트 계획에는 범위, 목표, 리소스, 일정, 접근법, 산출물(테스트 케이스, 환경 등), 위험 리스트 등이 포함됩니다. 추정 기법으로는 과거 데이터 기반 비율법, 현 프로젝트 데이터 외삽(Extrapolation), 전문가 기법(Planning Poker, 삼점 추정) 등이 있습니다.
Entry/Exit Criteria (사전/종료 기준)	테스트 수행 전제조건(Entry): 환경 및 테스트 산출물(테스트베이스, 테스트케이스 등) 준비, 필수 이전 테스트 완료 등. 종료조건(Exit): 커버리지 목표 달성, 결함 기준치 이하, 테스트 완료 등의 만족 조건입니다. 기간/예산 소진도 종료 기준이 될 수 있습니다.
Test Case Prioritization (테스트 우선순위)	위험 기반(높은 리스크 우선), 커버리지 기반(커버리지 높은 케이스 우선), 요구사항 기반(중요 요구사항 우선) 등의 전략으로 테스트 실행 순서를 정합니다. 의존성, 자원 가용성도 고려하여 실행 순서를 조정합니다.
Test Pyramid (테스트 피라미드)	테스트 자동화 비율을 계층화해 보여주는 모델입니다. 하단(Unit/API 테스트)은 많고, 상단(UI 테스트)은 적게 배치하도록 권장합니다. 테스트 유형별로 자동화 비중을 달리하여 효율성과 안정성을 확보합니다.
Risk-Based Testing (리스크 기반 테스팅)	식별된 제품 리스크(발생 확률×영향력)에 따라 테스트 범위와 우선순위를 결정하는 접근 방식. 주요 리스크(예: 핵심 기능 결함, 보안 취약점)는 집중적으로 테스트하고, 리스크 수준이 높은 영역의 품질을 최대한 보장합니다.
Risk (리스크)	발생 시 부정적 영향을 주는 잠재적 사건이며, 확률과 영향으로 정의됩니다. 높은 확률・영향의 리스크일수록 우선 처리합니다. 소프트웨어 테스팅에서는 프로젝트 리스크(일정/예산 지연, 인력 부족 등)와 제품 리스크(기능 누락, 성능 저하, 보안 취약점 등)로 구분합니다.
Test Monitoring & Control (테스트 모니터링/통제)	모니터링: 테스트 진행 상황과 품질 상태를 수집해 계획 대비 진행도를 평가합니다. 통제: 모니터링 결과를 바탕으로 일정·범위 조정 등 시정 조치를 취해 테스트 목표 달성을 돕습니다. 예: 위험 증대 시 우선순위 조정, 리소스 추가 배치 등.
Metrics & Reporting (측정 지표/보고)	테스트 진행·품질을 측정하기 위한 지표로는 진행율, 커버리지, 결함 발견율, 잔류 리스크 등이 있습니다. 보고서에는 기간, 진척상황, 리스크/이슈 등을 포함하여 이해관계자에게 결과를 공유하고 의사결정을 지원합니다.
Configuration Management (형상 관리)	테스트 산출물(테스트베이스, 케이스, 스크립트, 결과물 등)을 형상 아이템으로 식별·버전관리·추적합니다. 테스트 환경이나 툴셋도 구성 항목으로 관리하며, 기준선을 설정하고 변경 관리를 통해 이전 상태로 복원할 수 있게 합니다.
Defect Management (결함 관리)	결함 리포트 작성부터 분석, 우선순위, 수정, 확인, 종료까지의 워크플로우를 정의합니다. 보고서에는 고유ID, 재현 단계, 예상/실제 결과, 심각도, 상태 등의 정보가 포함되어 담당자가 결함을 해결하고 프로세스를 개선할 수 있도록 지원합니다.

Chapter 6: Tool Support for Testing

Concept (English) 설명 (Korean)

Test Tool Categories (도구 종류)	여러 유형의 테스트 도구가 있습니다. 예: 테스트 관리도구(계획/결과/결함 관리) 정적 분석 도구, 테스트 설계/구현 도구(테스트케이스/데이터 생성) 테스트 실행 도구(자동 실행/커버리지) 비기능 테스트 도구(부하, 보안 등) DevOps 도구(CI/CD 파이프라인 지원) 협업 도구, 컨테이너/가상화 도구 등.
Automation Benefits (자동화 이점)	반복 작업 절감에 따른 시간 단축과 일관성 향상, 결함 검출 기준의 객관적 측정(커버리지, 통계) 제공, 더 빠른 실행으로 조기 피드백 및 시장 출시 단축 등이 있습니다.
Automation Risks (자동화 위험)	도구 도입·유지보수 비용, 부적절한 기대, 과도한 의존으로 인한 효율 저하 등이 있습니다. 적합한 도구 선택 실패, 툴 벤더 변경 등도 위험요소이며, 자동화로 모든 문제를 해결할 수 없음을 인식해야 합니다.

Sources: Official ISTQB® Certified Tester Foundation Level 4.0 syllabus.