Die Frage kommt fast immer im gleichen Moment: Der Umbau ist besprochen, der Termin steht, und dann fragt jemand, ob man das vorher nicht einmal durchspielen kann. Kann man. Nur ist ein Klon des Shops noch kein Testsystem, sondern erstmal ein zweiter Shop, der genau dasselbe tut wie der erste. Inklusive Auftragsübergabe an die Warenwirtschaft, inklusive Rechnungsmail, inklusive Versandlabel.
Wir haben das mehr als einmal übernommen: Ein Staging steht schon da, jemand hat es vor zwei Jahren aufgesetzt, und niemand traut sich, dort eine Bestellung abzuschicken. Aus gutem Grund. Denn keiner weiß mehr, welche Zugangsdaten in dieser Instanz noch auf die Live-Systeme zeigen.
Was ein Klon von sich aus mitbringt
Eine Kopie enthält die Konfiguration des Originals. Das ist ja der Zweck. Damit enthält sie auch den API-Key des Zahlungsdienstleisters, das Token für die Warenwirtschaft, die Zugangsdaten des Mailservers, die Kundennummer beim Versanddienstleister und, falls Marktplätze angebunden sind, die Autorisierung für Amazon und eBay.
Der erste Testkauf läuft dann sauber durch. Zahlung wird autorisiert, echtes Geld. Der Auftrag geht über die Schnittstelle in die Warenwirtschaft und landet dort neben den echten Aufträgen des Tages. Falls die Kommissionierung morgens nach Datum sortiert, ist er mittags gepackt.
Besonders unangenehm sind die Fälle, in denen es nicht sofort auffällt. Ein Testauftrag mit einer Adresse aus dem Adressbuch fällt niemandem auf. Er wird bezahlt gemeldet, verpackt, verschickt. Erst die Reklamation klärt die Lage.
Die Warenwirtschaft braucht eine eigene Datenbasis, nicht nur ein anderes Kennzeichen
Der Reflex ist, die Testaufträge im ERP zu markieren und dort auszusortieren. Ein Auftragskennzeichen, ein Filter, fertig. Das trägt nicht. Sobald ein Auftrag in der Live-Warenwirtschaft liegt, greifen die Automatismen: Ereignisaktionen in PlentyONE, Workflows in der JTL-Wawi, Statusregeln in Shopware. Diese Regeln fragen nach Zahlstatus und Versandprofil, nicht danach, ob der Auftrag ernst gemeint war.
Bei JTL heißt das in der Praxis: eine zweite Wawi-Instanz auf einer eigenen SQL-Datenbank, ein eigener JTL-Connector, ein eigener Shop-Kanal. Wer die Live-Datenbank kopiert – und das ist der schnelle Weg, weil man dann echte Artikelstämme und echte Bestände hat –, muss danach in der Kopie systematisch aufräumen: Mailkonten entfernen, den FinTS-Bankzugang löschen, Versandarten auf ein Testkonto umstellen, Marktplatz-Anbindungen deaktivieren, Workflows durchgehen. Ein Workflow, der bei Auftragsfreigabe eine Bestätigung an die Kundenadresse schickt, feuert in der Kopie mit denselben echten Adressen.
Bei PlentyONE ist die Ausgangslage anders, weil die Instanz gehostet ist und ein Testsystem als eigene Instanz kommt. Der Aufwand verschiebt sich dorthin, wo die Daten fehlen: Die Kopie ist nicht tagesaktuell, Bestände weichen ab, und die Ereignisaktionen unter Einrichtung › Aufträge › Ereignisaktionen muss man Zeile für Zeile prüfen, bevor der erste Testauftrag einläuft. Es reicht nicht, die offensichtlichen Mailaktionen abzuschalten. Die interessanten sind die, die Belege erzeugen und Nummernkreise weiterzählen.
Shopify löst das über einen Development Store. Der ist schnell da und kostet nichts, hat aber genau die Grenze, an der es unbequem wird: Ein Development Store ist nicht der Live-Shop mit seinen gewachsenen Metafeldern, Kundendaten und App-Konfigurationen. Was man dort testet, ist die Mechanik, nicht der Bestand.
Zahlungsmodule: Testkeys sehen aus wie Livekeys, fast
Die Trennung ist hier vergleichsweise einfach, weil die Anbieter mitspielen. Stripe-Testschlüssel beginnen mit sk_test_ und pk_test_, PayPal hat eine eigene Sandbox unter api-m.sandbox.paypal.com mit eigenen Client-Credentials, Mollie unterscheidet test_ und live_ im Key. Shopify bringt das Bogus Gateway mit, Shopify Payments einen Testmodus.
Die Fehler passieren an zwei Stellen. Erstens: Es wird nur der Key getauscht, nicht die Webhook-URL. Dann autorisiert das Testsystem gegen die Sandbox, die Statusrückmeldung geht aber an den Live-Shop, und dort passiert Unerklärliches. Zweitens: Ein Zahlungsmodul ist umgestellt, drei sind es nicht, weil der Shop fünf Zahlarten anbietet und beim Test nur eine benutzt wird. Vorkasse und Rechnung fallen dabei besonders gerne durch, weil sie keinen Key haben und deshalb nicht auf der Liste stehen. Genau die erzeugen aber in der Warenwirtschaft einen Auftrag.
Eine Meldung wie „Invalid API Key provided" im Log ist der freundliche Fall. Der unfreundliche ist der, bei dem alles funktioniert.
Versand ist die Stelle, an der es teuer wird
Ein Label ist ein kostenpflichtiger Vorgang und in vielen Fällen nicht einfach zurückzuholen. DHL bietet eine Sandbox mit eigener Abrechnungsnummer, andere Dienstleister haben Testendpunkte, manche haben keine. Wenn kein Testzugang existiert, bleibt nur, das Versandmodul im Testsystem konsequent zu deaktivieren und die Übergabe an dieser Stelle als ungetestet zu behandeln.
Das ist unbefriedigend, und wir sagen es trotzdem klar: Es gibt Konstellationen, in denen der Weg vom Auftrag bis zum Label nur auf dem Livesystem vollständig prüfbar ist. Dann plant man einen kontrollierten Echttest mit einer internen Adresse, zu einer Zeit, in der jemand zusieht, und mit dem Wissen, dass dieser Auftrag anschließend storniert werden muss.
Alles, was nach draußen telefoniert
Mailversand zuerst. In Shopware 6 genügt in der .env ein MAILER_DSN=null://null oder ein lokaler Catcher, der alles einsammelt und nichts weiterleitet. Das ist die billigste Versicherung im ganzen Aufbau. Wer stattdessen nur die Absenderadresse ändert, hat nichts gewonnen.
Dann die Nummernkreise. Ein Testsystem, das seine Auftragsnummern in derselben Reihe wie der Livebetrieb zieht, produziert Doppelungen, sobald man Daten zurückspielt. Ein Präfix im Testsystem, in Shopware unter Einstellungen › Shop › Nummernkreise, macht später jeden Testauftrag auf einen Blick erkennbar.
Weiter: Newsletter-Anbindung raus, Tracking-IDs leeren oder auf eine eigene Property legen, Produktfeeds für Preissuchmaschinen und Retargeting abschalten. Und die Instanz selbst hinter Basic Auth plus X-Robots-Tag: noindex legen, sonst steht das Staging in vier Wochen im Index und Kunden bestellen dort. Das passiert häufiger, als man denkt.
Zuletzt die geplanten Aufgaben. In Shopware laufen sie über bin/console scheduled-task:run; ein Klon, der den Cron mitbringt, importiert weiter Bestände und schiebt weiter Bestellungen. Entweder abschalten oder auf die Testschnittstelle umbiegen. Beides ist eine Entscheidung, kein Zufall.
Der Abnahmetest für das Testsystem selbst
Bevor der erste fachliche Test läuft, prüft man das Testsystem gegen sich selbst. Eine Bestellung mit jeder Zahlart, danach die Kontrolle: Liegt der Auftrag in der Test-Warenwirtschaft und nirgends sonst. Ist eine Mail im Catcher und keine im echten Postfach. Steht eine Transaktion in der Sandbox und keine im Live-Konto. Existiert kein Label. Zählt der Live-Nummernkreis unverändert weiter.
Das dauert eine halbe Stunde und ersetzt später die Diskussion darüber, ob ein seltsamer Auftrag aus dem Test kam.
Was danach kommt
Der Aufbau ist nicht das Problem. Die Drift ist es. Ein Testsystem, das im Januar korrekt getrennt war, hat im Juni einen Live-Key drin, weil jemand für eine schnelle Prüfung eine Konfiguration aus der Produktion kopiert hat. Deshalb gehört zu jedem Testsystem eine kurze Liste der abweichenden Werte, versioniert, und die Regel, dass ein Rückspielen von Livedaten immer das Nachziehen dieser Liste bedeutet.
Offen bleibt die Frage der Echtdaten. Ein Testsystem mit anonymisierten Kunden ist datenschutzrechtlich sauber und versteckt zuverlässig die Fehler, die nur bei echten Adressen, Umlauten und alten Bestandsdatensätzen auftreten. Wir haben dafür keine Lösung, die in jedem Projekt passt. Man entscheidet es pro System, dokumentiert die Entscheidung, und begrenzt den Zugriff auf die Instanz entsprechend.
KI-generierter Inhalt.