Finding a defect before execution costs a fraction of finding it after release
A requirement that says "the system shall process orders quickly" is ambiguous. If a developer implements it to mean 10 seconds and the business expected 1 second, that misunderstanding could take weeks to undo after development. A 10-minute review at the requirements stage would have caught it for free.
Static testing is the practice of evaluating work products without executing them. It is one of the most cost-effective quality activities available — and one of the most underused.
// example: amazon — catching ambiguity before a single line of code
Static Testing — CTFL 4.0.1
Static testing examines work products without executing the software. It can be applied to virtually any written artefact produced during the software lifecycle.
Work products that can be statically tested
- Requirements specifications and user stories
- Architecture and design documents
- Source code and configuration files
- Test plans, test cases, and test scripts
- Project plans and risk analyses
- Contracts and service level agreements
Two forms of static testing
Reviews — human-led evaluation of work products. Team members examine the artefact and identify defects, ambiguities, and improvements. Ranges from informal peer checks to formal inspections.
Static analysis — tool-driven examination of code or models for patterns, violations, and potential defects without execution. Examples: linting, security scanners, complexity metrics.
Benefits of static testing
- Detects defects before they propagate to later phases where they cost more to fix
- Identifies ambiguities, inconsistencies, and omissions in requirements
- Improves the quality of documentation and code structure
- Builds shared understanding across the team
// tip: Exam Tip: Static testing can find defect types that dynamic testing cannot — for example, deviations from standards, requirement ambiguities, and unreachable code paths. The exam often contrasts what each finds. Remember: dynamic testing finds failures during execution; static testing finds defects in work products before execution.
Defects Found by Static Testing at Each Phase
| Phase | Work Product Reviewed | Typical Defects Found |
|---|---|---|
| Requirements | Requirement spec, user stories | Ambiguous terms, missing acceptance criteria, contradictory rules, untestable requirements |
| Design | Architecture diagrams, API specs | Missing interfaces, circular dependencies, security flaws in data flow |
| Coding | Source code, configuration | Syntax errors, unreachable code, security vulnerabilities, coding standard violations |
| Testing | Test plans, test cases | Missing test conditions, incorrect expected results, untestable test cases |
Cost principle: IBM research and CTFL both cite that defects found in requirements cost 10–100x less to fix than the same defect found after release. Early static testing is the single most cost-effective quality activity.
Requirements Phase
// Work products reviewed
// Typical defects found
Ambiguous terms ("quickly", "user-friendly")
Missing acceptance criteria
Contradictory business rules
Untestable requirements ("system shall be fast")
// Cost to fix if found here
1x (baseline)
IBM research + CTFL: defects found in requirements cost 10–100x less than post-release
// Exam tip
Static testing can find defects that dynamic testing cannot — like requirement ambiguities, unreachable code, and standard violations. The exam often contrasts what each technique finds.
Static Testing vs Dynamic Testing
| Aspect | Static Testing | Dynamic Testing |
|---|---|---|
| Requires execution | No — evaluates work products directly | Yes — software must run |
| Applied to | Any written artefact (requirements, code, test cases) | Executable software only |
| Finds | Defects, ambiguities, standard violations, dead code | Failures, performance issues, runtime errors |
| When | Any phase — as early as requirements | After software is executable |
| Cost to fix defects | Very low — change a document or few lines | Higher — code must be changed, retested |
| Examples | Requirements review, code inspection, linting | Functional tests, performance tests, exploratory testing |
// warning: Exam Trap: "Static testing only applies to code." This is false. Static testing applies to any work product — requirements, designs, test plans, user stories, and contracts. Code is just one of many targets. The exam frequently asks about static testing of non-code artefacts.
Exam Practice Questions
// ctfl 4.0.1 style — select an answer to reveal explanation