Static Testing
Core concepts
Static testing examines work products without executing them. It includes reviews and static analysis. Work products include requirements, designs, code, test plans, user stories, and contractual documents. Static testing finds defects early, before dynamic testing can observe failures. Static analysis tools check code for violations such as unused variables, unreachable code, insecure patterns, or complexity.
A formal review follows activities: planning, initiation, individual review, communication and analysis, and fixing and reporting. Roles include manager (decides what and when), moderator (leads), author (creates and fixes), reviewers (inspect), and scribe (records). Review types range from informal to walkthrough (author-led, knowledge sharing), technical review (peer review of technical content), and inspection (formal, moderated, with defined roles and metrics). Success depends on clear objectives, small review scope, trained participants, checklists, and a safe culture.
Traps
Static testing does not find failures because nothing executes; it finds defects. Inspection is the most formal type, not a walkthrough. A technical review is not necessarily led by the author. Reviews are not only meetings; individual preparation is essential. Static analysis is not a substitute for dynamic testing.
Worked example
A reviewer finds the requirement "the system shall respond quickly." This is a defect (ambiguity) in a work product. No execution occurs, so it is static testing. Rewriting it as "95% of searches complete within 2 seconds" makes it testable.
Rule of thumb: no execution means static; execution means dynamic.