Functional testing

Functional testing is the part of QA that checks behaviour rather than appearance. A page can look right and still send an enquiry to an inbox nobody reads, accept a booking for a date that has passed, or charge the wrong delivery rate. We test those behaviours deliberately, with written test cases, so that a pass means something specific and a failure can be reproduced by whoever has to fix it.

What we test

The scope is agreed before any testing starts, but a functional review of a small or medium website covers some or all of the following.

• Forms of every kind. Contact, quote, newsletter, booking and application forms. We submit valid entries, empty entries, entries that are too long, and entries with unusual characters, then confirm where each message ends up.
• Validation and error handling. Whether required fields are enforced, whether error messages say what went wrong, and whether the form keeps what the visitor already typed.
• User flows. The routes people take to finish a task: finding a product and paying for it, booking an appointment, creating an account and logging back in, resetting a password.
• Integrations. Payment providers in test mode, booking systems, mailing list services, CRM connections and anything else that receives data from your site.
• Search and filtering. Whether site search returns relevant results, handles a search with no matches, and copes with spelling variants.
• Confirmation and notification emails. Whether they arrive, whether the wording matches the action taken, and whether links inside them work.
• Edge cases that matter to your business. Opening hours, public holidays, stock limits, discount codes, minimum order values or anything else with rules attached.

How a session runs

Each engagement starts with a short scoping call or email exchange. We list the flows that matter, agree which ones are in scope, and note anything we should not touch, such as live payment accounts or production data. From that list we write test cases: a title, any preconditions, numbered steps and an expected result that anyone could judge. You can see the test cases before testing starts.

Testing is done on a staging copy where one exists, or on the live site with agreed limits. Each test case is run and marked pass, fail or blocked. A failure becomes a defect report with the page address, the browser and device, the steps, the expected and actual result, a severity rating and a screenshot or screen recording.

When your developers have made fixes, we run the failed cases again, along with a set of nearby checks. That second step is the one that catches a fix which repairs one form and breaks another. A defect is closed only when we have seen the fix work.

What you receive

• The agreed test cases, with the result of every run.
• A defect list with evidence attached to each item, sorted by severity.
• A short written summary: what was tested, what failed, what passed, and what was left out of scope and why.
• Retest results as quoted, including any new problems found during retesting.

Reports are written in plain English. Where a finding needs technical detail for a developer, that detail sits under the plain summary rather than replacing it.

What this service does not cover

Functional testing finds defects in the flows we test. It does not prove that untested flows work, and it is not a code review. We do not fix the defects ourselves; your developer or agency does that, which keeps the testing separate from the build. Load testing, where thousands of simulated visitors hit the site at once, is outside this service. If a flow handles payments, we test it with the provider's test mode and test card numbers only.

Test data and clean-up

Functional testing creates data: test enquiries in your inbox, test bookings in your calendar, test accounts in your user list. We label every piece clearly, keep a list of what was created, and hand that list over at the end so it can be removed. Where a flow sends messages to staff, such as a booking notification, we agree in advance who will receive them so nobody acts on a test by mistake.

When to book functional testing

• Before a launch or relaunch, once content is in place and the build is feature-complete.
• After a significant change, such as a new booking system, a new payment provider or a redesigned checkout.
• After platform updates, when a CMS, theme or plugin release has changed code that your forms rely on. Our guide to testing after CMS and plugin updates covers this case.
• When enquiries drop without explanation. A broken form can look like a quiet month.

Questions about functional testing