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.
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?"
8 Self-Check
Click each question to reveal the answer.
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.