Static Testing
How to read requirements and participate in reviews. Find bugs in documents before they become bugs in code—the cheapest form of testing there is.
1 The Hook
A Wellington council IT project had a requirement that said "users should be able to search by suburb." Seems simple. But nobody specified what happens when a suburb has a macron—for example, Whanganui (with the ā) versus Wanganui (without it). Users typed one spelling, the system expected the other, and search results came back empty. The bug cost $50,000 to fix after release because it was missed during requirements review. A 30-minute static review would have caught the ambiguity before a single line of code was written.
2 The Rule
Static testing finds bugs in documents before they become bugs in code. It's the cheapest form of testing.
Every bug found in a requirements document costs pennies to fix. The same bug found after release costs thousands. Static testing is your first line of defence—and you don't need to write a single test case to do it.
3 The Analogy
Proofreading a contract before signing it.
Once signed, changes are expensive and painful. Lawyers review every clause before the ink dries. Static testing is the same: read the requirements carefully, question what is unclear, and fix it before the developers start building.
4 Watch Me Do It
Follow these five steps every time you review a requirement document.
- Check for completeness Who is involved? What must happen? When does it happen? Where in the system? Why is this needed? If any are missing, the requirement is incomplete.
- Check for ambiguity Look for vague words: fast, user-friendly, sometimes, as appropriate. These mean different things to different people. Ask for numbers or clear criteria.
- Check for consistency Does this requirement contradict another one? Does it use the same terms as the rest of the document? Inconsistency creates confusion and rework.
- Check for testability Can you write a test case for this? If you cannot figure out how to prove it works, the requirement is too vague to implement.
- Check for feasibility Is this realistic in the given time and budget? A requirement that demands real-time translation of every language on Earth may be technically possible but not feasible for a 3-month project.
"The system shall allow users to quickly book events. It should be user-friendly and support multiple payment options. Bookings must be confirmed fast. The admin can override bookings if needed."
| # | Problem | Issue |
|---|---|---|
| 1 | "quickly" | Ambiguous. How fast? 2 seconds? 10 seconds? |
| 2 | "user-friendly" | Subjective. Cannot be tested. Define criteria. |
| 3 | "multiple payment options" | Incomplete. Which ones? Credit card? Afterpay? POLi? |
| 4 | "fast" | Ambiguous. What is the maximum acceptable time? |
| 5 | "if needed" | Vague. When is it needed? Who decides? |
Five problems in three sentences. That is normal. Your job in static testing is to flag them so they get fixed before developers start coding.
Scenario 2: Contradiction between spec and design catches critical issue
A spec says users must have two-factor authentication (2FA) to log in. But the design mockups show no 2FA field on the login screen. This contradiction means either the design is incomplete or the spec is wrong. Either way, it must be resolved before coding starts.
| Document | Says | Status |
|---|---|---|
| Requirements spec | "All logins require 2FA" | Requirement |
| Design mockup | Shows email + password only | Missing feature |
| API contract | No 2FA endpoint defined | Incomplete |
| Issue found | Contradiction between three docs | Must fix |
This contradiction would have cost days of rework if discovered in testing. Static review caught it in planning. That's the whole point.
Senior engineer insight
Static testing changed for me the day I stopped reading documents to understand them and started reading them to break them. The Wellington suburb macron issue isn't a one-off — I've seen the same class of bug appear in NZ government portals, DHB patient systems, and council asset registers, always because reviewers were reading for meaning rather than hunting for gaps. What shifted my thinking: treating a requirements document exactly like a test case — every sentence is an assertion, and your job is to find the one that has no way of being verified.
Most common Grad mistake: annotating what a requirement says instead of flagging what it doesn't say — completeness misses are consistently costlier than ambiguity misses.
From the field
On a data migration project for a NZ local government, the team assumed the technical spec was final — it had been through two rounds of sign-off. When a tester walked through the spec against the source data dictionary, she found that seven field-mapping rules contained the phrase "as per existing logic," but the legacy system had no documented logic — it was all tribal knowledge in the heads of two people who had left the organisation. The team had been about to start coding from a spec that referenced rules that didn't exist. A two-day static review surfaced eleven such references. The lesson that generalises: sign-off confirms that stakeholders have read a document, not that the document is complete — always cross-check specs against their source artefacts, not just against each other.
5 When to Use It / When NOT to Use It
✅ Do it when...
- A requirements document is published
- A user story is written
- Design mockups are shared
- API contracts are drafted
❌ Skip it when...
- The code is already written and deployed
- You need to verify runtime behaviour
- You are checking performance under load
Before you apply this technique, ask:
- Do you have access to the requirements or design documents?
- Do you have time to review before development starts?
- Is the document complete enough to analyse, or still a sketch?
- Is there a clear owner (PM, architect) who can clarify ambiguities?
6 Common Mistakes
🚫 Reviews are boring meetings
I used to think: Requirements reviews are dull meetings where seniors talk.
Actually: A 30-minute review can prevent weeks of rework. Every ambiguous word you catch saves money and stress later.
🚫 I need to be senior to review requirements
I used to think: Only seniors can spot problems in requirements.
Actually: Beginners ask the best "dumb questions" that expose assumptions. If you don't understand it, the requirement is unclear.
🚫 Finding problems makes me negative
I used to think: Pointing out flaws in requirements makes me look critical.
Actually: It makes you valuable. The team would rather fix a wording problem now than a production bug at 2am.
🚫 Reviewing obvious typos only
I used to think: Static testing is just spell-checking.
Actually: Spell-checking is 5% of static testing. The real work is finding missing requirements, ambiguous acceptance criteria, and contradictions between design and spec. Look for logic, not just grammar.
When this technique fails
Static testing fails when you review a document that is incomplete, has no owner to clarify ambiguities, or won't be changed anyway. Also fails when you review too late—after development has already started. Static testing only works if teams actually use the feedback. If your review is ignored, you're wasting time.
7 Now You Try
Scenario: You are reviewing a user story for an NZ medical booking app. Identify 3 problems in this requirement:
"As a patient, I want to book an appointment so that I can see a doctor."
Three problems to flag:
| # | Problem | Why it matters |
|---|---|---|
| 1 | No mention of cancellation | Can patients cancel? How? What notice is required? |
| 2 | No time constraints | How far ahead can they book? Same-day? 6 months? |
| 3 | No mention of emergency prioritisation | What happens if a patient needs urgent care? |
Tip: Even a simple-sounding story hides gaps. Ask "what if?" and "what about?"
Why teams fail here
- Reviews become rubber-stamp ceremonies — stakeholders sign off without reading, and testers treat sign-off as permission to stop asking questions.
- Feedback lands too late — static review comments raised after development has started are almost always deprioritised as "nice to have for v2," then never fixed.
- Issues are logged but not owned — a review that produces a list with no assigned action owner and no follow-up meeting achieves nothing; ambiguities simply carry forward into code.
- Testers confine themselves to their own section — on NZ government projects with large technical specifications, testers review only the functional chapters and miss contradictions between functional requirements and the architectural or security annexes.
Key takeaway
The cheapest bug you will ever fix is the one you find in a document — the professional judgment is to insist on reviewing that document before the first line of code is written, even when the team is already in a hurry.
8 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Static Testing at the Grad level.
Q1. What is static testing, and what does it find that dynamic testing cannot?
Strong answer: Static testing examines artefacts (requirements, design documents, code, test cases) without executing the software. It finds defects in the specification — ambiguous requirements, missing edge cases, conflicting rules, unreviewable acceptance criteria — before any code is written. Dynamic testing can only find defects in running software. A requirement that says "the system shall be fast" cannot be tested dynamically without first asking "how fast?" — but static testing catches this ambiguity at the requirements stage.
Q2. You are reviewing a colleague's test cases. What would you look for in a good test case?
Strong answer: A good test case has: a clear, descriptive title (what is being tested and under what conditions), explicit preconditions (what state the system must be in before starting), numbered step-by-step actions that can be followed exactly, a specific expected result for each step or overall (not "it should work"), and enough detail to be reproducible by anyone on the team. I also check: does it test one thing? Is the expected result verifiable? Would I know pass from fail unambiguously?
Q3. What is a code review, and why should testers care about it?
Strong answer: A code review is when one or more developers read another developer's code before it is merged, looking for bugs, security issues, style violations, and maintainability problems. Testers care because code reviews catch defects before testing begins — finding a bug in review is faster and cheaper than finding it during testing. Testers can contribute to code reviews by checking whether the code includes the edge cases from the acceptance criteria, whether error handling is complete, and whether the code is testable (has clear inputs and outputs, not tightly coupled to dependencies).
Q1. What type of testing reviews documents without executing code?
Static testing. It examines requirements, designs, and code without running anything.
Q2. Which words in a requirement are red flags for ambiguity?
Vague terms like fast, user-friendly, sometimes, and as appropriate. They mean different things to different people and cannot be tested.
Q3. Why is static testing considered the cheapest form of testing?
Because it finds bugs in documents before code is written. Fixing a wording issue costs almost nothing compared to fixing a production defect.