Product configurator testing and QA guide
A configurator can look correct while producing an invalid combination, wrong price, inaccessible interaction or incomplete order. This guide connects rules, 3D, documents, integrations and operations to one versioned test architecture and release evidence pack.
Ten quality domains
Verify the complete configured workflow
Six test layers
Use the right evidence at the right boundary
Twelve acceptance tests
Make release decisions reproducible
Eighteen QA FAQs
Answer technical and buyer questions clearly
Clear definition
A product configurator joins multiple truths: the catalogue says what exists; rules say what is permitted; 3D communicates the selected state; pricing creates a commercial result; documents communicate an offer; integrations and optional BOM or order outputs move the project into another responsible system. QA proves that these layers agree for known configurations and failure conditions.
A good test names the requirement, product and account fixture, input, expected structured state, visible result, downstream consequence, environment, revisions and evidence. “The quote button works” is weak. “Dealer A configures product revision 12.4, receives account price revision 8, generates quote revision 3 and delivers project ID P-2041 exactly once to CRM” is reproducible.
Testing is therefore a permanent product capability, not a ceremony at launch. The accepted scenarios become the regression pack for new options, prices, assets, translations, integrations, browsers and platform releases. Production observation adds evidence from real conditions while never replacing pre-release prevention.
Interactive QA scope builder
Select the journey, business output and change type. The builder returns the minimum areas an impact review should consider. Replace the generic choices with real product fixtures and responsibilities before release.
Primary journey
Business output
Change type
Suggested release scope
Require source revision, targeted regression, presentation review and post-release observation.
Account catalogue, price list, customer project and co-branding
Cross-account denial and role downgrade
Saved project continuation between dealer and customer
Known-price ledger and branded document reconciliation
Quote revision, validity, language and customer delivery
CRM project identity and follow-up status
Normal, boundary, invalid and historical configuration fixtures
Price, visual, quote and downstream trace for changed logic
Targeted plus dependent regression suite
Journey
Dealer sales
Output
Lead + quote
Change
Product logic
Complete quality model
Each domain has different owners and evidence. They meet in the same versioned configuration, which is why the test pack must reconcile layers rather than evaluate them as unrelated features.
Is the right product revision being tested?
Verify product families, option groups, stable IDs, labels, markets, languages, availability and saved configuration identity. Test renamed, withdrawn, replaced and effective-dated items—not only the current happy path.
Evidence
Catalogue revision, fixture IDs, expected availability and saved-project results
Can users create only accepted states?
Test defaults, required choices, dependencies, exclusions, substitutions, minimums, maximums, increments, derived values, coupled dimensions, warnings, review conditions and hard stops at boundaries and just outside them.
Evidence
Decision table, boundary fixtures, expected messages and valid-state snapshots
Does the visible product match the structured state?
Trace materials, visibility, modules, transforms, instances and procedural geometry to configuration IDs. Verify scale, pivots, camera, clipping, motion, largest scenes, repeated changes and asset revisions across supported devices.
Evidence
Configuration-to-scene trace, asset manifest, screenshots and device measurements
Can every price be explained and reproduced?
Reconcile list, dimension, area, component, service, account, market, currency, discount, approval, tax and rounding lines. Include thresholds, effective dates, missing prices, quote-only states and repricing of saved projects.
Evidence
Known-price ledger, source revision, line provenance and approved total
Do outputs represent the accepted revision?
Verify quote identity, configuration snapshot, selections, exclusions, totals, tax, validity, terms, language, brand, 2D or 3D imagery, page flow, accessibility and regeneration after a controlled change.
Evidence
Approved PDF set, structured quote record, comparison and reviewer sign-off
Does the downstream structure reconcile with product truth?
Test component IDs, hierarchy, quantity, unit, variable dimensions, effectivity, substitutions, pack or waste logic, documents and review status. A correct picture or total does not prove production output.
Evidence
Expected component structure, quantity calculations and destination acknowledgement
Does data arrive once, completely and traceably?
Test authentication, schema, field mapping, identifiers, idempotency, ordering, timeouts, retries, duplicate events, destination outage, partial failure and reconciliation for CRM, ERP, ecommerce, PIM and other systems.
Evidence
Contract result, correlation IDs, delivery log, recovery and reconciliation record
Can each identity access only permitted objects and actions?
Test public, customer, dealer, workforce and service identities across accounts, projects, prices, files, exports and privileged actions. Include cross-object denial, role changes, shared links, upload controls, retention and audit reconstruction.
Evidence
Role matrix, negative access results, event records and lifecycle exercise
Can people complete the journey without one input or sensory mode?
Evaluate keyboard order, focus, control names, status announcements, errors, contrast, target size, zoom, reflow, reduced motion, dragging alternatives and an equivalent way to understand and configure the product beyond the canvas.
Evidence
WCAG scope, automated scan, manual assessment, assistive-technology notes and exceptions
Does the accepted experience remain usable in real conditions?
Measure initial page and 3D loading, first useful product view, interaction response, layout stability, memory, sustained frame behavior and recovery on supported browsers, devices, networks and normal plus largest valid scenes.
Evidence
Lab matrix, field measurements, budgets, representative traces and release comparison
Test architecture
Put combinations and calculations in fast model tests. Use end-to-end journeys to prove assembly. Preserve human review for appearance, language, usability, accessibility and operational meaning that automation cannot decide reliably.
Fastest
Validate data shape, identifiers, units, formulas, rule functions and transformations in isolation.
Examples: Schema validation, decision-table cases, pricing calculations, quantity formulas and migration checks.
Limit: Cannot prove that the assembled customer journey or connected systems behave correctly.
Fast
Verify a boundary between services, assets or systems without depending on a live external environment.
Examples: API request/response, webhook signature, document payload, asset manifest and ERP field mapping.
Limit: A correct contract does not prove the real endpoint, permissions, data or recovery path.
Medium
Exercise user-visible controls and state transitions with controlled product fixtures.
Examples: Dimensions, option dependencies, validation messages, price updates, keyboard behavior and save state.
Limit: Mocked boundaries can hide deployment, authentication and downstream failures.
Slower
Verify a real user role completes the most valuable business flow through the assembled application.
Examples: Configure, price, save, request quote, approve, generate document and deliver an order record.
Limit: Broad tests are expensive and harder to diagnose; keep them representative rather than duplicating every rule case.
Deliberate
Evaluate meaning that automated checks cannot reliably determine.
Examples: Finish credibility, language quality, document clarity, accessibility, usability and production acceptance.
Limit: Review must use recorded criteria and exact revisions or it becomes subjective and irreproducible.
Continuous
Detect real-user, device, data and dependency behavior that pre-release fixtures cannot fully reproduce.
Examples: Field performance, error rates, failed events, abandoned steps, quote reconciliation and support signals.
Limit: Monitoring finds impact after release; it does not replace pre-release prevention or acceptance.
Release governance
A green automated suite is evidence, not authority. Release acceptance also needs scope, domain ownership, non-functional quality, historical compatibility and operational readiness.
Pass evidence
Change record names affected products, markets, roles, systems, saved states, evidence and rollback.
Not enough: The change is described only as a ticket title or visual request.
Pass evidence
Required model, contract, component and journey tests pass on the release candidate and accepted fixtures.
Not enough: Failures are rerun until green without explaining flakiness or scope.
Pass evidence
Named product, pricing, 3D, document, integration or operations owners approve affected evidence.
Not enough: A general stakeholder approves outputs outside their responsibility.
Pass evidence
Accessibility, performance, security, compatibility and recovery checks match the change risk.
Not enough: Functional success is treated as proof of usable, secure and resilient delivery.
Pass evidence
Supported saved projects, quotes, orders and integrations retain their accepted meaning or follow a documented migration.
Not enough: Only new projects created after the release are tested.
Pass evidence
Version, migration, observability, owner, communication, rollout and rollback are ready before publication.
Not enough: Publishing is the first time the complete change is observed in a production-like environment.
Evidence contract
The report connects the assertion to exact product, application, price, asset, fixture and environment revisions. That makes the result reproducible and useful when a later release fails.
{
"testId": "QA-E2E-QUOTE-014",
"requirement": "dealer configuration to accepted quote",
"status": "passed",
"executedAt": "2026-08-19T15:20:00Z",
"environment": "release-candidate",
"revisions": {
"application": "8.7.0-rc.2",
"productModel": "PERG-BIO-12.4",
"priceList": "DEALER-EU-8",
"asset": "asset_pergola_01@3.2.0",
"quoteTemplate": "Q-EN-4.1",
"crmContract": "lead-project@2.3"
},
"fixture": {
"account": "dealer_havenform",
"configuration": "cfg_known_1042",
"expectedTotal": { "currency": "EUR", "value": "10440.00" }
},
"assertions": {
"configurationValid": true,
"visualStateMatched": true,
"priceLedgerMatched": true,
"quoteRevision": 3,
"crmDeliveryCount": 1
},
"evidence": ["trace_7A4", "quote_Q1042-r3.pdf", "crm_evt_83P"],
"approvedBy": ["product-owner", "pricing-owner", "sales-operations"]
}Cross-domain acceptance pack
These tests deliberately cross boundaries. Replace the example product, numbers, identities and outputs with approved fixtures, then apply the same pack to every vendor and every material release.
Set each primary dimension to the accepted minimum and just below it. Verify product state, explanation, visual geometry, price and downstream behavior.
Create the largest valid multi-module product with permitted accessories. Verify constraints, scene stability, price, document and output quantities.
Select a required dependency, then attempt a known incompatible option through the UI and direct state input. Confirm one governed result and clear message.
Run a configuration with approved line-by-line expectations across dimensions, options, services, discounts, tax and rounding; compare sources and total.
Change one material, module, dimension, accessory and moving state. Reconcile node behavior with stable configuration IDs and the saved project.
Generate a quote, revise the configuration, reprice and regenerate. Verify revision identity, supersession, snapshot, validity and customer-visible differences.
Deliver a known configuration to the accepted order or BOM destination. Reconcile IDs, quantities, units, dimensions, revision and acknowledgement.
Interrupt one required integration. Verify safe user status, queued or failed state, attributable alert, idempotent retry and final reconciliation.
Use a valid dealer or customer identity to request another account's project, quote, file, export and event. Confirm denial without content leakage.
Complete the primary journey without a pointer. Verify focus order, visible focus, control names, errors, progress, price changes and completion status.
Load a normal and largest valid configuration on representative phones and networks, then change options repeatedly while measuring response and memory.
Open supported projects created before the release. Verify product revision, mappings, price policy, appearance, documents and intended migration behavior.
QA failure patterns
The dangerous test suite is not always the red one. It is the green suite that checks the wrong revision, depends on unstable data or never observes the business output.
The demo configuration passes while minimums, maximums, incompatibilities, missing data and historical states remain untested.
Control: Build fixtures from equivalence classes, boundaries, known failures and real support cases.
A visual comparison detects pixels but cannot prove option identity, price provenance, BOM quantity or accessible meaning.
Control: Pair visual evidence with structured state, calculation and downstream assertions.
Shared catalogue or account records are edited, making failures irreproducible and expected results uncertain.
Control: Use versioned, isolated fixtures with explicit source revisions and controlled setup.
Intermittent synchronization, data and environment failures are hidden until a real customer experiences them.
Control: Classify, quarantine with ownership, diagnose and remove the cause before the test regains release authority.
A scan passes while keyboard, focus, announcements, canvas alternatives and real assistive-technology journeys fail.
Control: Combine automated detection with manual assessment and inclusive user evaluation.
QA creates real leads, quotes, orders, emails or operational records that cannot be distinguished from business activity.
Control: Use governed test identities and data, safe destinations, clear markers and cleanup or retention rules.
A PDF, screenshot or test report cannot prove which code, catalogue, price list, asset or integration contract was assessed.
Control: Attach release, environment, fixture and dependency revisions plus time and owner to every acceptance result.
The team cannot distinguish invalid configurations, pricing errors, delivery failures or performance regressions until users report them.
Control: Define release and business observability alongside the test plan, including owner and response path.
Vendor QA due diligence
Ask every vendor against the same product and output. Require exact evidence, owners and revision identity instead of “fully tested” or “works on all devices.”
Which real product, account and output form the common acceptance fixture?
How are product, price, asset, document, environment and integration revisions identified in results?
Which tests cover defaults, dependencies, exclusions, dimensional limits and derived values?
How are invalid states tested through both the interface and direct API or saved-state input?
How are visible 3D parts and materials reconciled with configuration IDs?
Which known-price cases are approved line by line and who owns each price source?
How are quotes, revisions, validity, tax, language and document snapshots accepted?
Which component, quantity, unit and dimension cases prove BOM or order outputs?
How are CRM, ERP, ecommerce and webhook failures, retries and duplicates tested?
Which roles, tenants, projects, files, exports and privileged actions have negative access tests?
What WCAG target and page or journey scope is accepted for accessibility evaluation?
Which accessibility checks are automated, manual and user evaluated?
Which browsers, devices, networks, products and scene sizes define the compatibility matrix?
Which lab and field performance measures are release gates?
How are fixtures isolated, reset and protected from uncontrolled changes?
How are flaky tests identified, owned, quarantined and restored?
Which changes trigger full, targeted or no regression suites, and who decides?
How are supported saved projects and earlier quotes tested after changes?
What evidence must exist before release, and where is it retained?
How are rollout, monitoring, support, rollback and post-release reconciliation tested?
Primary testing references
These official sources help define accessibility, browser testing, performance, security and 3D asset checks. The product owner still has to define the real catalogue, commercial and operational acceptance criteria.
The W3C recommendation with testable success criteria for making web content accessible across devices and user needs.
Official guidance on early evaluation, tools, conformance assessment, reports and the need for knowledgeable human review.
Official browser-testing guidance on user-visible behavior, isolation, resilient locators and controlled dependencies.
Official guidance for automated accessibility checks and their limits relative to manual and inclusive evaluation.
Current field-oriented guidance for loading, responsiveness and visual-stability quality signals.
A basis for testing web-application technical security controls and defining secure-development requirements.
Official tooling for applying machine-readable audit profiles to glTF assets, dimensions, geometry, materials, textures and use-case limits.
Product configurator testing FAQ
Continue the evaluation
Measure Core Web Vitals, staged runtime work, first useful product view, option response, GPU cost and long-session stability.
Open guideTest semantic controls, canvas alternatives, keyboard operation, status, complete processes and WCAG 2.2 evidence.
Open guideDesign and accept the full user task across controls, feedback, validation, pricing, review, mobile and accessibility.
Open guideTurn business, product, 3D, pricing, output and operational expectations into testable vendor requirements.
Open guideConnect QA to discovery, source data, ownership, delivery phases, launch and ongoing maintenance.
Open guideBuild decision tables, dimensional boundaries, derived-value cases and permanent rule regression evidence.
Open guideTest canonical state, contract schemas, concurrency, authorization, idempotent commands, events and channel journeys.
Open guideValidate source identity, runtime assets, material and node bindings, performance and revision safety.
Open guideCreate known-price ledgers, explain calculation provenance and preserve historical commercial meaning.
Open guideUse the accepted test pack to control catalogue changes, releases, saved projects and rollback after launch.
Open guideBring a real acceptance fixture