User story testing depends on functional testability: the tester has all the information needed to test with purpose. User stories are planning artifacts, not lasting requirements documents. Acceptance criteria capture what has to work in a way that can be demonstrated. Additional specifications such as decision tables or flowcharts are added only where they actually help the team.
Key Takeaways
- User stories are planning artifacts, not requirements: they can be thrown away after the sprint, because lasting documentation has to be maintained somewhere else.
- Many projects underuse acceptance criteria by filling them with extra requirements instead of the concrete examples the product owner wants to see in the demo before accepting the story.
- The strongest lever for functional testability is one question in refinement: which specification would help the team develop and test this story in the sprint?
- Every user story can be covered by three test activities: acceptance tests always, exploratory testing always, systematic test design techniques only when the risk calls for them.
- Many teams dropped requirements engineering when they moved to agile, even though formal methods such as decision tables or flowcharts do not conflict with agile principles.
User Stories Are Work Packages, Not Requirements
User story testing starts with a distinction many teams skip: a user story is not a requirement. It is a planning artifact that a team can pin to a board, estimate and pull through a sprint. Build on the wrong assumption here and everything after it wobbles.
That leads to an uncomfortable consequence. Stories are not meant to be lasting requirements documentation. Once the iteration is done, you can throw them away. This is exactly where many teams go wrong, because they use the story as long-term storage for knowledge that belongs somewhere else.
Christian Brandes sees a bigger pattern behind this mix-up. When teams moved to agile models, requirements engineering often went overboard, usually with the argument: “We don’t need requirements anymore, we have stories now.” That equation does not survive contact with real projects.
Responsibility then tends to drift quietly to the product owner. But very few product owners are trained requirements engineers. The result is a gap between requirements and testing that nobody explicitly fills.
Functional vs. Technical Testability
Functional testability means that whoever tests a story has all the information they need beyond their own intuition. That is the central question, and it decides how much a story is worth for testing.
Technical testability is a separate matter. It asks whether tests can be run at all, that is, whether you control the test environment, the date and the time. Both matter, but they solve different problems.
In practice, everyone nods along to the “testable” in the INVEST criteria. Ask how testability is actually achieved, though, and the room often goes quiet. Brandes compares it to the concept of quality: hard to define, but you notice right away when it’s missing.
The practical fix for that silence is simple. If a story contains business logic, it comes with a specification the tester does not have to hunt down first. If all it says is “check discount calculation”, the team needs to know what “check” means in this case.
Acceptance Criteria Are Underused in Many Projects
Acceptance criteria are not additional requirements, even if many projects treat them that way. They answer a different question: what has to be shown to work at the end so the product owner can accept the story with a clear conscience?
The clean method behind this is Specification by Example as described by Gojko Adzic. The product owner writes down, as acceptance criteria, the concrete examples they want to see in the demo to be convinced. Even in agile, acceptance is a matter of trust, and these examples are what build it.
That logic does not fit into a classic requirement. It belongs in the acceptance criteria section, and there it is a problem that is already solved.
Acceptance criteria have one more advantage for testing: they are practically begging to be automated. Whatever matters so much to the product owner that they want it demonstrated, you as a tester will want to check again and again.
The Story as a Container: The Middle Section Makes the Difference
A workable story has three zones. The name describes the problem space using the familiar template: as a role, I want functionality so that I achieve business value. The acceptance criteria describe what has to work, demonstrably, at the end.
In between sits an optional section, the story specification or story description. If the team says “we’ve done this ten times already”, it stays empty. If the team needs a hand-drawn sketch, a decision table or a link to details, that is where it goes.
Many tools nudge teams into a lopsided split here. The user story template ends up in the description, and the name shrinks to two words. It works better to keep the name as a meaningful short title and reserve the description for all the detail that helps the team.
Risk notes belong in this section too. When the product owner marks the one detail where a bug must not happen under any circumstances, that is a valuable signal for testing.
How a Team Decides Which Specification It Really Needs
The strongest lever is one question in refinement. After presenting the story, the product owner asks the team: which specification would help you develop and test this in the sprint?
“Help” is the yardstick. What gets documented is whatever is useful to someone, not everything and not nothing. That also clears up the supposed contradiction in “communication over documentation”: the “over” does not forbid documentation, it just puts the conversation first.
The content decides the format. Business logic fits into a decision table. A process with variants fits into a flowchart, BPMN or UML, without anyone having to call it that.
Brandes explicitly warns against one thing: forcing every example into Gherkin syntax just because a team has switched to BDD. Where the format doesn’t fit, a sketch, a value range or a table people can actually read is often enough.
“We only document what has value or use for someone. If it helps the team, we do it in agile, too.”
(Christian Brandes)
Lasting Documentation Lives Next to the Story, Not in It
A specification that is meant to last does not live in the story. It lives in product documentation that grows alongside the product, iteration by iteration.
Brandes describes a split structure of target and actual, both organized identically by business components. If the team says a specification would help, it is documented in the target area. The story only points to it: you’ll find the details here.
Once the feature is developed and tested, the specification moves to the actual state. There is hardly anything left to do, because the documentation work was done up front. The story itself is thrown away afterwards.
This also solves a recurring traceability issue. Test cases are not linked to the story, which disappears after the sprint, but to the specification and later to the product documentation. That creates a traceable trail without turning short-lived work packages into trace anchors.
| Artifact | Lifetime | Purpose |
|---|---|---|
| User story | Only for the sprint, then disposable | Planning, estimation, work package |
| Specification (target) | Grows with every iteration | Detailed knowledge that helps the team |
| Product documentation (actual) | Permanent | Trace anchor for test cases, product knowledge |
Non-Functional Requirements Need No Special Route
Non-functional requirements need nothing new. The story has room for specifications, so that is where you specify performance, security or other quality characteristics.
Requirements engineering offers tools here as well. Instead of “the system must be fast”, a sentence template produces a statement you can verify: in 99 percent of cases, under defined conditions, this function must respond within a given amount of time.
The product owner decides how visible the topic becomes. If it matters enough, they raise it as an acceptance criterion and ask to see it demonstrated. Otherwise they rely on the team’s system testing activities.
Triple X: A Lightweight Strategy for User Story Testing
Once a story is functionally testable, three activities fall straight out of its structure. Brandes sums them up as the Triple X strategy: Acceptance, Exploratory, Risks.
- Acceptance: The acceptance criteria are always tested and always automated. They are what absolutely has to work.
- Exploratory: Every story gets exploratory testing, based on the criteria, the specification or intuition. The goal is fast feedback, early bug detection and understanding the system.
- Risks: Optionally, a systematic test design technique is added when risk and specification justify it. Here the tester asks for a test basis, such as a decision table.
This order turns something around. Acceptance and exploratory tests always run, systematic techniques only when they help. Systematic testing becomes a complement to experience-based testing, while the Foundation Level puts it exactly the other way around.
Model-Based Testing Fits Agile, Too
Model-based testing generates test artifacts from formal models such as UML or BPMN. The key distinction is between system models and test models.
System models describe the system and often come from the requirements engineer, for example as a use case model or a class diagram. A test model looks similar but describes how the system is tested. It belongs to testing and can be enriched with test decisions and concrete test data that have no place in a system specification.
Path generators can derive abstract tests from system models, which takes a lot of tedious work off your hands. Test models can even produce concrete tests. When a risky story comes with a model like that, the bridge to the test strategy is already in place.
Brandes puts the fact that model-based testing rarely takes hold in agile down to a double misunderstanding. Models are seen as mere documentation, and documentation is seen as optional in agile. Both assumptions are wrong. Where a model helps you test the beast thoroughly, it belongs in the process.
Frequently Asked Questions
Are user stories a substitute for requirements engineering?
No. A user story is a planning artifact: something a team posts on a board, estimates, and takes through a sprint. It is not intended to permanently store requirements information. When switching to agile models, requirements engineering was often phased out on the grounds that “we have stories now,” and responsibility tacitly shifts to the Product Owner, who is usually not a trained requirements engineer.
How can you tell if a user story isn’t functionally testable?
It contains business logic but no accompanying specification. If a story simply says “Check discount calculation,” the team lacks the information needed to know what “check” actually means in this context. In practice, everyone nods in agreement when the “testable” INVEST criterion is mentioned, but when asked how testability is actually achieved, there is often silence. Functional testability means: The tester has all the information they need in addition to their intuition.
Are acceptance criteria additional requirements for the software?
No, even though they’re treated as such in many projects. They answer a different question: What must demonstrably work for the Product Owner to accept the story with a clear conscience? The method behind this is “Specification by Example” as described by Gojko Adzic. The Product Owner writes down the specific examples they want to see in the demo. Acceptance remains a matter of trust, even in Agile.
How much documentation is appropriate in an Agile team?
You document what is useful to someone: not everything, and not nothing. The most powerful tool is a question during refinement: What specification would help you develop and perform testing on this during the sprint? If the team says, “We’ve already done that ten times,” nothing will come of it. The “over” in “Communication over Documentation” doesn’t prohibit documentation; it simply prioritizes conversation.
Why is it worth automating acceptance criteria?
As a tester, you’ll want to verify again and again whatever is so important to the Product Owner that they want to see it demonstrated. Acceptance criteria describe exactly what absolutely must work, making them the natural candidate for automation. In the Triple X strategy (Acceptance, Exploratory, Risks), they are therefore always tested and always automated.
Where are test cases anchored if user stories are discarded after the sprint?
In the specification and later in the product documentation, not in the story itself. A proven approach is a separate structure consisting of “Target” and “Actual” sections, each organized identically by business components: Anything that helps the team is documented in the “Target” section; the story merely references it. After development and testing, the specification moves to the “Actual” section. This ensures that short-lived work packages do not become trace anchors.
Does every user story require a systematic test design process?
No. Acceptance tests and exploratory testing are performed for every story; a systematic test design process is only added if the risk and the specification justify it. In such cases, the tester requests a test basis, such as a decision table. This represents a reversal compared to the Foundation Level: systematic testing becomes a supplement to experience-based testing, not the other way around.
Is model-based testing compatible with agile development?
Yes. The fact that it is rarely used in agile development stems from a twofold misunderstanding: models are regarded as mere documentation, and documentation is considered dispensable. Using path generators, abstract tests can be derived from system models, and concrete tests, including test data, can even be derived from test models. If such a model is provided along with a high-risk user story, the bridge to the test strategy is already built.
