Norwich, Norfolk eCommerce since 2009 UK-wide

How do we decide a website or data change is finished?

Working notes

How do we decide a website or data change is finished?

It ran without an error is not the whole acceptance test. The result has to do the job the business actually needed.

Working method

The short answer

Define finished in terms of useful behaviour, not 'the script ran'. Test normal examples, awkward examples and the failure cases that matter.

Why it matters

A script can run successfully and still produce the wrong match. A page can load while its enquiry form goes nowhere. I'd rather agree the useful checks early than reach the end of a project with two different ideas of finished.

Define the expected behaviour

For an import, that might mean the right records updated and unrelated fields left alone. For a reporting tool, it means the calculation answers the agreed question. For a form, it includes delivery and the information the recipient receives.

Choose the tests from the requirement, not from whichever checks happen to be easiest.

Include awkward examples

A representative sample should include the records most likely to expose a problem: variations, duplicate-looking items, missing values or overlapping dates, depending on the job.

Occupancy calculations and product relationships show why a simple happy-path sample can miss the important issue.

Test updates and failures where they matter

For a repeatable process, run the sample again and inspect what changes. For an ongoing process, agree how a failed source or unexpected input should be handled.

Keep the test separate from live operations where possible, and establish a suitable backup or recovery plan before consequential changes.

Tell me what you need to sort out

If you need this checked or fixed on a real site, send me the URL, a safe example and what you are trying to achieve.

Tell me the problem

Handover is part of the result

The finished job should make clear what was changed, what remains outside scope and who looks after it. That can be a short practical handover rather than a large document nobody uses.

If a later change introduces new requirements, assess it as a change. Clear scope and support are part of making the technical work sustainable.

HAVE SOMETHING AWKWARD?

Tell me what you need to sort out

Send me the URL, what is happening, what you have already tried and what a useful result would look like. A small anonymised sample is enough to start - do not send passwords, credentials or sensitive customer data.