Example definition of three critical flows for a browser smoke suite, with break checks

This definition is synthetic

The shop, the pages and every value below are invented. The example shows what a buyer should agree in writing before any test is written: for each flow, where it starts, what the visitor does, the one thing on screen that proves it worked, what data it uses, how outside services are handled and how the test will be shown to fail. It is not a record of any client's flows.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

SYNTHETIC EXAMPLE: "Example Shop" does not exist; every value is invented.
Environment: staging copy, synthetic accounts, test-mode payment, email stubbed

FLOW 1  Sign up
  Start        /register
  Steps        enter an invented name, a unique address and a password; submit
  End state    the welcome page shows the account name and a "Sign out" control
  Data         unique address per run, for example run-<id>@mail.invalid
  Third party  verification email replaced by a stub; the test follows the recorded link
  Break check  remove the submit action on a throwaway copy -> flow 1 must fail, with a trace

FLOW 2  Log in and see orders
  Start        /login
  Steps        sign in with this worker's synthetic account; open Orders
  End state    the Orders page lists the account's seeded order
  Data         one seeded order per worker account, created at setup
  Third party  none
  Break check  make the Orders query return nothing on a throwaway copy -> flow 2 must fail

FLOW 3  Pay for a basket in test mode
  Start        a product page
  Steps        add to basket; enter an invented address; pay with the provider's test method
  End state    the confirmation page shows an order number and the correct total
  Data         unique order per run; synthetic address
  Third party  payment provider in test mode; shipping rates answered by a stubbed response
  Break check  change the total shown on the throwaway copy -> flow 3 must fail

What makes each flow testable

Each flow ends in something a person can see. A test that only checks that a page opened would stay green while the flow was broken, so the end state is the heart of the definition. Each flow uses its own data, so tests can run in any order and at the same time. Each outside service is replaced with a test mode or a stubbed response, so the suite never charges a card, sends an email or depends on a service you do not control. Those three properties are the difference between a smoke suite that is trusted and one that is ignored.

• End state: visible text or a visible page state, not an internal flag.
• Data: a unique account or record per test, created by the test or its setup.
• Outside services: test mode or a stub, and a note of which.

How the break check is used

A green test proves little until you have seen it fail for the right reason. For each flow, a deliberate fault is introduced on a throwaway copy, and the matching test must fail and attach a trace or screenshot. The fault is removed again and the test must pass. If a test stays green with the fault in place, it asserts too little and is rewritten. The buyer reads the break-check table beside the flow definitions, and may repeat any check on their own copy.

• Each fault is small and specific, such as removing an action or changing a displayed total.
• Each test is also run repeatedly in CI, with retries disabled for the check, before it is relied on.

Limits

Three flows cannot cover an application. They cover three journeys on a staging or preview copy, in the browsers agreed, with synthetic data. They do not measure speed, prove accessibility or test production. The browser smoke suite job is accepted on 20 consecutive passing runs per flow in the pull request job, the break checks and a review of the recorded network traffic for unexpected hosts. Prices are untested hypotheses, and this example is a checklist, not a runnable fixture.