Les tests multiboutiques échouent lorsque toutes les boutiques se ressemblent. Si deux boutiques partagent des réglages et des valeurs de test identiques, une écriture accidentelle dans le mauvais périmètre peut passer inaperçue. Les nouveaux travaux multiboutiques de la version 9.2 s’évaluent mieux avec des comportements volontairement différents selon la boutique.

Une extension du Back Office peut survivre visuellement à une migration de page tout en échouant fonctionnellement. Son champ peut apparaître sans jamais être enregistré. Sa colonne de grille peut afficher des valeurs tandis que les filtres utilisent la mauvaise requête. Son lien de navigation peut fonctionner pour un administrateur et échouer pour le personnel ordinaire.

Un indicateur de fonctionnalité change le chemin de code testé. Deux testeurs peuvent exécuter la même version de PrestaShop, ouvrir ce qui semble être la même page du Back Office et pourtant tester des implémentations différentes. Sans inventaire des indicateurs, leurs résultats peuvent sembler contradictoires.

Un environnement de version candidate doit être suffisamment réaliste pour révéler les incompatibilités et suffisamment isolé pour qu’une erreur ne puisse pas devenir une vraie commande, une expédition ou une campagne. Copier une base de données de production vers un autre nom d’hôte ne suffit pas à assurer cette isolation.

Une intégration d’IA a deux fonctions distinctes : interpréter ce qu’une personne souhaite et exécuter une opération autorisée dans la boutique. Les réunir derrière une interface de discussion ne supprime pas la frontière entre elles. Les développeurs doivent rendre cette frontière visible dans la conception et dans les preuves issues des tests.

L’assistant de boutique le plus utile est celui dont vous pouvez vérifier la réponse. Si un marchand demande les « commandes récentes présentant un problème », l’assistant doit interpréter à la fois la période et la notion de problème. Une réponse fluide peut masquer ces hypothèses si la demande n’est pas formulée précisément.

Une première intégration utile d’Extra Properties consiste à suivre un champ depuis sa définition jusqu’à toutes les interfaces qui l’utilisent. Cela permet de détecter des problèmes plus importants qu’en enregistrant de nombreux champs d’un seul coup : des valeurs enregistrées dans la mauvaise boutique, affichées au mauvais endroit ou perdues lors d’une opération du cycle de vie du module.

Un champ supplémentaire est facile à demander et étonnamment difficile à bien définir. Un marchand demande une « référence fournisseur », mais l'agence doit encore savoir si cette référence appartient à un produit, une déclinaison, une commande ou une relation avec un fournisseur. Une mauvaise réponse crée de l'ambiguïté partout où la valeur est réutilisée.

Les tests du checkout doivent prouver que la commande finale correspond aux derniers choix valides du client. Un écran de confirmation vert ne suffit pas si le mauvais transporteur, la mauvaise adresse, le mauvais montant de taxe ou le mauvais état de paiement arrive dans le Back Office.

Un checkout sur une seule page change l'endroit où les clients prennent leurs décisions. Coordonnées, choix de livraison et paiement n'ont plus besoin de ressembler à des destinations distinctes. Ils deviennent les parties reliées d'une même session d'achat, où les changements d'un domaine peuvent en affecter un autre.