End-to-end user flow tests

End-to-End Testing

Prove that the critical user flows work in a real browser against the running system. Layout and visual checks belong to visual QA; this is about flows and behavior.

Choose the flows

• End-to-end tests only for the critical journeys (sign up, sign in, the main task or purchase, payment, data submission) plus a short smoke set. Edge cases and validation permutations belong in unit and integration tests.
• Write each flow as a user would describe it, with the expected outcome of every step.

Environment and data

• Run against a local or test environment started with the project's commands, never against production.
• Each test creates its own data, preferably through the API or a seed step rather than by clicking, with unique values per run, and cleans up after itself. No test depends on another test's order or state.
• Reuse a signed-in state per role instead of logging in through the UI in every test; keep one test of the real login.
• External services run in test or sandbox mode (payment test keys and test cards, captured email, SMS sandboxes) or are mocked at the network boundary. A test never sends a real email or message and never charges a real card.

Drive the browser like a user

• Look before acting: open the page, wait until it has settled, inspect the rendered result (a screenshot or the accessibility tree), then choose the controls.
• Locate elements by role, label and visible text, then test ids; never by CSS classes or DOM position, which change with styling.
• Use assertions that wait and retry until the condition holds. No fixed sleeps, and no one-off check of something still loading.
• Assert both what the user sees and what the system did: the confirmation, the new record in the list, the email caught in the sandbox, the API response with the expected status.

Find hidden failures

• Collect console errors and warnings and failed network requests (4xx, 5xx, aborted) during every flow. A flow that passes with errors in the console is still a finding.
• Run the unhappy paths of each critical flow: invalid input, a declined payment, an expired session, a slow or failing dependency, going back mid-flow, double submit.
• Check that a failed step leaves the system consistent: no half-created order, no second charge.

Flaky tests

• A flaky test is a defect. Find the cause (shared state, timing, test order, real external calls); never retry until it is green.
• Keep traces, screenshots and console output of failures so they can be diagnosed without re-running.
• After changing timing-sensitive code, run the suite more than once.

Report

List the flows run, the environment, browsers and widths, and each step's result, with evidence for failures. Say which flows were not run and why.

Before you finish

• Critical flows and their main unhappy paths are covered.
• Each test owns its data; no real sends or charges; third parties are sandboxed or mocked.
• Role, label and text locators with waiting assertions; no fixed sleeps.
• Console and network were checked for errors in every flow.