Most teams treat testing as execution. The teams that catch fewer regressions treat it as design.

TL;DR

• Most engineering teams treat test writing as an execution task: something to do once a feature is built, not something to think through before.
• A user story or ticket describes what a feature should do in general terms. It rarely specifies exact expected behavior across inputs, which is what a test actually needs.
• Skipping the design step means QA engineers write tests against their best guess of intended behavior, not a verified description of it.
• The cost of skipping test design shows up later, as ambiguous test failures nobody can resolve without going back to ask “what was this supposed to do.”
• A real test specification captures inputs, expected outputs, and edge cases as explicit decisions, made once, by someone who understands the feature.
• Treating test design as its own discipline, separate from and prior to test execution, is the difference between a suite that catches regressions and one that just runs.

A ticket lands in the sprint: “Add discount code support to checkout.” No acceptance criteria beyond that sentence. No note on what happens if two discount codes are entered. No note on whether a discount code can push the total below zero.

The QA engineer picks up the ticket after development is done. They write tests against their best guess: a valid code applies a discount, an invalid code shows an error. Reasonable guesses. Also, as it turns out, incomplete ones. Three weeks after release, a customer stacks two discount codes and gets a negative total. The test suite didn’t catch it, because nobody had decided, on paper, whether that combination was even supposed to be possible.

This isn’t a story about a careless QA engineer. It’s a story about a step that got skipped before the QA engineer ever touched the ticket.

Execution vs. design: the distinction most teams skip

Test execution is the part everyone thinks of when they hear “testing”: writing the actual test code, running it, checking the result. Test design is the step before that: deciding what should be tested, under what conditions, with what expected outcome, and why.

Most teams collapse these into one activity. A ticket gets picked up, and the same person who executes the test also decides, informally and in their head, what to test. There’s no separate artifact capturing that decision, no review step where someone else checks whether the decision was complete, and no record for the next person who needs to understand why a given test exists months later.

Treating design and execution as one blended activity works fine when the feature is simple and the person writing the test understands it deeply. It breaks down exactly where it matters most: complex business logic, edge cases that aren’t obvious from the ticket, and any feature where “what should happen” isn’t fully specified anywhere before the test gets written.

What a real test spec captures that a user story doesn’t

A user story answers “what should this feature let a user do.” A test specification answers a narrower, more precise question: for this exact set of inputs, what is the exact expected output, and which input combinations are explicitly in scope versus explicitly out of scope.

Take the discount code example. A complete test spec for that feature would state, as explicit decisions made before any code is tested: can two discount codes be applied at once (yes or no, decided by someone, not inferred); what happens if a discount would take the total below zero (floor at zero, error out, or some other defined behavior); what happens if a discount code expires mid-checkout (allowed to complete, blocked, defined either way).

None of these decisions require an engineer. They require someone who understands the business logic to make the decision once, write it down, and hand it to whoever builds the tests. That’s the artifact a user story usually doesn’t produce, and it’s precisely the artifact whose absence caused the negative-total bug.

Why skipping this step costs more later, not less

Skipping test design feels like it saves time, because it removes a step from the front of the process. It doesn’t remove the work. It moves the work downstream, to a moment when it’s more expensive to do.

When a test fails and nobody can say with confidence whether the failure represents a real bug or a test that encoded the wrong assumption, someone has to go find out, which usually means tracking down whoever built the feature and asking what it was actually supposed to do, weeks or months after they last thought about it. That conversation is the test-design step, happening late, under time pressure, with worse information than it would have had at the time the feature was built.

Multiply this across a codebase with hundreds of tests written against guessed rather than specified behavior, and a pattern emerges: an increasing share of test failures require investigation rather than a fix, because the test suite itself is ambiguous about what it was verifying. Teams in this state often describe their test suite as “noisy” or “not trustworthy,” without realizing the root cause is a design step that never happened.

What “verified spec first” actually looks like

The fix isn’t more documentation for its own sake. It’s a specific, lightweight practice: before any test gets written, someone who understands the feature’s intended behavior writes down the inputs, expected outputs, and edge-case decisions explicitly, and someone else reviews that spec for gaps before it becomes the basis for tests.

This doesn’t need to be a heavyweight process. For the discount code example, it’s three or four sentences: state whether stacking is allowed, state the floor behavior, state the expiry behavior. What matters isn’t the length of the document. It’s that the decisions get made once, explicitly, by someone with the right context, instead of being made implicitly and inconsistently by whoever happens to write the test.

Teams that adopt this practice describe a specific shift: test failures start meaning something again, because the failure points back to a documented expectation rather than an assumption nobody can trace. That shift, treating test design as a discipline with its own artifact and its own review step, is what separates a test suite that catches regressions from one that mostly just executes and hopes.

Sources

• ISTQB (International Software Testing Qualifications Board), foundational syllabus on test design techniques
• IEEE Software, research on requirements ambiguity and downstream defect cost
• Google Testing Blog, internal engineering writing on test design practices