ISTQB 4.0 Foundation Level [3장] 전체 요약 정리

정적 테스팅은 '코드를 실행하지 않고' 결함을 찾는 모든 활동을 의미하며, "Shift Left" 사상의 핵심입니다. 즉, 개발 초기에 결함을 발견하여 수정 비용을 극적으로 낮추는 것을 목표로 합니다.

Basics of Static Testing (정적 테스팅의 기초)

Static Testing (정적 테스팅)이란 소프트웨어 개발 생명주기의 초기에, 코드를 포함한 프로젝트 문서(Work Products)를 실행하지 않고 분석하여 결함을 찾아내는 테스트 활동입니다.

Dynamic Testing (동적 테스팅)이 소프트웨어를 직접 실행하며 '실패(Failure)'를 찾는 과정이라면, 정적 테스팅은 문서를 검토하거나 코드를 분석하여 '결함(Defect)' 그 자체를 찾아내는 예방적 활동입니다.

• 정적 테스팅으로 검토할 수 있는 산출물 (Work Products):
  • 요구사항 명세서 (Requirements specifications)
  • 설계 명세서 (Design specifications)
  • 코드 (Code)
  • 테스트 계획서 (Test plans)
  • 사용자 스토리 및 인수 조건 (User stories and acceptance criteria)

The Review Process (리뷰 프로세스)

정적 테스팅의 핵심 활동은 **리뷰(Review)**입니다. ISTQB에서는 공식적인 리뷰 프로세스를 5단계로 정의하고 있습니다.

• Stages of a Formal Review (공식 리뷰의 5단계) (암기)

단계	영문명	주요 활동
1. Planning	계획	리뷰의 목적, 범위, 문서, 역할, 일정, 진입/종료 조건 등을 정의합니다.
2. Initiate Review	검토 착수	문서를 배포하고, 리뷰의 목적과 프로세스에 대해 설명하는 킥오프 미팅을 진행합니다.
3. Individual Review	개별 검토	각 리뷰어(검토자)가 할당된 문서를 개별적으로 검토하며 잠재적 결함이나 질문을 기록합니다.
4. Issue Communication and Analysis	이슈 소통 및 분석	리뷰 미팅을 통해 발견된 잠재적 결함을 논의하고, 수정이 필요한 결함으로 확정합니다.
5. Fixing and Reporting	수정 및 보고	작성자(Author)가 합의된 결함을 수정하고, 리뷰 리더는 종료 조건을 확인한 후 리뷰 결과를 보고합니다.

• Roles and Responsibilities in a Formal Review (공식 리뷰의 역할 및 책임) (암기)

역할	역할	주요 책임
Author	작성자	리뷰 대상 문서를 작성하고, 발견된 결함을 수정합니다.
Management	관리자	리뷰 활동을 위한 예산과 시간을 확보하고, 리뷰의 성공에 대한 책임을 집니다.
Facilitator (Moderator)	촉진자 (사회자)	리뷰 미팅을 이끌며, 모든 참가자가 원활하게 참여하도록 돕습니다. 객관성과 효율성을 유지하는 중요한 역할입니다.
Reviewer	검토자	자신의 전문 분야 관점에서 문서를 검토하여 잠재적인 결함을 식별합니다.
Scribe (Recorder)	서기 (기록자)	리뷰 미팅 동안 발견된 결함과 결정 사항을 문서화합니다.

Review Types (리뷰 유형)

리뷰는 형식성의 수준에 따라 여러 유형으로 나뉩니다. **인스펙션(Inspection)**이 가장 형식적인 리뷰입니다.

• Comparison of Review Types (리뷰 유형 비교) (암기)

리뷰 유형	한국어	특징 및 목적
Informal Review	비공식 리뷰	정해진 절차 없이 진행되며, 문서화가 필수는 아닙니다. (예: 2명이 짝을 이뤄 검토하는 Pair Review)
Walkthrough	워크스루	작성자(Author)가 문서를 직접 설명하며 동료들로부터 피드백을 받고 아이디어를 공유하는 협업 미팅입니다.
Technical Review	기술 리뷰	기술 전문가들이 모여 기술적인 내용의 정확성을 검토하고 대안을 논의합니다. 합의(Consensus)를 도출하는 것이 중요합니다.
Inspection	인스펙션	가장 형식적인(Formal) 리뷰 유형입니다. 정해진 역할과 절차를 엄격히 따르며, 결함을 찾는 것이 주된 목표입니다. 촉진자(Facilitator)의 역할이 매우 중요합니다.

Feature	Informal Review	Walkthrough	Technical Review	Inspection
Formality	Very Low	Low	Medium	Very High
Main Goal / Objective	Quick check, idea sharing	Learning, understanding, finding defects	Gaining consensus, discussing alternatives, finding defects	Finding defects (Primary)
Leader	Author	Author	Moderator or a technical expert	Trained Moderator
Formal Process	❌ No	❌ Not required	❔ Optional	✅ Yes, required
Defined Roles	❌ No	❔ Optional	✅ Yes	✅ Yes, required & well-defined
Documentation	❌ No	❔ Simple notes (informal)	✅ Yes (e.g., issue list)	✅ Formal (e.g., review report)
Metrics Collection	❌ No	❌ No	❔ Optional	✅ Yes, collected & used

• Inspection: 
  • The most formal review type. If you see keywords like "Trained Moderator", "Formal Process", "Entry/Exit Criteria", and "Metrics", the answer is almost always Inspection.
  • (가장 공식적인 리뷰 유형. '훈련된 사회자', '공식 절차', '진입/종류 기준', '측정 지표' 같은 키워드가 보이면 거의 항상 정답은 Inspection입니다.)
• Walkthrough: 
  • The primary goal is often learning and knowledge transfer. It is led by the Author.
  • (주요 목표는 종종 '학습과 지식 전달'입니다. '작성자'가 주도합니다.)
• Technical Review: 
  • The main goal is to reach a consensus on a technical matter. It is often led by peers and technical experts.
  • (주요 목표는 기술적인 문제에 대해 '합의'에 도달하는 것입니다. 동료나 기술 전문가들이 주도하는 경우가 많습니다.)
• Informal Review: 
  • No formal process. Keywords like "Pair Programming" or a quick check by a colleague are examples of this.
  • (공식적인 절차가 없습니다. '페어 프로그래밍'이나 동료의 간단한 확인 같은 것이 예시입니다.)

 

---

 

Static Analysis by Tools (도구를 이용한 정적 분석)

Static Analysis (정적 분석)는 개발자가 작성한 코드를 실행하지 않고, 전용 도구(Tool)를 사용하여 분석하는 활동입니다. 컴파일러도 일종의 정적 분석 도구로 볼 수 있습니다.

• 정적 분석 도구가 발견할 수 있는 결함 유형:
  • 코딩 표준 위반 (Violations of coding standards)
  • 코드 복잡도 (Code complexity)가 높은 부분
  • 정의되었지만 사용되지 않는 변수 (Unused variables)
  • 보안 취약점 (Security vulnerabilities) (예: SQL 인젝션)
  • 데이터 흐름 및 제어 흐름 이상 (Data and control flow anomalies)
• Value of Static Analysis (정적 분석의 가치):
  • 개발 초기에 결함을 신속하게 발견할 수 있습니다.
  • 사람이 놓치기 쉬운 패턴의 오류를 효과적으로 찾아냅니다.
  • 코드 품질과 유지보수성을 향상시키는 데 기여합니다.

(주의점) 정적 분석 도구는 실제 결함이 아닌 것을 결함으로 보고하는 **거짓 경고(False positives)**를 많이 발생시킬 수 있습니다. 따라서 분석 결과를 검토하고 실제 결함을 선별하는 과정이 필요합니다.