Static vs Dynamic: Finding Bugs Without Running Code

Every technique in this chapter so far runs the software. But some of the cheapest bugs you'll ever catch are found with the product sitting completely still — by reading, reviewing, and questioning documents and code before anything executes. The industry splits all testing along this axis too: dynamic testing runs things; static testing examines them at rest. And here's the twist — you've already done static testing in this book, twice, without the name.

Blueprints explain why the still kind matters. Proofreading an architect's blueprint and stress-testing the finished building both find problems — but the blueprint reading catches the missing fire exit while it's a pencil line, years and millions cheaper than discovering it in a walkthrough of the built thing.

Dynamic Testing: Everything That Runs

Dynamic testing is the familiar kind: execute the product and observe. Every level from Topic 10, every smoke pass and regression run from Topic 13 — all dynamic, because the software is alive while you probe it. Dynamic testing's superpower is truth: whatever the documents claim, running code shows what actually happens. Its limit: it can only test what got built. A missing feature, an unhandled situation, a requirement nobody wrote — running the product can't reveal the absence of things.

Static Testing: Examining Artifacts at Rest

Static testing examines work products without executing them: requirements, user stories, designs, test cases, code read as text. The tools are human attention and good questions. When you dissected "the promo discount applies to long stays" in Chapter 2 — how long is long? what combines with what? — that was static testing of a requirement. When you asked in refinement whether a gift card can pay for part of a booking, that was static testing too. ISTQB is explicit on this: evaluating a work product is testing; execution is optional.

And this is where the absence-blindness of dynamic testing gets its cure: a review can notice what isn't there. No test run will ever fail because the story forgot to say what happens when Paylane is down — the scenario was never written, so no test was ever designed for it. A reviewer reading the story can ask "what if the payment provider is unreachable?" in five seconds. Reviews catch absent things; execution can't.

Reviews: a Spectrum of Rigor

Most static testing happens as reviews, and reviews come in weights. An informal review is a colleague reading your work and commenting — no ceremony, high value per minute; most reviews in the wild are this. A walkthrough has the author present the work while others question it — Petra walking the team through the gift-card story in refinement is exactly one. A technical review brings qualified peers to examine the work against standards, with findings recorded. And a formal inspection — the heavyweight — has defined roles, entry criteria, checklists, and metrics; you'll meet it in regulated industries, rarely elsewhere. The pattern: rigor rises with cost, and teams pick the weight the stakes deserve — the same right-sizing logic you'll see again with documentation in Chapter 5.

Where does a junior tester fit? In refinement walkthroughs from day one — your questions there are static testing in its natural habitat. And soon, reviewing test cases: a fresh pair of eyes on a colleague's checks is the cheapest quality upgrade a QA team can buy itself.

Static Analysis: the Tool-Shaped Cousin

One more term, for map completeness. Static analysis is software that reads code without running it, hunting known trouble patterns — a variable used before it's set, a branch that can never execute, style violations. It lives in the developers' world, runs automatically in their tools, and no, you won't operate it — but you'll hear "the static analyzer flagged it" in standups, and now the sentence parses: a robot proofreader for code, catching pattern-shaped mistakes while humans catch meaning-shaped ones. The division of labor matters: tools catch patterns; only humans catch a requirement that contradicts another requirement.

The Fifteen-Minute Institution

Back at Fernway, your gift-card question from Chapter 2 has quietly become an institution. Nadia noticed that one refinement question deleted an entire bug lifecycle, did the arithmetic, and made it official: every sprint now starts with a fifteen-minute story review, and you bring the checklist — is every criterion yes-or-no answerable? Is there a quality expectation (the Chapter 3 lesson)? What happens when the third party fails? What's missing? Fifteen minutes of static testing per sprint, catching bugs at the price of a sentence each. It is, per minute, the highest-value testing Fernway does — and nothing ever runs.