The Quality Checklist for Any Text

🎯 Learning Objectives

By the end of this lesson, you will:

• Name and define all 5 quality criteria for requirements
• Apply each criterion to a sample requirement
• Identify which criterion is violated in a given example
• Know why testability is the most QA-specific criterion

📋 The Problem with "Looks Fine to Me"

Reading a document and thinking "seems okay" is not a review. It's a scan.

A professional static review applies specific, named criteria to each requirement. This makes your review:

• Repeatable — anyone can do it the same way
• Defensible — you can explain why something is a problem
• Actionable — the author knows exactly what to fix

Here are the 5 criteria. Memorize them. Use them every day.

✅ Criterion 1: Completeness

Definition: All necessary information is present. Nothing is missing.

How to check:

Ask yourself: "Is everything needed to implement and test this requirement included?"

✅ Pass example:

"When a user submits a login form with an invalid email format, the system shall display an error message: 'Please enter a valid email address.'"

❌ Fail example:

"When a user submits a login form with an error, the system shall show a message."

🔍 What's missing: Which errors trigger this? What does the message say?

✅ Criterion 2: Consistency

Definition: The requirement does not contradict other requirements or documents.

How to check:

Ask: "Does this conflict with anything else I've read?"

✅ Pass example:

All references to "the email field" across the spec use the same validation rules.

❌ Fail example:

• Section 3: "Email is optional"
• Section 8: "Email is required for account creation"

🔍 The fix: One section needs to align with the other. Find out which is correct.

✅ Criterion 3: Unambiguity

Definition: The requirement has exactly one valid interpretation. No one should be able to read it differently.

How to check:

Ask: "Could a developer and a tester read this and come to different conclusions about what 'correct' behavior looks like?"

✅ Pass example:

"The password must be 8–20 characters, containing at least one uppercase letter and one digit."

❌ Fail example:

"The password must be strong."

🔍 What's ambiguous: "Strong" means different things to different people. One developer writes a regex. Another adds a password-strength meter. Neither is "wrong" based on the spec.

✅ Criterion 4: Testability / Verifiability

Definition: It is possible to write a concrete test case that definitively passes or fails this requirement.

How to check:

Ask: "Can I write a test case for this right now? What are the inputs, the action, and the expected result?"

This is the most QA-specific criterion — you'll spot untestable requirements that others miss.

✅ Pass example:

"The page shall load within 2 seconds on a 4G connection."

Test case: Measure page load time on a throttled 4G network. Pass if ≤2000ms.

❌ Fail example:

"The UI shall be intuitive."

🔍 Why it fails: You cannot write a pass/fail test for "intuitive". Ask the author: what user behavior would prove the UI is intuitive? (If they say a usability test, that's a valid answer — write it down!)

✅ Criterion 5: Currency / Relevance

Definition: The requirement reflects the current state of the project and hasn't been superseded by a more recent decision.

How to check:

Ask: "Is this document up to date? Does it match recent decisions from meetings, emails, and Slack?"

✅ Pass example:

The spec has a "Last updated: 2025-04-10" timestamp and matches the decisions from the last sprint planning.

❌ Fail example:

"Users will log in with username and password." (But the team decided 2 weeks ago to switch to Google SSO.)

🔍 The fix: Update the document. Or at minimum, add a note: "Decision pending alignment with SSO migration plan."

🎯 Applying the Checklist

When you review any text, run it through all 5:

If the answer to any question is "no" or "I'm not sure" — that's a review comment. 📝

💡 Pro Tips

💡 Tip 1: When you find a violation, frame it as a question: "I couldn't determine the expected behavior when X — could we clarify?" This invites collaboration instead of defensiveness.

💡 Tip 2: The hardest criterion to check is currency. You need context. Attend sprint planning. Read the Slack channel. Know what decisions were made last week.

💡 Tip 3: "Intuitive", "fast", "beautiful", "user-friendly", "seamless" — these words almost always fail the testability criterion. Flag every one.

📋 Summary

The 5 quality criteria for any requirement:

1. Completeness — nothing is missing
2. Consistency — no contradictions with other requirements
3. Unambiguity — only one valid interpretation
4. Testability — a pass/fail test can be written
5. Currency — reflects current decisions

Apply all 5 every time. Make it a habit. Your future self will thank you. 🙏

Module 1 complete! You now have the vocabulary and the checklist. Module 2 is where we go hunting. 🔍