I work on Notice27, and one lesson from testing notice placement in WooCommerce is that “it appeared at checkout” is not a meaningful acceptance test.
A store can have a classic product template, a block-based cart, a shortcode checkout, extension-managed line items, translated routes, and customer order views—all in the same installation. Each surface has different rendering and state-change behaviour.
This is the practical test matrix I now use before treating a notice workflow as implementation-ready.
1. Map the real customer surfaces
Start with the routes that customers actually use:
- simple and variable product pages;
- mini-cart or cart drawer, if present;
- full cart;
- Classic Checkout and Checkout Block;
- order-pay and order-received routes;
- customer account order details;
- transactional email, if the implementation intentionally includes it.
Do not infer coverage from one route. A clean product-page result says nothing about a Checkout Block integration.
2. Separate Classic and Block paths
WooCommerce Blocks are not just a visual variation of the classic shortcode flow. They use different extension points and update behaviour. Treat these as separate test families:
| Surface | Minimum checks |
|---|---|
| Classic cart | initial render, quantity update, item removal, coupon update |
| Cart Block | initial hydration, quantity change, item removal, extension data refresh |
| Classic checkout | initial render, address change, validation error, payment-method change |
| Checkout Block | initial hydration, address change, validation state, payment-method change |
If a store supports both paths during a migration, both need evidence.
WooCommerce’s extension documentation is the right starting point for Block integrations: Extending the Cart and Checkout Blocks.
3. Build rows around facts, not ideal products
A useful matrix includes ambiguity and failure states:
- simple product with complete reviewed facts;
- variable product where variations resolve differently;
- variation selected, changed, and cleared;
- mixed cart with different product states;
- missing product or market fact;
- unsupported or unresolved language;
- merchant decision still awaiting review;
- stale configuration after a product edit.
The important result is not always “show the notice.” Sometimes the correct implementation result is a visible review-required state. Missing inputs should not silently become a legal conclusion.
4. Keep distinct decisions distinct
In the Notice27 workflow, the harmonised EU legal-guarantee notice and the separate GARAN durability label remain separate review paths. A decision about one does not establish eligibility or required use of the other.
Digital content, digital services, goods with digital elements, and software-update information also need their own classification and review. The software should preserve those distinctions rather than flattening them into one “covered” flag.
That is an implementation principle, not a claim that software can determine whether a specific transaction is legally in scope.
5. Test interaction, language, and accessibility together
For every approved row, exercise the state changes a customer can trigger:
- add the item from the product page;
- change a variation or quantity;
- remove and restore items;
- change billing or shipping country where relevant;
- switch storefront language;
- trigger validation errors;
- navigate by keyboard;
- zoom to 200%;
- repeat on a narrow viewport.
Long translations are especially good at revealing fragile layouts. Check that the notice does not obscure the price, variation controls, quantity input, add-to-cart action, order summary, or payment controls.
For accessibility expectations, use the WordPress Accessibility Coding Standards as a baseline, then test the actual theme and extension combination.
6. Record repeatable evidence
A screenshot alone is weak evidence. For each matrix row, record:
- WooCommerce and WordPress versions;
- active theme and relevant extensions;
- route and viewport;
- product or variation state;
- market and language inputs;
- expected result;
- actual result;
- reviewer and date;
- screenshot or short recording;
- unresolved questions.
This makes regressions easier to diagnose after theme, checkout, or merchandising changes.
A public implementation demo
I built a resettable Notice27 demo to make these states easier to inspect:
Open the fictional-product demo
It collects no payment and is intended for implementation evaluation. The workflow previews supplied notice assets across product, cart, Classic/Block checkout, and customer order views while keeping unresolved inputs visible for review.
Disclosure and scope: I work on Notice27. Notice27 is implementation software, not legal advice, certification, automatic national-law coverage, official approval, or a guarantee of compliance. A merchant and its advisers remain responsible for applicability under the relevant national law.
If you maintain WooCommerce stores, which matrix row has caused the most surprising failure in your stack?
