ISTQB 4.0 Foundation Level [1장][2장] - 전체 요약 정리

 

Chapter 1: Fundamentals of Testing (테스팅의 기초)

"테스팅이란 무엇이며, 왜 필요한가?"에 대한 근본적인 질문에 답하는 챕터입니다.

1.1 What is Testing? (테스팅이란 무엇인가?)

테스팅은 단순히 결함을 찾는 활동을 넘어섭니다. 소프트웨어의 품질 수준에 대한 정보를 이해관계자에게 제공하여, 올바른 의사결정을 내릴 수 있도록 돕는 모든 활동을 포함합니다.

• 테스팅의 주요 목적 (Objectives of Testing) (암기)
  • 결함(Defects)을 예방하고 발견하는 것
  • 명시된 요구사항이 충족되었는지 검증(Verify)하는 것
  • 소프트웨어 품질 수준에 대한 신뢰도를 높이는 것
  • 릴리스(배포) 결정을 위한 충분한 정보를 제공하는 것
• 테스팅과 디버깅 (Testing vs. Debugging) (암기)
  테스트와 디버깅은 다른 활동입니다. 이 차이점을 아는 것은 매우 중요합니다.

구분	테스팅 (Testing)	디버깅 (Debugging)
목적	실패(Failure)를 유발하는 결함의 존재를 확인	결함의 원인을 찾아 분석하고 수정
수행 주체	주로 테스터 (독립적인 시각)	주로 개발자 (코드에 대한 이해)

1.2 Why is Testing Necessary? (테스팅은 왜 필요한가?)

소프트웨어 결함은 시간 및 비용 손실, 비즈니스 평판 손상, 심지어는 인명 사고까지 유발할 수 있습니다. 테스팅은 이러한 리스크(Risk)를 줄이고 소프트웨어 품질에 대한 신뢰를 구축하기 위해 필수적입니다.

• 에러, 결함, 실패의 인과관계 (Error, Defect, Failure) (암기)
  사람의 실수로부터 모든 것이 시작됩니다.
  1. 에러 (Error / Mistake): 사람이 저지르는 실수 (예: 코드의 논리를 잘못 생각함)
  2. 결함 (Defect / Bug / Fault): 에러의 결과로 코드나 문서에 남겨진 결점 (예: 잘못된 논리로 코드를 작성함)
  3. 실패 (Failure): 실행 중인 소프트웨어가 결함으로 인해 기대와 다르게 동작하는 현상 (예: 잘못된 코드가 실행되어 프로그램이 다운됨)
  4. https://msharp.tistory.com/203

1.3 Seven Testing Principles (7가지 테스팅 원리) (암기)

이 7가지 원리는 ISTQB의 핵심 철학이며, 시험에 반드시 출제됩니다.

1. Testing shows the presence of defects, not their absence.
   테스팅은 결함이 존재한다는 것을 보여줄 뿐, 결함이 없다는 것을 증명할 수는 없습니다.
2. Exhaustive testing is impossible.
   모든 입력과 조건의 조합을 테스트하는 것(전수 테스트)은 현실적으로 불가능합니다. 따라서 리스크와 우선순위를 고려한 테스트가 필요합니다.
3. Early testing saves time and money.
   개발 초기에 결함을 발견하고 수정하는 것이, 나중에 발견하는 것보다 훨씬 비용이 적게 듭니다. (Shift Left)
4. Defects cluster together.
   결함은 소프트웨어 전체에 고르게 퍼져있기보다는, 소수의 특정 모듈에 집중되는 경향이 있습니다. (파레토 법칙)
5. Beware of the pesticide paradox.
   동일한 테스트 케이스를 반복하면, 더 이상 새로운 결함을 찾을 수 없습니다. (살충제에 내성이 생기는 벌레처럼) 따라서 테스트 케이스는 지속적으로 검토하고 개선해야 합니다.
6. Testing is context-dependent.
   테스팅은 상황(Context)에 따라 다르게 수행되어야 합니다. 예를 들어, 전자상거래 사이트와 의료기기 소프트웨어의 테스트 접근법은 완전히 다릅니다.
7. Absence-of-errors fallacy.
   요구사항 자체가 잘못되었다면, 결함이 없는 소프트웨어를 만들어도 사용자의 필요를 충족시키지 못해 쓸모가 없습니다.

---

Chapter 2: Testing Throughout the Software Development Lifecycle

테스팅이 전체 개발 프로세스 안에서 어떻게 자리 잡고 수행되는지를 설명하는 챕터입니다.

2.1 Software Development Lifecycle Models (개발 생명주기 모델)

소프트웨어를 개발하는 방식(모델)에 따라 테스팅의 역할과 시점이 달라집니다.

모델	영문명	특징 및 테스팅 관점
순차 모델	Sequential Model	요구사항 분석 → 설계 → 개발 → 테스트 → 배포 순으로 진행됩니다. (예: 폭포수 모델, Waterfall). 테스트는 개발이 완료된 후반 단계에서 집중적으로 수행됩니다.
V-모델	V-Model	개발 단계와 테스트 단계를 V자 형태로 연결하여, 각 개발 단계마다 어떤 테스트가 연관되는지를 명확히 보여줍니다. **초기 테스트 설계(Early Test Design)**를 강조합니다.
반복적/점증적 모델	Iterative/Incremental Model	시스템을 작은 단위(증분, Increment)로 나누어 개발하고 테스트하는 과정을 반복(Iteration)합니다. **리그레션 테스팅(Regression Testing)**의 중요성이 매우 커집니다. (예: 애자일 모델)

v model

Iterative/Incremental Model

2.2 Test Levels (테스트 레벨) (암기)

테스트는 개발 과정에 따라 여러 단계(Level)로 나뉘어 수행됩니다.

테스트 레벨	영문명	테스트 대상	주요 목적
컴포넌트 테스팅	Component Testing	가장 작은 단위의 소프트웨어 (모듈, 유닛, 클래스). **유닛 테스트(Unit Test)**라고도 합니다.	개별 컴포넌트의 기능적/비기능적 동작을 검증합니다. 주로 개발자가 수행합니다.
통합 테스팅	Integration Testing	컴포넌트 간의 인터페이스 및 상호작용.	컴포넌트들이 결합되었을 때 올바르게 동작하는지 검증합니다.
시스템 테스팅	System Testing	전체 시스템 (End-to-End).	완전히 통합된 시스템이 전체 요구사항(기능/비기능)을 충족하는지 검증합니다.
인수 테스팅	Acceptance Testing	전체 시스템.	시스템이 사용자/고객의 요구와 비즈니스 요구사항을 만족하여 인수할 준비가 되었는지 검증합니다.

2.3 Test Types (테스트 유형)

테스트 유형은 "무엇을 테스트할 것인가?"라는 특정 목적에 따라 분류됩니다.

• 기능 테스팅 (Functional Testing): 시스템이 '무엇을 하는가'를 테스트합니다. 즉, 명시된 기능이 요구사항에 맞게 동작하는지 확인합니다.
• 비기능 테스팅 (Non-functional Testing): 시스템이 '얼마나 잘 동작하는가'를 테스트합니다. 성능, 사용성, 신뢰성, 보안성 등이 포함됩니다.
• 화이트박스 테스팅 (White-box Testing): 시스템의 내부 구조, 코드, 로직을 기반으로 테스트합니다. (Chapter 4에서 자세히 다룸)
• 확인 테스팅과 리그레션 테스팅 (Confirmation and Regression Testing) (암기)
  • 확인 테스팅 (Confirmation Testing / Re-testing): 수정된 결함이 정말로 해결되었는지를 확인하기 위해 다시 테스트하는 활동입니다.
  • 리그레션 테스팅 (Regression Testing): 코드 수정이나 새로운 기능 추가로 인해, 기존에 잘 동작하던 기능에 의도치 않은 문제가 생기지 않았는지 확인하는 테스트입니다.

2.4 Maintenance Testing (유지보수 테스팅)

소프트웨어가 배포되어 운영 중일 때 발생하는 변경사항에 대해 수행하는 테스트입니다.

• 유지보수 테스팅의 원인: 결함 수정, 환경 변화, 기능 개선 등
• 영향도 분석 (Impact Analysis): 변경이 시스템의 다른 부분에 어떤 영향을 미칠지 분석하는 것이 매우 중요하며, 이는 리그레션 테스트의 범위를 결정하는 데 도움을 줍니다.