Technical testability of user stories refers to the property that a tester has all the necessary information to be able to test in a targeted manner. User stories are planning artifacts, not permanent requirements documents. Acceptance criteria define what must function in a demonstrable way. Supplementary specifications such as decision tables or flowcharts are only added where they really help the team.
Key Takeaways
- User stories are planning artifacts, not requirements: they can be thrown away after the sprint because sustainable documentation has to be maintained elsewhere.
- Acceptance criteria are wasted in many projects because they contain additional requirements instead of concrete examples that the product owner wants to see in the demo in order to approve it.
- Asking in the refinement which specification would help the team with development and testing in the sprint provides the strongest leverage for technical testability.
- Each user story can be approached according to three test activities: Acceptance testing always, exploratory testing always, systematic test design only if the risk is appropriate.
- Requirements engineering has been dropped in many places in the transition to agility, although formal methods such as decision tables or flowcharts do not contradict agile principles.
User stories are not requirements, but work packages
A user story is not a requirement. It is a planning artifact that a team can attach to a board, estimate and drag through a sprint. Anyone who ignores this distinction is building on the wrong foundation.
This leads to an uncomfortable consequence: stories are not intended for permanent requirements documentation. After the completed iteration, they can be thrown away. This is precisely where many teams rub themselves up the wrong way because they misuse the story as a long-term repository for knowledge that actually belongs somewhere else.
Christian Brandes identifies a larger pattern behind this confusion. With the switch to agile models, requirements engineering has gone overboard in many teams, often with the justification: “We no longer need requirements, we now have stories.” This equation does not hold up in practice.
Responsibility then often silently shifts to the product owner. However, very few product owners are trained requirements engineers. This creates a gap between requirements and testing that no one explicitly fills.
What does functional testability mean?
Technical testability means that whoever is supposed to test a story has all the information they need for the test in addition to their intuition. This is the central question that determines the value of a story for the test.
Separate from this is technical testability. It asks whether tests can be carried out at all, i.e. whether there is control over the test environment, date and time. Both forms are important, but they solve different problems.
In practice, everyone nods at the “testable” investment criterion. However, when asked how testability is actually achieved, there is often silence. Brandes compares this to the concept of quality: difficult to define, but immediately noticeable if it is missing.
The practical lever against this silence is simple. If a story contains technical logic, it includes a specification that the tester does not have to laboriously search for. If it only says “Check discount calculation”, the team needs to know what checking actually means.
Acceptance criteria are given away in many projects
Acceptance criteria are not additional requirements, even if they are treated as such in many projects. They answer a different question: What must be proven to work in the end for the product owner to accept the story with a clear conscience?
The clean method behind this is Specification by Example according to Gojko Adzic. The product owner writes down the concrete examples that he wants to see in the demo as acceptance criteria in order to be convinced. Acceptance is also a matter of trust in agile, and it is precisely these examples that create trust.
This logic does not fit into a classic requirement. It belongs in the acceptance criteria section, where it is a problem that has already been solved.
Acceptance criteria have another advantage for testing: they cry out to be automated. What is so important to the product owner that he wants to have it demonstrated, you as a tester want to check again and again.
The story as a container: the middle room decides
A viable story consists of three zones. The name describes the problem space according to the familiar template: As a role, I want functionality in order to achieve business value. The acceptance criteria describe what has to work in a demonstrable way in the end.
In between is an optional space, the story specification or story description. If the team says “we’ve already done this ten times”, this space remains empty. If the team needs a hand-drawn sketch, a decision table or a link to details, this is where it goes.
Many tools lead to a skewed division here. The user story template ends up in the description, the name shrinks to two words. It is better to keep the name as a meaningful short name and keep the description free for all the detailed information that helps the team.
Risk information also belongs in this space. If the product owner marks the detail where no error should occur, this is a valuable signal for testing.
How does a team manage which specification it really needs?
The strongest lever is a single question in the refinement. After the product owner has presented the story, he asks the team: Which specification would help you to develop and test this in the sprint?
The word “help” is the benchmark here. What is documented is what is useful for someone, not everything and not nothing. This resolves the apparent contradiction between “communication over documentation”, because the “over” does not prohibit documentation, it just prioritizes the conversation.
The choice of format depends on the content. Technical logic fits into a decision table. A process with variants fits into a flowchart, whether BPMN or UML, without having to call it that.
Brandes expressly warns against this: don’t force every example into Gherkin syntax just because a team has switched to BDD. Where the format does not fit, a sketch, a value range or a table that can be read is often sufficient.
We only document what is of value or use to someone. If that helps the team, then we do the same in agile.
- Christian Brandes
Permanent documentation belongs next to the story, not in it
If a specification is to last, it does not live in the story. It lives in product documentation that grows in parallel with the product from iteration to iteration.
Brandes describes a separate structure of target and actual, both with an identical content structure according to technical components. If the team says that a specification would help, it is documented in the target area. The story only references this: details can be found here.
Once the function has been developed and tested, the specification moves to the actual state. There is almost nothing left to do because the documentation work has already been done in advance. The story itself is then thrown away.
This also solves a recurring trace issue. Test cases are not linked to the aging story, but to the specification and later to the product documentation. This creates a traceable trail without the need for short-lived work packages to become trace anchors.
| Artifact | Lifetime | Purpose |
|---|---|---|
| user story | only for the sprint, then disposable | planning, estimation, work package |
| specification (target) | grows with each iteration | detailed knowledge that helps the team |
| Product documentation (actual) | permanent | Trace anchor for test cases, product knowledge |
Non-functional requirements do not need a special path
Nothing new is needed for non-functional requirements. The story offers space for specifications, so performance, security or other quality characteristics are specified there.
Here, too, there are tools from requirements engineering. Instead of “the system must be fast”, a sentence template provides a verifiable statement: this function must provide an answer in 99 percent of cases under defined framework conditions in no more than this much time.
The product owner decides how visible the topic becomes. If it is important enough to him, he raises it as an acceptance criterion and has it demonstrated. Otherwise, he trusts the test activities of the system testing team.
Three Xs: a lightweight test strategy for stories
If a story is technically testable, three activities jump out of its structure. Brandes summarizes them 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 is exploratory tested, based on the criteria, the specification or intuition. The aim is fast feedback, early error detection and system understanding.
- Risks: Optionally, a systematic test design procedure is added if the risk and specification justify it. Here, the tester requires a test basis, such as a decision table.
There is a reversal in this sequence. Acceptance and exploratory tests always run, systematic procedures only if they help. Systematic testing thus becomes a complement to experience-based testing, while the foundation level has the sentence exactly the other way around.
Model-based testing also fits into agile
Model-based testing generates test artifacts from formal models such as UML or BPMN. The most important distinction separates system models from test models.
System models describe the system and often come from the requirements engineer, for example as a use case model or class diagram. A test model looks similar, but describes the test of the system. It belongs to the test and can be enriched with test decisions and concrete test data that have no place in a system specification.
Abstract tests can be derived from system models using path generators, which saves a lot of hard work. Concrete tests can even be generated from test models. If such a model comes along with a risky story, the bridge to the test strategy is built.
Brandes attributes the fact that model-based testing is hardly used in agile to a double misunderstanding. Models are seen as mere documentation, and documentation is seen as dispensable in agile. Both assumptions are wrong. Where a model helps to test the beast, it is part of it.
