Multistore testing fails when every shop looks the same. If two shops share identical settings and fixture values, an accidental write to the wrong scope can pass unnoticed. The new 9.2 multistore work is best evaluated with deliberately different shop behavior.

A Back Office extension can survive a page migration visually and still fail functionally. Its field may appear but never save. Its grid column may show values while filters use the wrong query. Its navigation link may work for an administrator and fail for ordinary staff.

A feature flag changes the code path being exercised. Two testers can run the same PrestaShop version, open what appears to be the same Back Office page and still test different implementations. Without a flag inventory, their results may look contradictory.

A release-candidate environment should be realistic enough to expose incompatibilities and isolated enough that a mistake cannot become a real order, shipment or campaign. Copying a production database to another hostname does not achieve that isolation by itself.

An AI integration has two different jobs: interpreting what a person wants and executing an authorized store operation. Combining them behind a chat interface does not remove the boundary between them. Developers should make that boundary visible in the design and in the test evidence.

The most useful store assistant is one whose answer you can check. If a merchant asks for “recent problem orders,” the assistant must interpret both the time period and the meaning of a problem. A fluent answer can hide those assumptions unless the request is made precise.

A useful first Extra Properties integration follows one field from definition to every surface that uses it. This catches a more important class of problems than registering many fields at once: values that save in the wrong shop, appear in the wrong place or disappear during a module lifecycle operation.

An extra field is easy to request and surprisingly difficult to define well. A merchant asks for a “supplier reference,” but the agency still needs to know whether that reference belongs to a product, a combination, an order or a supplier relationship. The wrong answer creates ambiguity wherever the value is reused.

Checkout testing should prove that the final order matches the customer’s latest valid choices. A green confirmation screen is insufficient if the wrong carrier, address, tax amount or payment state reaches the Back Office.

A single-page checkout changes where customers make decisions. Contact information, delivery choices and payment no longer need to feel like separate destinations. They become connected parts of one buying session, with changes in one area potentially affecting another.