Research guide
How to Write Good E2E Test Cases: Examples + Template
A practical guide to writing E2E test cases that are worth keeping: how to describe a journey from the user’s goal, what to assert, and a reusable template you can copy.
Start from the user outcome
Write the scenario the way a customer would describe it: “A returning customer adds an item to the cart and checks out with a saved address.” That sentence contains the actor, the journey, and the expected end state.
If a test can only be understood by reading the DOM, it will only be maintained by the person who wrote it. A journey written from the user’s goal survives redesigns, copy changes, and framework swaps.
Write the preconditions explicitly
Every test needs a defined starting state: which user, which environment, what data already exists, and how it got there. Name the actor and the account so the setup is reproducible.
Deterministic setup matters more than clever teardown. If the test seeds its own data through an API instead of clicking through screens, it is faster and far less likely to flake.
Make the steps declarative
Declarative steps describe intent: “adds the product to the cart.” Brittle steps describe mechanics: “clicks the third button in the product grid.” Both can work today; only one still works after the grid is redesigned.
A useful rewrite rule: if the step mentions a selector, the class, or the position, rephrase it as the action the user is performing.
Assert outcomes, not animations
Assert the business result: the order exists, the session persists, the item is saved. Avoid asserting intermediate UI animations or arbitrary waits, which make tests fail for the wrong reasons.
When a test passes because the spinner finished rather than because the outcome is correct, it is not testing anything.
A reusable E2E test case template
Keep a fixed template so new cases stay reviewable: Feature, User story, Actor and preconditions, Steps, Expected result, and Priority. Filling in six fields forces the author to answer the questions a reviewer needs.
Example for login: Feature, Authentication. User story, “A returning user signs in and reaches the dashboard.” Preconditions, seeded user, no active session. Steps, open login, enter credentials, submit. Expected result, dashboard loads, session persists on reload. Priority, critical.
Review a test case before you run it
A quick review pass asks three questions: would a new teammate understand it, does it survive a redesign, and does it test exactly one journey? If any answer is no, the case needs work.
For ready-to-adapt scenarios, see the 50 real-world E2E test cases list, and use the production-release checklist to decide which cases actually gate a release.
Key takeaways
- Describe the journey from the user’s goal, not from the DOM structure.
- Make preconditions explicit and setup deterministic.
- Assert the business outcome; a test that names a selector twice breaks twice.