Add QA testing checklist

[tblivet]

Questions	Answers
Description?	Adds docs/qa/testing-checklist.md, a full test pass on the theme, cross-page checks, page by page, the back-office settings that change the front office, the native modules, overrides, accessibility and responsive checks. It is also meant to become the checklist for AI-assisted end-to-end tests.
Type?	new feature
BC breaks?	no
Deprecations?	no
Fixed ticket?	--
Sponsor company	@PrestaShopCorp
How to test?	--

[mattgoud]

Really nice piece of work, and unusually well sourced. I checked the derived lists against the repo rather than just reading them, and nearly everything holds up exactly:

• the $grid-breakpoints table matches src/scss/bootstrap/overrides/variables/_variables.scss value for value
• the hook columns in section 5 match config/theme.yml, including the two modules_to_unhook entries
• the (JS) marks map 1:1 onto the 10 entries in src/js/modules/ (blockcart.ts for ps_shoppingcart included)
• "four templates the default pass never renders" in 3.7 is exactly the four *-multishipment.tpl files
• the small_default vs category_default subcategory fallback in 3.2 is exactly what templates/catalog/_partials/subcategories.tpl does
• toasts "come from errors and from the quantity input rather than from add to cart": useToast is only consumed by errors.ts and useQuantityInput.ts
• "Save customization posts to the product URL": product-customization.tpl does action="{$product.url}"
• the accessories block "rendered without the container wrapper": need_container = false in product-accessories.tpl
• section 3 covers every page-level template, and the README anchors, port 8887 and npm test all resolve

One real gap plus a few factual corrections below. The gap is the only thing I'd call blocking, and it's a one-row fix.

blockwishlist is missing. It has a theme override in modules/blockwishlist (a displayCustomerAccount hook template and five modals: create, rename, delete, share, add-to-wishlist, login) and it's in global_settings.modules.to_disable in config/theme.yml. Section 5 says it lists "every native module Hummingbird overrides or hooks" and names only ps_advertising, ps_productinfo and ps_rssfeed as exclusions, and section 9 sets the rule "one entry per overridden module". So by the file's own contract blockwishlist needs a row, and the exclusion rationale doesn't apply to it: it isn't archived and it's actively maintained. It's also one of the larger overrides in the theme, so the flows behind it (add to wishlist from a miniature, create/rename/delete/share a list, the login modal for a guest, the account tile) are currently untested by this pass. It's disabled by default like ps_brandlist/ps_supplierlist, so it can carry the same note. 5.6 looks like the right place.

Nothing else is a blocker. Once blockwishlist has a row I'm happy to approve.

[tblivet]

Thanks @mattgoud for the review!

All corrections applied, except the one related to blockwishlist. We talked about it in the past and decided the module isn't stable: the theme disables it at install, and the overrides are due for removal, so testing them would mean testing code we intend to delete. Documented as an explicit exception in section 5, with section 9's rule amended to match. You were right that the file was silent on this, that's the gap, rather than the missing row.

Also dropped the hardcoded counts ("six layouts", "four templates") in favour of the directory and the glob: a count goes stale silently, which is what section 9 is meant to prevent.

[mattgoud]

Thanks @tblivet, all five corrections landed and I re-checked each one against the repo rather than just reading the diff:

• PS_DEV_MODE now names docker-compose-prestashop.yml and says the Flashlight file does not set it, which matches
• the second blockreassurance on displayFooterAfter is called out in 2.2
• the layouts sweep now takes templates/layouts/ as its source, and the content_only claim checks out: FrontController::getLayout() sets $layout = 'layout-content-only' when the request carries content_only
• /brands and /suppliers now point at the settings, and the location is right: display_suppliers and display_manufacturers live in PreferencesType, under Form/Admin/Configure/ShopParameters/General/, so Shop Parameters > General is correct, and it's marked (config)
• 3.9 and 5.7 both say the layout has to be switched first, marked (config)

The section 9 table keeps up with all of it: the new templates/layouts/ row, config/theme.yml narrowed to the selectable layouts, and the modules/ rule amended to admit the exception.

Dropping the hardcoded counts is the right call and better than what I reviewed against. I leaned on "exactly four multishipment templates" myself when I checked the file, and a glob is what section 9 is arguing for everywhere else, so it should not have been a number in the first place.

On blockwishlist, that works for me. My finding was never really "this module must be tested", it was that the file claimed to list every overridden module, named three exclusions, and then quietly dropped a fourth. You have fixed that: the exception is stated, the reason is given, the two paths it still owns are named (modules/blockwishlist/ and src/scss/prestashop/modules/_blockwishlist.scss, both present), and there is an exit condition saying what happens if the module stabilises. A documented exception with a way out is a better answer than a row for code you intend to delete.

Approving.