Static Testing

Chapter 3 in the CTFL exam

Exam questions

4 / 40

Share of exam

10%

Highest K-level

K2

Glossary terms

18

Chapter 3 is K1 and K2 only. The review process activities and the roles within a review are the most reliably examined content.

What this chapter covers

Chapter 3 covers everything you can evaluate without executing code. It is 4 of 40 questions, and it is the chapter where candidates most often lose marks on the review process — the activities and the roles are precisely defined and precisely tested.

Static testing examines work products without running them. That includes requirements, user stories, acceptance criteria, architecture and design documents, code, test plans and test cases, and even contracts and models. Because it applies to work products that exist long before executable code, static testing is the primary mechanism for finding defects early — which is where the cost-of-fix argument from chapter 1 pays off.

The value of static testing is in detecting defects rather than failures. A review finds the defect directly in the work product; dynamic testing can only observe a failure and then requires debugging to locate the underlying defect. Static testing also finds classes of problem dynamic testing cannot reach at all: requirement ambiguities, contradictions, omissions, inconsistencies, and untestable statements. Static analysis tools additionally detect coding standard violations, control and data flow anomalies, and security vulnerabilities.

Early and frequent stakeholder feedback is the second half of the chapter's rationale. Involving stakeholders early communicates what is being built and surfaces misunderstandings while they are still cheap, reducing the risk of delivering something that satisfies the specification but not the need.

The review process has five activities: planning (defining scope, criteria, effort, roles), review initiation (distributing materials, explaining objectives), individual review (each reviewer examines the product and logs anomalies), issue communication and analysis (anomalies are discussed, given a status, and ownership assigned), and fixing and reporting (defects are corrected and exit criteria evaluated).

Five roles are defined: the author owns the work product; the management role plans the review; the facilitator (moderator) runs the meeting and mediates; the review leader takes overall responsibility and decides who participates; and the reviewers identify anomalies. One person may hold several roles. Review types run from informal review through walkthrough (led by the author) and technical review (led by a trained facilitator, performed by technical peers) to inspection — the most formal, metric-driven type, led by a facilitator with defined roles and formal exit criteria.

CTFL v4.0 syllabus outline

1. 3.1 Static Testing Basics

   • Work Products Examinable by Static Testing
   • Value of Static Testing
   • Static Testing vs Dynamic Testing

2. 3.2 Feedback and Review Process

   • Benefits of Early and Frequent Stakeholder Feedback
   • Review Process Activities
   • Roles and Responsibilities in Reviews
   • Review Types
   • Success Factors for Reviews

Highest-value terms in this chapter

Start here if you are short on time.

• static testing
• static analysis
• review
• walkthrough
• technical review
• inspection
• informal review
• moderator
• reviewer

Common exam traps

• ⚠️Confusing walkthrough with inspection. A walkthrough is author-led; an inspection is formal, facilitator-led, and metrics-driven.
• ⚠️Saying static testing finds failures. It finds defects directly — failures require execution.
• ⚠️Forgetting that static analysis is a tool activity and does not require reviewers at all.
• ⚠️Assuming the facilitator and the author can never be the same person; the syllabus allows roles to combine.