Functional website testing

Walk every step before your customers do

Journey J-07 Checkout in sandbox verdant.example, staging

01 Open the basket Passed

Two items in, quantity changed on one of them, total recalculated.

02 Sign in Passed

Test account, correct password, basket still there afterwards.

03 Enter the delivery address Failed here

Postcode looked up, address chosen from the list it returns.

DEF-026 Blocker

The address comes back from the lookup, and the step will not accept it

Expected: The address chosen from the lookup is saved on the order and the step continues.
Actual: The county comes back empty, the field cannot be typed into, and Continue stays disabled. The journey stops here.

04 Pay with a sandbox test card Not reached

The payment provider’s published test card, in its test facility.

05 Land on the confirmation Not reached

Order reference shown on screen and repeated by email.

Registration, password recovery, search, filters, forms, booking and a checkout run in the payment provider’s sandbox. We take the journeys your website is actually used through, on an environment you approve, and write up every step that did not do what the site says it does.

Test your website before launch See a report entry in full

What is tested

Seven journeys, and the condition each one has to meet

A journey is not tested until there is a written statement of what counts as it working. The right-hand column is that statement, turned round: the conditions under which the journey is written up as failed.

The scope of an order names which of these are run and how far each one is taken.
Ref	Journey	What it covers	Written up as failed when
J-01	Registration	A new account created through the form a visitor actually sees.	an account is created that cannot then be signed into, a message states a rule the field does not enforce, a refusal is announced somewhere the person filling the form cannot see it, or the confirmation never reaches the test address.
J-02	Sign-in and password recovery	Getting back in, including the path taken when the password has gone.	the old password still works after a reset, a reset link can be spent twice, or the screen tells a stranger which half of the pair was wrong.
J-03	Search	Finding something, finding nothing, and what the page says in each case.	a term that exists in the catalogue returns nothing, an empty result is presented as an error, or paging loses the query.
J-04	Filters and sorting	Narrowing a list, combining the narrowings, and undoing them.	two filters together return more than either alone, clearing one clears them all, or a copied link opens the list unfiltered.
J-05	Forms	Enquiry, contact, upload and application forms, field by field.	an error clears what was typed, a required field can be skipped, or the page reports a message as delivered when nothing was sent.
J-06	Booking	Choosing a slot, holding it, changing it and giving it back.	one slot can be booked twice, the confirmation names a different time from the one chosen, or a cancelled slot is not offered again.
J-07	Checkout in sandbox	The basket and the payment step, run against the provider’s test facility.	a declined test card produces an order, the total at confirmation differs from the basket, or an abandoned attempt leaves an order behind.

Each of these is set out step by step on the Scenarios page.

How far each one is taken

Depth is the other half of a scope

Which journeys is the first question and the one everybody asks. How far into each one is the question that decides whether a pass finds anything.

Interrupted and resumed

The journey broken into part way through: the back button, a refresh mid-step, a session left to expire, the same journey open in two tabs, a slow or dropped connection. What the site does on the way back in is the thing being examined.

Input it should refuse

Each field given what it says it will not take: empty, too long, the wrong shape, the wrong type, the same thing twice. The message that comes back is read against the rule it claims to be enforcing.

The expected route

The journey completed the way it is meant to be completed, with valid input, on one browser and one screen size. Every step is written down and its outcome recorded, pass or fail, so that the run can be repeated later and compared against.

Read it from the inside out. The innermost block is the whole of a D1 pass; each ring around it is what the next level adds, and it is added on top rather than instead.

That is why a scope names a depth beside every journey. Two quotes for the same list of journeys at different depths are quotes for different work, and without the letter beside each one there is no way to see it.

How a package is put together

What a finding looks like

An entry carries the steps that produce it

A finding nobody can reproduce is an opinion. Every entry names the environment and the browser, runs the steps out to the one that failed, sets what should have happened against what did, carries a priority read from a published scale, and has a recording attached to it.

DEF-014 J-07 Checkout in sandbox

Blocker

A declined test card leaves a paid order behind

Environment: staging.orderly.example, build 4.7.2
Browser: Chrome, Windows, 1440 x 900

Steps to reproduce

01 Sign in as the test account buyer-02@orderly.example.

02 Add two items to the basket, then set the quantity of the first to 3.

03 Go to checkout and complete the address step.

04 Pay with the payment provider’s published test card for a declined authorisation.

Expected result

The payment is refused, the message names the refusal, the basket is left exactly as it was and no order is created.

Actual result

The payment is refused and the message is correct, but an order is written anyway and appears in the account’s order list marked Paid. Repeating the step writes a second one.

Screen recording DEF-014.mp4 0:41 the basket, the refusal message and the order list, in one take

The rest of the report

How an order runs

Three pairs, and nothing skips ahead

There is no basket on this site and no card field. A scope is written first, and the quote carries one figure in pounds sterling which is the whole of what the work costs.

Before there is an order

01 You describe the site

The address, what it is built on, which journeys matter and whether there is an environment that is safe to test on. The request form on Contact assembles exactly that and nothing else.

02 We write a scope and a quote

In writing: the journeys, the depth of each, the browsers and screen sizes, what is excluded, the figure, and the date the report is due.

Nothing is booked, nothing is begun and nothing is owed.

The order

03 You accept it in writing

We send a written confirmation back. Payment is arranged against that confirmation, by the method named in it. This website takes no payments.

04 Access is handed over securely

Test accounts, not real ones. Credentials through a channel meant for them, never in the body of an email and never through a form on this site.

The contract exists from the moment the confirmation is sent, and not before.

The work

05 The pass is run and written up

Every case is recorded whether it passes or fails. Failures become report entries with steps, expected result, actual result, priority and a recording.

06 Fixes are retested, if that is ordered

Quoted on its own, against the entries that have actually been marked fixed, together with the steps either side of each one.

A retest is a separate order, made when there is something to retest.

Access, data and payments

Five rules that do not move

These are conditions of an order rather than selling points. A customer who cannot meet one of them is better told before a quote than after a pass.

Only sites you are entitled to submit

Testing runs against websites the customer owns or is authorised in writing to submit. Confirming that is part of the request, and it is a condition of the order rather than a formality: nobody else’s site is exercised on a customer’s say-so alone.

Credentials travel in a channel meant for them

Usernames and passwords are not asked for in the request form and are not accepted in the body of an email. They come through a one-time secret link or a share from the customer’s own password manager, and they are deleted once the pass is finished.

Test accounts and test data

Accounts are created for the testing and belong to it. Where the customer supplies them, they are accounts made for the purpose, not a member of staff’s own login and not a real customer’s record. Personal data belonging to real people is not needed and is not wanted.

Payments in the sandbox, never live

The payment step is exercised in the payment provider’s sandbox, with the test cards that provider publishes. No live card is used, no live payment is taken and no live refund is issued.

A staging environment where there is one

Testing runs on an environment that can be written to without consequence. Where only the live site exists, that is agreed in writing beforehand and the pass is held to steps that change nothing a real customer would see.

What is not promised

Four things no pass here will claim

Not every defect

Testing is sampling. A pass exercises the journeys, depths, browsers and screen sizes in the scope and reports what it finds there. It cannot show that nothing else is wrong, and no pass is sold as though it could.

No score and no grade

A report is a list of findings with the steps to reproduce them. It does not end in a mark out of ten, a pass certificate or a badge to put in a footer.

Findings, not fixes

The work here is finding and writing up. Changing the code that caused a finding is a separate arrangement, agreed and quoted on its own.

Only as stable as the environment

A pass is worth what the environment it ran on is worth. Where the site changes underneath a run, the affected cases are re-run or marked as run against a moving target, and the report says which.

Test your website before launch

Send the address, the journeys that matter and what there is to test against. A scope and a quote come back in writing before anything is run.

Request a test