Multishop-Tests scheitern, wenn jeder Shop gleich aussieht. Teilen zwei Shops identische Einstellungen und Testwerte, kann ein versehentlicher Schreibvorgang im falschen Umfang unbemerkt bleiben. Die neuen Multishop-Arbeiten in Version 9.2 lassen sich am besten mit bewusst unterschiedlichem Shop-Verhalten bewerten.

Eine Back-Office-Erweiterung kann eine Seitenmigration optisch überstehen und dennoch funktional scheitern. Ihr Feld kann erscheinen, aber nie gespeichert werden. Ihre Tabellenspalte kann Werte anzeigen, während Filter die falsche Abfrage nutzen. Ihr Navigationslink kann für einen Administrator funktionieren und für gewöhnliche Mitarbeitende scheitern.

Ein Feature-Flag verändert den getesteten Codepfad. Zwei Tester können dieselbe PrestaShop-Version ausführen, scheinbar dieselbe Back-Office-Seite öffnen und dennoch unterschiedliche Implementierungen testen. Ohne ein Flag-Verzeichnis können ihre Ergebnisse widersprüchlich wirken.

Eine Umgebung für einen Release Candidate sollte realistisch genug sein, um Inkompatibilitäten aufzudecken, und so weit isoliert, dass ein Fehler nicht zu einer echten Bestellung, Lieferung oder Kampagne werden kann. Das Kopieren einer Produktionsdatenbank unter einen anderen Hostnamen schafft diese Isolation allein nicht.

Eine KI-Integration hat zwei unterschiedliche Aufgaben: zu interpretieren, was eine Person möchte, und einen autorisierten Shop-Vorgang auszuführen. Beide hinter einer Chat-Oberfläche zu verbinden, beseitigt die Grenze zwischen ihnen nicht. Entwickler sollten diese Grenze im Entwurf und in den Testnachweisen sichtbar machen.

Der nützlichste Shop-Assistent ist einer, dessen Antwort Sie überprüfen können. Fragt ein Händler nach „aktuellen problematischen Bestellungen“, muss der Assistent sowohl den Zeitraum als auch die Bedeutung eines Problems interpretieren. Eine flüssige Antwort kann diese Annahmen verbergen, wenn die Anfrage nicht präzise formuliert ist.

Eine sinnvolle erste Integration von Extra Properties verfolgt ein Feld von seiner Definition bis zu jeder Oberfläche, die es verwendet. So lassen sich wichtigere Probleme erkennen als durch die gleichzeitige Registrierung vieler Felder: Werte, die im falschen Shop gespeichert werden, an der falschen Stelle erscheinen oder bei einem Vorgang im Modullebenszyklus verloren gehen.

Ein zusätzliches Feld ist leicht angefordert und überraschend schwer sauber definiert. Ein Händler bittet um eine „Lieferantenreferenz“, doch die Agentur muss noch wissen, ob diese zu einem Produkt, einer Kombination, einer Bestellung oder einer Lieferantenbeziehung gehört. Die falsche Antwort erzeugt Mehrdeutigkeit überall, wo der Wert wiederverwendet wird.

Checkout-Tests sollten beweisen, dass die endgültige Bestellung den letzten gültigen Kundenentscheidungen entspricht. Eine grüne Bestätigungsseite reicht nicht, wenn der falsche Versanddienstleister, eine falsche Adresse, Steuerhöhe oder ein falscher Zahlungszustand im Backoffice ankommt.

Ein Checkout auf einer Seite verändert, wo Kunden Entscheidungen treffen. Kontaktdaten, Versandwahl und Zahlung müssen sich nicht mehr wie getrennte Ziele anfühlen. Sie werden zu verbundenen Teilen einer Kaufsitzung, wobei Änderungen in einem Bereich einen anderen beeinflussen können.