In a real company a feature is not born on its own: a business requirement is written, analysed, split into epics, epics are broken into user stories, and each story is built separately on the frontend and the backend. The person testing reads that whole chain. This is that chain.
A real backlog end to end: 8 business requirements, 6 epics, 16 user stories and separate frontend and backend stories with acceptance criteria you can test.
Each link is the answer to the one before it. When you ask why a test exists, the answer is found upward along the chain; when you ask whether a requirement is met, the answer is found downward. The person testing must be able to walk this chain in both directions.
What you can learn on this page
A feature travels through five documents — Business requirement: What the business wants from the system. It states the need, not the solution: "a customer must be able to shop with an account of their own". · Analysis document: How the need maps onto the system: the data model, the order sta
Business requirements — BR-01 A customer must have an account of their own — A shopper must be able to identify themselves to the system; their cart, addresses and orders must not be mixed up with anyone else's. BR-02 A customer must only see products that can actually be bought — Th
EP-01 Identity and Session — Let a customer identify themselves to the system, with a session that opens and closes safely. US-01 A new customer creates an account · US-02 A customer signs in and out
EP-02 Catalog and Search — Let a customer find the products they can buy, without wasting time on the ones they cannot. US-03 A customer browses the catalog and does not see withdrawn products · US-04 A customer searches for a product
EP-03 Cart and Coupons — Let the cart genuinely reserve stock, and let discounts be revalidated at the moment of ordering. US-05 A customer adds an item and stock is reserved · US-06 A customer changes a quantity in the cart · US-07 A customer applies a coupon and is rejected with a r
EP-04 Orders and Payment — Let an order advance only in a meaningful sequence, keeping stock and money consistent at every step. US-09 A customer places an order and stock really drops · US-10 A payment fails and the order does not advance · US-11 An unpaid order cannot be shipped · US-
EP-05 Addresses and Reviews — Let a customer always have a usable address, and let any published review pass through moderation. US-14 A review does not count toward the average before approval · US-15 A customer always has exactly one default address
EP-06 Data Safety and Test Infrastructure — Let customer data open only to its owner, and let every test run start from a clean state. US-13 One customer cannot see another's order · US-16 Every run starts from a clean state
Frontend and backend story list — FE-01 The sign-up form warns the user before submitting · BE-01 The registration service creates the account once and safely · FE-02 The interface always shows correctly whether the session is open or closed · BE-02 The session service issues the key only to t
How the person testing walks this chain — Read the requirement - what does the system promise? — A story is part of a promise. A test written without knowing the promise repeats what the code does, not what the code ought to do. Open the analysis document - how exactly is the rule defined? — The data
Frequently Asked Questions
What does writing separate frontend and backend stories change?
It splits the surface to be tested in two. A rule can hold in the interface and not in the service: the quantity box may refuse zero while the service accepts the same request. When stories are written as one piece that distinction is invisible, and the testing usually exercises only the interface.
Why does a frontend story not begin with "as a frontend developer"?
Because it would stop being a user story and become a task in disguise. A story is always written from the user's point of view and its value flows to the user; development is done for the user in the first place. The frontend and backend labels say WHERE the work lives, not WHO benefits. Making the developer the actor cuts the tester off from the question "who is this for?" - and that is the only question by which an acceptance criterion can be judged.
Why do the acceptance criteria not state the expected status code?
The criteria a tester receives in the field are in business language. Deciding which code to expect, turning a criterion into a test case, is the tester's job - handed over ready-made, that skill never develops. Which endpoint can return which code is already written in the API contract.
What is the difference between an epic and a user story?
An epic is a large chunk that does not fit into a single sprint, holds several stories together and is not tested on its own. A user story is the smallest piece that produces value for the customer; it has acceptance criteria and can be tested end to end. Here, every epic also states which business requirements it serves.
I tested the business story - do I really need to test the frontend and backend stories separately?
Testing the business story end to end through the interface does not prove the rule also holds in the SERVICE. The interface may refuse to let you take a cart quantity down to zero while the very same request, sent straight to the service, is accepted; your end-to-end test is green and the defect is live. The reverse happens too: the service enforces the rule correctly but the interface never shows the refusal, so the action looks successful. That is why the same rule is exercised separately at both layers - it is not repetition, it is two different claims.