How to test an AI virtual try-on: 7 acceptance tests for your pilot

Before running the tests: freeze the scope, not the entire catalog

Choose a product family the team can review and include its real challenges: plain and printed garments, different constructions where in scope, references of varying quality, a product without sufficient data and an unavailable variant. There is no universal number of SKUs that makes a pilot representative. Record why each case was included and which categories were left out.

Identify the versions of the theme, component, catalog and settings. In Provei, Store experience distinguishes previews from published changes, including partial publication when one part fails. Seeing a setting in the editor does not prove the page used in the pilot received the same version. Check the page in the authorized environment after the change.

Assign review responsibilities by role: the product or design team assesses the garment's visual identity; the catalog team checks associations; the team maintaining the store verifies variants and the purchase journey; the data team checks how events are interpreted. The person running the tests may cover several roles, but must record who owns each decision. Vendor and store need to agree in advance on required behaviors, including those that depend on integration.

For each case, write down the expected result before generating the output. Use four record statuses: passed, failed, not run or not applicable, always giving a reason for the last of these. A test blocked by missing access or materials does not pass simply because no error was observed.

1. Visual fidelity: is it still the same garment?

Prepare: for each pilot SKU, choose the approved reference and list the visible details that must not disappear: print placement, paneling, relative length, fastening, neckline or another element that defines the garment. Do not use the image to infer fabric composition, fabric weight or stretch. You are assessing the visual information presented.

Run: combine the reference with synthetic test materials accepted by the vendor and compare input and output side by side. If repeated generation is part of the plan, define that beforehand and preserve problematic results too. Selecting only the best image conceals variability and weakens the acceptance review. Record problems in the input reference separately from changes introduced in the visualization.

Expected result: the product team recognizes the decisive elements and can identify the representation's limitations. A printed T-shirt cannot be evaluated by silhouette alone; the design and its placement matter. A structured garment cannot pass just because the color looks similar. Account for differences in screens and lighting without treating them as permission to depict a different product.

Critical failure: the visualization changes, removes or invents a detail capable of altering the purchase decision, or is presented as an exact physical reproduction of fit. For size comparison, Provei's help guide states that the image is illustrative and emphasizes differences to make comparison easier. It is not a ruler for measuring the garment or body.

Acceptance evidence: case ID, test SKU, reference version, output identifier and an objective observation about each specified detail. Archive only approved test materials, without customer photos. If the requirement cannot be assessed with those materials, record the limitation; do not claim the pilot proved fidelity on real people.

2. Catalog: is the page using the correct input?

Prepare: map the product page, catalog identifier and approved reference photo. Include an item with complete data, one without a suitable reference and one whose association needs checking. This test examines the catalog data feeding the experience; selection changes during the session are covered in the next test.

Run: open each page and compare the item loaded in the try-on with your prepared mapping. Make a controlled reference or association update in the authorized environment, record the version and check the page again after the prescribed update procedure. Observe whether ineligible products have no try-on experience or receive an appropriate explanation, according to the agreed scope.

Expected result: product, image and association match the approved catalog data. The behavior of an incomplete item is explainable and does not silently reuse the last valid product. Provei's import-by-link workflow can finish with partial failures and instructs users to review products after importing. A completion status therefore does not replace checking the pilot items.

Critical failure: a page opens another product, a change does not reach the experience without that being made clear, or an old reference is treated as current. Do not fix this type of problem by choosing a visually better generation: the source of the problem is the association or update.

Acceptance evidence: test page reference, relevant IDs, source image version, update date and readback after the change. If you cannot obtain the input's identity, ask the vendor for traceable evidence. Missing access is an outstanding issue, not proof that the association is correct.

3. Variant and purchase: does the selection reach its destination?

Prepare: use a test product with distinguishable variants and an unavailable selection where the environment allows. Define in advance whether the integration should add to the cart or redirect to the product page. Do not require direct cart addition from an integration whose contracted behavior is a redirect.

Run: select a variant, open the try-on and check its identity. Change the selection as the workflow permits, including before starting a new generation, and observe whether the result and purchase action make clear which selection they belong to. Continue the purchase journey without placing an order and inspect the test environment's cart: product, variant, size and quantity. Also follow the path for a selection with unknown stock or no availability, according to your prepared cases.

Expected result: an old result and a new selection are not mixed together. An image of the previous variant must remain identified as previous or be explicitly replaced. What reaches the cart matches what the person selected; when the destination is the product page, the interface explains that the purchase continues there and does not claim the item has already been added.

Provei's documented journey distinguishes cart addition from return to the page according to the platform. The cart troubleshooting guide also covers an inconclusive response: the item may or may not have been added. In that case, checking the cart before trying again prevents duplication. Do not treat the end of a waiting period as permission to repeat the action blindly.

Critical failure: the wrong variant or size at the destination, an unintended increase in quantity, an unavailable item presented as a confirmed purchase or a success message that contradicts the cart. Evidence: the sequence of selections and a sanitized readback of the final state, without creating a real order. The test ends with the behavior of the purchase action, not payment processing.

4. Sizing: does guidance use the right chart when it is in scope?

Prepare: if the contract includes visualization only, record not applicable — sizing guidance out of scope. That is not a sizing approval. If it includes a chart, recommendation or comparison, identify the chart version, garment type, applicable sizes and interpretation of each column: body, flat garment width, circumference or length.

Run: follow the contracted features using entirely fictional profiles defined for the test and unrelated to real people. Include the relevant scenarios: key measurements completed, one body region without data, a between-sizes situation, an unavailable size and no suitable option. The team responsible for garment cut must describe the expected behavior and rationale before execution; do not invent a body measurement or ease allowance to force a particular suggestion.

Expected result: the displayed chart belongs to the product and preserves its measurement basis. The recommendation explains its limitations, and the selected alternative does not erase the recommended size's identity. The current Find your size documentation provides for different results, such as a chart-based suggestion when stock information is missing and the closest size when there is no ideal match. The suggestion must not be interpreted as certainty of fit or availability.

In Provei, also check the association and applicable sizes. Product fit adjustments affect its recommendation, but the guide and comparison continue to use the chart. The team must know which configuration it is reviewing, rather than assume a correction has propagated throughout the journey.

Critical failure: an incorrect chart or garment type, confusion about the measurement basis, a suggestion without sufficient data presented as reliable or an image used as certification of physical fit. Evidence: chart version, fictional scenario, expected interpretation and observed text output. Do not record real measurements or turn this functional test into an accuracy claim for the entire customer base.

5. Mobile and accessibility: can users complete and exit the journey?

Prepare: choose devices and browsers based on the environments the store intends to support. Record the model, operating system, browser and version. Viewport emulation helps review layout, but does not replace checking the file picker, permissions and returning to the browser on a real device. Do not describe an emulator test as validation on a physical iPhone or Android device.

Run: enter through the product page, open the try-on and upload permitted synthetic material. If the camera and photo gallery are part of the workflow, check both inputs with suitable test materials; do not improvise with a customer photo. Cancel selection, deny camera permission, return from the gallery, wait for processing, view the result and close the window. Also test the keyboard, focus order and zoom for essential actions.

Expected result: canceling does not trap the user; denying camera access offers a path consistent with the scope; uploading, waiting, errors and results are understandable. Continue, back, close and buy buttons remain accessible with the keyboard open, zoom enabled and the store's floating elements present. On closing, the page retains enough context to continue the purchase journey. Provei's journey help guide distinguishes uploads on mobile and desktop; check the behavior actually available in the pilot configuration.

If waiting time is a mandatory criterion, set the acceptable budget in advance, separate uploading from processing and record the connection conditions. Do not turn the time observed in a single run into a store promise. The goal here is to determine whether the person understands the status and can act, including when the journey takes longer than expected.

Subcase: the store page before opening the try-on. In an authorized environment, compare the same page and product with the integration enabled and disabled, keeping device, browser, network, cache and other scripts comparable. Define acceptable regression limits in advance, repeat the measurements and record the conditions. Check loading, responsiveness to interactions and layout shifts on the page itself, not just inside the try-on window. Web Vitals guidance separates loading, interactivity and visual stability; a laboratory test does not prove that field metrics pass. Do not confuse this integration overhead with the time needed to generate an image.

Critical failure: being unable to close the window or reach an essential action, trapped focus with no exit, a covered control, loss of the selection without warning or a host-page regression beyond the previously agreed limit. Evidence: the exact environment, measurement conditions and repeated runs with and without the integration, the steps followed and sanitized screenshots of the states, including errors and closing. A single screenshot of the result does not cover the journey.

6. Failures and data: is the error handled without creating another risk?

Prepare: agree with the vendor on safe ways to trigger errors in the test environment: an unsupported file, a file above the documented limit, a network interruption and simulated unavailability. If testing credit balance or quota, use a test state provided for that purpose; do not exhaust credits or interrupt a production store. If there is no safe way to simulate a case, record it as not run.

Run: trigger one failure at a time, read the message, try the prescribed recovery and check whether the result corresponds to the new attempt. During processing on an unstable network, observe whether the system keeps waiting, completes or explains the failure; do not assume the request was canceled. Provei documents different messages for rejected photos, limits and connection issues, and a separate path for running out of credits. A generic poor-photo message should not conceal service unavailability.

In the same test, check the data boundaries that the agreed configuration is supposed to preserve: what the workflow requests, where the fictional profile reappears, how it is reset and which data appears in the evidence available to the team. Use separate test sessions to check that a profile does not improperly appear in another session. Do not share credentials, keys, tokens, customer images or complete copies of technical logs. Record only necessary, sanitized evidence.

Expected result: the error has an understandable cause and next step; a new attempt does not silently retrieve an old product or duplicate a purchase action; data does not appear outside its intended context. Provei's privacy and security help guide describes the store's responsibilities and related resources. Checking a configuration's behavior is not a security audit or validation of LGPD compliance. Legal or data processing questions require a separate assessment by those responsible.

Critical failure: exposure of data from another session, a credential in shareable evidence, fictitious success after an error or recovery that repeats a purchase without checking the state. Stop the case, restrict circulation of the evidence and contact the responsible teams. Evidence: the condition triggered, the exact message without personal data, the final state and the support ticket reference. Recording that support replied is not enough; the corrected case must be rerun before the blocker is closed.

7. Measurement: does each number match what happened?

Prepare: write a known sequence of actions for the test and define which should create a record: opening, starting an upload, completing or failing, receiving guidance, choosing an alternative and continuing the purchase journey, as applicable to the scope. These are editorial stage labels, not guaranteed event names in any product. Agree on how the implementation will let you verify the sequence without recording personal data.

Run: follow the sequence and compare it with the technical evidence provided and the metrics it should feed. Include a failed attempt, a resumed journey and a deliberate repeat. Check that the distinction between attempt and completion remains intact and that the repeat is handled as defined. When the system excludes test traffic from a particular screen, check through the appropriate evidence; do not generate external traffic just to increase a dashboard number.

Expected result: the team can explain the unit, period, time zone and rules for each metric, along with any delay. In Provei's metrics documentation, events, people and visits are distinct units. The funnel counts visits; try-ons count events. The same person repeating a try-on does not mean a new person, and dividing counts with different units can produce a meaningless rate.

Also check what cart and revenue mean. The help guide documents additions associated with try-on use or a recommendation, including through the button on the same product's page. Without a Google Analytics connection, estimated revenue is an estimate based on carts, not confirmed sales. Do not reconcile it as if it were the store's financial records, or add revenue across features without checking the overlap rules.

Critical failure: recording an attempt as a success, duplicating a completion outside the defined rule or calling a click or estimate a paid order. Another blocker to interpretation is concluding that the try-on caused more sales simply because people who used it bought more. People who choose to use the feature may already be more interested. That comparison describes an association; it does not isolate a causal effect.

Evidence: the known test sequence, metric definitions, sanitized records and an explained reconciliation. Acceptance may establish that measurement is consistent within the verified scope, not that the product increased conversion. If the next question concerns incremental impact, it requires its own evaluation design, such as a well-planned randomized comparison where feasible, with criteria and analysis defined in advance. Do not invent statistical significance, a minimum sample size or an expected gain to close this pilot.

How to decide without hiding a problem in an average

Do not assign scores to offset different types of risk. A good image does not compensate for the wrong variant in the cart, and a complete report does not compensate for improper data exposure. Treat any critical failure in a mandatory journey as a blocker to expansion until there is a correction and a documented rerun of the case.

When a problem is confined to a nonessential category or integration, an alternative may be to reduce the pilot to what was actually verified. That requires being able to isolate the affected part, remove the corresponding promise and record the limitation explicitly. If reliable isolation is not possible, do not declare partial approval.

Approve means accepting the scope that passed the mandatory cases, with known limitations. Fix and rerun means keeping the blocker open with a responsible role and a closure criterion. Stop means a mandatory requirement was not met or could not be demonstrated. Missing evidence for a mandatory case cannot be relabeled as a qualified approval.

After a change, rerun the failed case and the journeys it could affect. Changing a catalog reference requires another identity check; changing the theme's selector requires another variant and cart check. The acceptance record must identify the corrected version. Evidence from the previous version does not automatically approve the next one.

A useful pilot leaves a decision someone else can verify

At the end, the team should be able to show which version was assessed, which cases were run, what happened and why the decision was made. A collection of images without identified inputs, variant states or stop criteria does not provide that traceability.

If purchasing criteria are still unresolved, return to the guide on how to choose a virtual try-on for your online store. If the main outstanding issue concerns the garment reference, explore the review of product images and variants. Acceptance does not need to resolve the entire operation at once: it needs to make clear what is ready, what is missing and what cannot yet be promised.