tatic Testing vs Dynamic Testing
1. Introduction
Static testing and dynamic testing are both essential, but they are used to find different types of defects.
This question checks whether you can identify which defects are most easily found without executing the code.
정적 테스트와 동적 테스트는 각각 다른 유형의 결함을 찾는 데 사용됩니다. 이 문제는 프로그램을 실행하지 않고 가장 쉽게 발견할 수 있는 결함이 무엇인지 묻습니다.
2. Key Concept: Static vs Dynamic Testing
A quick comparison:
- Static testing: reviews and analysis without executing code (e.g., reviews, inspections, static analysis)
- Dynamic testing: execution of the software to observe behavior (e.g., functional testing, performance testing)
간단히 정리하면:
- 정적 테스트: 코드/문서 실행 없이 결함 탐지
- 동적 테스트: 프로그램을 실행하여 결함 탐지
3. Practice Question
❓ Question
Given the following example defects:
- Two different parts of the design specification disagree due to the complexity of the design
- A response time is too long and so makes users lose patience
- A path in the code cannot be reached during execution
- A variable is declared but never subsequently used in the program
- The amount of memory needed by the program to generate a report is too high
Which of the following BEST identifies example defects that could be found by static testing (rather than dynamic testing)?
- a) ii, v
- b) iii, v
- c) i, ii, iv
- d) i, iii, iv
✅ Correct Answer: d)
4. Explanation (EN / KR)
✔ i) Inconsistent design specification — Static testing
This is a specification defect. Inconsistencies, contradictions, ambiguities, and omissions in documents are most easily found through reviews and inspections.
설계 명세 간 불일치는 전형적인 명세 결함입니다. 리뷰와 인스펙션 같은 정적 테스트로 가장 쉽게 발견됩니다.
✔ iii) Unreachable code path — Static testing
Unreachable code is a coding defect. Static analysis tools can detect unreachable or dead code without execution.
실행될 수 없는 코드 경로는 대표적인 코딩 결함입니다. 정적 분석 도구로 실행 없이 탐지할 수 있습니다.
✔ iv) Declared but unused variable — Static testing
Unused variables are another example of coding defects. They are easily detected during code reviews or static analysis.
선언만 되고 사용되지 않는 변수 역시 정적 분석이나 코드 리뷰로 쉽게 찾을 수 있는 결함입니다.
❌ ii) Slow response time — Dynamic testing
Response time issues are performance defects. They require executing the software and measuring behavior.
응답 시간이 느린 문제는 성능 결함으로, 프로그램을 실행해야만 확인할 수 있습니다.
❌ v) Excessive memory usage — Dynamic testing
High memory consumption is also a performance-related defect and must be detected by running the program.
메모리 사용량 과다는 실행 중에만 측정 가능한 동적 테스트 대상 결함입니다.
5. Summary Table
| Defect | Testing Type | Reason | 한글 요약 |
|---|---|---|---|
| i) Spec inconsistency | Static | Document review | 명세 리뷰로 탐지 |
| iii) Unreachable code | Static | Static analysis | 정적 분석으로 탐지 |
| iv) Unused variable | Static | Code review / analysis | 코드 리뷰로 탐지 |
| ii) Slow response | Dynamic | Execution required | 실행 필요 |
| v) High memory usage | Dynamic | Runtime measurement | 실행 중 측정 |
6. Final Takeaway
For ISTQB exams, remember:
Static testing finds defects in documents and code structure without execution.
시험에서는 다음 문장으로 정리하세요.
정적 테스트는 실행 없이 명세·구조·코딩 결함을 찾는다.
Related: More ISTQB Posts | Next Question