Las pruebas multitienda fallan cuando todas las tiendas parecen iguales. Si dos tiendas comparten ajustes y valores de prueba idénticos, una escritura accidental con el alcance equivocado puede pasar inadvertida. El nuevo trabajo multitienda de la versión 9.2 se evalúa mejor con comportamientos deliberadamente distintos por tienda.

Una extensión del Back Office puede sobrevivir visualmente a una migración de página y aun así fallar funcionalmente. Su campo puede aparecer pero no guardarse nunca. Su columna de cuadrícula puede mostrar valores mientras los filtros usan la consulta equivocada. Su enlace de navegación puede funcionar para un administrador y fallar para el personal habitual.

Un indicador de funcionalidad cambia la ruta de código que se está probando. Dos testers pueden ejecutar la misma versión de PrestaShop, abrir lo que parece la misma página del Back Office y aun así probar implementaciones distintas. Sin un inventario de indicadores, sus resultados pueden parecer contradictorios.

Un entorno de versión candidata debe ser lo bastante realista para revelar incompatibilidades y estar lo bastante aislado para que un error no pueda convertirse en un pedido, envío o campaña reales. Copiar una base de datos de producción a otro nombre de host no logra por sí solo ese aislamiento.

Una integración de IA tiene dos trabajos distintos: interpretar lo que quiere una persona y ejecutar una operación autorizada en la tienda. Combinarlos tras una interfaz de chat no elimina el límite entre ambos. Los desarrolladores deben hacer visible ese límite en el diseño y en las pruebas obtenidas de los tests.

El asistente de tienda más útil es aquel cuya respuesta puede comprobar. Si un comerciante pregunta por «pedidos recientes con problemas», el asistente debe interpretar tanto el período como el significado de un problema. Una respuesta fluida puede ocultar esas suposiciones si la solicitud no es precisa.

Una primera integración útil de Extra Properties sigue un campo desde su definición hasta todas las interfaces que lo utilizan. Así se detectan problemas más importantes que al registrar muchos campos a la vez: valores que se guardan en la tienda equivocada, aparecen en el lugar incorrecto o desaparecen durante una operación del ciclo de vida del módulo.

Un campo adicional es fácil de pedir y sorprendentemente difícil de definir bien. Un comerciante solicita una «referencia de proveedor», pero la agencia aún debe saber si pertenece a un producto, una combinación, un pedido o una relación con un proveedor. Una respuesta equivocada crea ambigüedad allí donde se reutiliza el valor.

Las pruebas del checkout deben demostrar que el pedido final coincide con las últimas elecciones válidas del cliente. Una pantalla de confirmación verde no basta si llegan al Back Office un transportista, dirección, importe de impuestos o estado de pago incorrectos.

Un checkout de una sola página cambia dónde toman decisiones los clientes. La información de contacto, las opciones de entrega y el pago ya no tienen que parecer destinos separados. Se convierten en partes conectadas de una misma sesión de compra, donde los cambios de un área pueden afectar a otra.