From business requirement to test: agreeing on behaviour you can verify
The requirement “customers must be able to register for a workshop” does not yet explain how you will recognise a correct result. The product owner, who is responsible for the product’s direction, the analyst, developer and tester may each interpret it differently. A shared specification should therefore describe inputs, conditions and expected behaviour in a form the client can approve and the team can verify. You can start even without ready-made test scenarios.
Why a list of clicks is not enough
The instruction “open the website, select a workshop, press Register” describes how to operate the application. It does not explain what success means: was a valid registration created, was a place taken and can the user see the correct status? A passing test that only checked whether the button appeared cannot answer these questions.
Requirements such as “it should be fast” or “handle the error correctly” are equally unclear. The team needs to agree on conditions, an observable outcome and, where relevant, a time limit. The application’s current behaviour can help with investigation, but it does not by itself establish the intended rule. Otherwise, you may copy an existing defect into the specification.
This step comes before deciding when to run smoke, sanity or acceptance tests. Here, you agree on what the application should do; those types of testing then use the agreement for different purposes.
What to bring when you have no prepared scenarios
The client does not need to write a technical specification. A demonstration of everyday work, a description of the problem and a concrete case involving an error or uncertainty often provide a more useful starting point. An analyst or tester can use these materials to prepare a proposal, open questions and examples for approval.
For a shared discussion, prepare:
- The objective and user: who needs to do something and why the result matters.
- Inputs: for example, the selected workshop, the participant’s account and the number of occupied places; use prepared test data for demonstrations.
- Preconditions: what must already be true, such as a signed-in user, registration being open and the workshop existing.
- The expected result: what the user or a downstream system can observe after the action.
- Boundaries and exceptions: the last available place, full capacity, a repeated request or an unavailable dependency.
- The decision owner: who can confirm the rule when team members interpret it differently.
Record a missing answer as an open question with a named owner. An assumption such as “it probably needs to send an email” must not quietly become an approved requirement. If you cannot determine the correct result without the answer, that scenario is not yet ready to implement.
How the discussion produces acceptance criteria
Acceptance criteria are the conditions used to assess whether a requirement has been met. A rule may cover every registration, while a concrete example shows how to interpret it: when eleven out of twelve places are occupied, another participant can still register.
Keep rules, examples and unanswered questions separate during the discussion. The Example Mapping method in the Cucumber documentation uses this distinction. Adding a list of deferred topics also helps everyone see the boundaries of the current assignment.
A useful deliverable is a short record attached to the requirement: approved criteria, examples, open questions and scope decisions. Clearly distinguish the tester’s proposal from a confirmed business rule. A tester can identify ambiguity, but without the authority to do so, cannot decide whom the business should allow to register.
A worked example: registering for the last place
The following example is fictional. Its numbers and rules explain the process; they are not recommended settings for every booking system.
Requirement R-17: “A signed-in user can register for a workshop that is open for registration if a place is available. The number of confirmed registrations must not exceed capacity.” After the discussion, the team adds that one account can have only one valid registration for the same workshop. Waiting lists and email notifications are outside this requirement.
| Criterion | Agreed behaviour | Concrete example |
|---|---|---|
| K1: a place is available | One confirmed registration is created and appears both to the user and in the organiser’s list. | With capacity set to 12 and 11 registrations, a twelfth is added. |
| K2: capacity is full | No new registration is created, and the user is informed that capacity has been reached. | With 12 registrations, another account cannot register; the count remains 12. |
| K3: repetition | Repeated submission by the same account does not create another registration. | An account already registered under K1 submits the request again; the count does not change. |
| K4: concurrent requests | When two different accounts request the last place at the same time, only one succeeds. | The count rises from 11 to 12; the other account is informed that capacity is full. |
K1 becomes scenario S-17-1. The preconditions are open registration, capacity set to 12, exactly 11 confirmed participants and a signed-in account that is not among them. The action is submitting a registration. The expected result is confirmed status for that account, exactly one entry for it in the organiser’s list and a total count of 12.
This structure corresponds to Given–When–Then: an initial state, an event and an expected result. The Gherkin documentation recommends checking the outcome through an observable output. Ordinary text or a table is sufficient for reaching agreement; adopting a particular tool is not a prerequisite.
K2 through K4 need their own scenarios. Two sequential attempts do not replace the concurrent attempt in K4. The tester and developer must agree on how to create concurrent requests and distinguish the outcomes for both accounts. If a test only checked the last place for one user, the concurrency criterion remains unverified.
What counts as evidence of an executed test
A scenario describes the expectation; a run result records what actually happened. For S-17-1, the requirement and criterion identifiers, scenario version, tested application version, environment, accounts used and initial occupancy should be traceable. The record also needs the actual results of the individual checks and the overall run status.
Appropriate evidence might be the confirmed registration visible in the user’s account and the corresponding organiser’s list. A technical check may also read the result through an agreed API, an interface through which programs communicate. The verification method should match the criterion; a successful server response alone does not confirm the correct participant count.
A screenshot of the confirmation helps check what was displayed, but cannot on its own prove that no duplicate was created. Similarly, “test passed” is insufficient if the summary does not reveal which conditions were actually checked. Agree on the scope and form of evidence according to the project’s needs, rather than everything the testing tool can produce.
What the client approves and what the technical team handles
The client or an authorised product owner approves the intended behaviour, examples and scope boundaries. In our example, they confirm that the rule applies per user account, that repetition does not create another registration and that a waiting list will not be introduced yet. They also identify who will answer questions or approve a later rule change.
The technical team is responsible for an executable procedure, data preparation and appropriate checks. The client does not need to approve every selector, meaning a rule for finding an element on a website. They should understand what the test result confirms and what remains outside its scope. Approving a scenario before implementation is also not automatic acceptance of the completed feature.
AI should preserve the scenario’s approved meaning
When creating a test with artificial intelligence (AI), the approved written description remains the basis for review. AI can propose code, follow-up questions or a repair to a technical step. It should not change inputs, the procedure or expected results simply to make the test pass.
If the check for twelve registrations fails, replacing the exact count with “the list is not empty” weakens the criterion. Omitting the duplicate check removes part of the agreed behaviour. A selector repair may preserve the meaning, but a person still needs to check that the test uses the correct element and account.
An authorised person must approve a change in meaning, and it should be reflected in the requirement, criterion and scenario. During review, compare the written description with the actual steps and checks. A passing result is useful only in conjunction with what the test performed.
What you gain and where the limits remain
Connecting requirement → criterion → scenario → evidence makes it possible to locate a specific rule and responsible person when a disagreement arises. The analyst can show unresolved questions, the tester missing checks and the client the scope they are accepting. When capacity or account rules change, the affected tests are easier to find.
Even a thoroughly specified registration flow does not cover the whole product. Security, accessibility or behaviour under heavy load may need further requirements and separate verification. Their priorities belong in the broader test strategy.
A first step for your own requirement
Choose one important user activity and add a successful example, a boundary case and an error flow. For each, identify inputs, preconditions, the result and how it will be verified. Assign ambiguities to a named decision-maker. This gives you a basis for agreeing on the work even when you do not yet have a single automated test.