This checklist is for businesses preparing to accept delivery of a product, offer or project configurator. It helps define the evidence required before accepting the work, without prescribing a particular technology.

Define what the configurator must deliver

The expected output determines the checks. An estimate helps guide the visitor; a quote request must provide enough information to be processed; a purchase must carry the approved choices and amount through to the order. Define that output before testing the screens.

Also specify who maintains the options, incompatibilities and prices. Choose a reference configuration whose expected result is calculated independently, using the approved pricing and rules. If the expected result is simply copied from the configurator, the test can confirm the configurator's own error.

An acceptance checklist to use with your provider

For each row, record the configuration used, the expected result, the actual result and evidence: a screenshot of the summary, a request reference or a record received. Run tests in an environment intended for this purpose, using test contact details.

Situation to trigger Expected result Evidence to keep
Complete a reference configuration Choices, quantities and total match the independent calculation. Summary and reference calculation.
Return to the first choice after adding options Options that have become incompatible are removed or flagged before confirmation; the price follows. Comparison before and after the change.
Try a prohibited combination The rule is explained and the configuration cannot be confirmed as it stands. Message and confirmation that no invalid request was created.
Enter a dimension or quantity at its permitted limit, then just beyond it The business limit is enforced; the unit and required correction are clear. Values tested and responses.
Quickly change several priced options The final price reflects the last choice, even if network responses arrive in a different order. Final choice and confirmed amount.
Refresh the page or return later The agreed behavior is respected: a consistent restored state or an explicit warning before starting again. Restored state and displayed message.
Submit the same request twice or retry after a connection failure The same submission is recognised and its status can be checked, without silent duplication. Submission reference and check in the receiving tool.
Repeat the journey on mobile and using a keyboard Choices, errors and the summary remain accessible; no essential control is hidden. Observed journey and any issues.
Change a price after saving a configuration The old price remains identifiable; any update is explained before confirmation. Pricing version and recalculation rule.

This checklist is a starting point. Add rules specific to your business: availability, service area, production lead time or technical approval. A configurator used only for quotes does not need to simulate a payment, but you must check that requests reach the sales tool.

Pricing: distinguish display from validation

Visitors must understand what the amount includes: options, quantity, currency, taxes and any charges still to be determined. An estimate must be labelled as such. For a sale, compare the summary with the amount actually presented at checkout.

Technical checks must also confirm that changing a price sent by the browser cannot force the system to accept that amount. OWASP recommends recalculating sensitive values on the server from trusted data, rather than trusting fields sent by the client. Ask for evidence of this check in the test environment: a correct total on screen does not demonstrate it.

A worked example: an option that becomes unavailable

Consider a fictional garden shed configurator. The chosen finish is only available for certain models. The visitor selects that finish, then goes back and changes the model.

The test follows the same configuration all the way through. The new model must trigger the agreed rule: request another finish or remove the incompatible one with an explanation. If the option is removed, its surcharge must disappear from the total. The summary and the request received must describe exactly the same shed.

This example illustrates an acceptance testing method; it does not describe any Codezilla client or result. It checks a rule across several screens and through to receipt, where testing screens individually can miss an inconsistency.

Customer journey: make choices understandable and correctable

For a multi-step journey, show progress and preserve choices when visitors go back to check them. The W3C recommends organizing forms into logical steps and making progress understandable.

An incompatibility should not result in a disabled button with no explanation. The W3C guide to form notifications recommends clear feedback on errors and successful submission. During acceptance testing, check that visitors can identify the problem, understand how to correct it and retain the other information they have already entered.

Receipt: check what the team can actually use

Open the request at its real destination: inbox, CRM, quoting tool or order. Compare it with the summary. It must let the team retrieve the configuration, its options, quantities, amount and pricing context, together with the contact details needed to process it.

Distinguish a record being received by the system from a notification email being sent. If a request is saved but the notification fails, the team must still be able to find it. If submission remains uncertain, visitors must be able to check its status or retry without unknowingly creating a new request.

When should you postpone launch?

An incorrect price, an accepted prohibited combination or a missing request are reasons to postpone. A minor visual issue can be scheduled for later if it does not hinder understanding or action. For every outstanding issue, assign someone to approve the correction and identify the scenario to rerun.

This acceptance test does not replace a full security or accessibility audit. It establishes one specific point: the configurator's priority rules have been checked through to their business outcome. To scope custom development connected to your website, prepare your rules, a reference configuration and the destination for requests. Let's discuss your configurator using that information.

Plan your next step