Lesson 5: One Requirement = One Testable Thing – Avoiding the “Broken Telephone” in Specs

Introduction

“Why did this pass testing when it’s clearly broken?”
If you’ve ever had this thought while reviewing a feature that was “done,” only to realize something critical is missing—you’re not alone. And the problem might not be QA, devs, or test coverage.
It might be how the requirement was written in the first place.

If you’ve followed Lesson 1 through Lesson 4, by now you should be:
✅ Writing specs instead of keeping things in your head.
✅ Keeping everything in a single source of truth.
✅ Using consistent names.
✅ Using a single verb like “shall” to prevent confusion.

Now it’s time to tackle a more subtle, but deadly, problem: writing too much into a single requirement.

🔑 Key Takeaways from This Lesson

✅ One Requirement = One Testable Thing

When you combine multiple expectations into one sentence, things fall through the cracks. Dev teams and QA need clarity, not compound thoughts. If a requirement isn’t atomic and testable, it’s likely that something important won’t make it to the finish line.

Here’s what happens when you don’t follow this rule:

1️⃣ QA may test only the most obvious part of the requirement.
2️⃣ Dev may only implement part of the logic.
3️⃣ No one notices what’s missing — until the very end.
4️⃣ You get stuck validating features that “pass” but are actually broken.

🚨 Biggest Lesson: Every requirement should be testable on its own and represent a single unit of behavior.

💡 Pro Tip: Watch for “and” or “then” in your requirements
If your requirement has an “and,” it probably needs to be split.

💬 My Personal Experience: The Lost Email Confirmation

At one point, I wrote a seemingly fine requirement:

“User shall be able to update their profile and receive email confirmation and see it reflected on their dashboard.”

It looked okay at first. But then I traced what actually happened downstream.

Dev team rewrote it as:

“Implement profile update endpoint and ensure updated user data is displayed on the dashboard.”

QA wrote a test case that said:

“Change profile → Save → Check dashboard.”

So what got lost?
The email confirmation.
No one tested for it. No one built it.
And it was my fault — because I bundled too many things into one sentence.

🔥 Lesson Learned: Break it down into atomic requirements, like this:

1️⃣ The system shall allow the user to update their profile information.
2️⃣ The system shall send a confirmation email after a successful update.
3️⃣ The system shall display updated profile information on the user’s dashboard.

Now everyone knows what to build, what to test, and what to validate.

🛠 How You Can Apply This Today

✅ Simple 3-Step Action Plan:
1️⃣ Check your requirements for “and,” “then,” or compound logic.
2️⃣ Split each behavior into its own clear, testable sentence.
3️⃣ Ask yourself: Can this requirement pass or fail independently?

📌 Bonus Challenge: Find one overly complex requirement in your current backlog and rewrite it as 2–3 atomic ones. You’ll thank yourself later.

📌 Recap & What’s Next

📌 Key takeaway: If a requirement can’t be tested with a simple yes/no outcome, it needs to be rewritten. One thought. One test. No exceptions.

🎯 Next Lesson: Coming soon! Subscribe on YouTube to get notified when it drops.

🚀 Keep Learning with SpecWriting Academy

💡 Want to write better specs? Get access to more lessons and tools.
👉 Join the SwipeSpec Waiting List (Free Early Access!)

🎬 Watch the Next Lesson → Coming Soon