Test, Go-live und Optimierung

Test, Go-live und Optimierung

0:00 Ein Shop geht nicht an einem Tag live. Er geht in dem Moment live, in dem jemand sagen kann, woran der Start scheitern würde — und feststellt, dass es nichts Gravierendes mehr gibt. In diesem letzten Modul bauen wir genau das: eine Teststrategie mit prüfbaren Kriterien, die fachlichen Testfälle, die regelmäßig fehlen, vier technische Kontrollen in der richtigen Reihenfolge und einen Go-live mit Rückweg.

0:22 Am Ende steht die Abnahme des Shops, den wir in dieser Woche zusammen aufgebaut haben.

Test, Go-live und Optimierung

0:28 Das letzte Modul. Vier Kapitel: Teststrategie und Abnahme mit den Möglichkeiten für Testbestellungen. Dann die fachlichen Testfälle — zweiter Markt, B2B, Rabattkombinationen, Teillieferung, Retoure; Sie werden die ganze Woche wiedererkennen. Danach vier technische Kontrollen, die nach dem Start teuer werden. Und schließlich der Go-live mit Rollback und Hypercare.

0:50 In der Übung nehmen Sie den Shop von Steglicht ab und entscheiden begründet, ob er starten darf.

Teststrategie und Abnahme

0:57 Beginnen wir mit der Strategie. Und mit einer Reihenfolge, die banal klingt und selten eingehalten wird. Eine Teststrategie legt fest, was geprüft wird, womit und von wem — und woran der Abschluss erkennbar ist. Vier Angaben, die vor dem Testen stehen, nicht danach. Für die Praxis wichtig: Testbestellungen laufen über das Test Payment Gateway oder den Testmodus von Shopify Payments, und berechnet wird dafür nichts.

1:22 Sie können also so viel testen, wie Sie wollen. Die Begrenzung ist nicht das Geld, sondern die Zeit — und deshalb entscheidet die Auswahl der Testfälle über die Qualität der Abnahme. Vier Bereiche, die eine einzige Testbestellung gleichzeitig prüft. Den Checkout-Ablauf und die Bestellverarbeitung. Die Bestandsführung — wird korrekt abgebucht?

1:43 Die Versandkonfiguration mit dem richtigen Tarif. Und die E-Mail-Benachrichtigungen an Kundschaft und Team. Dazu die Steuerberechnung in den betroffenen Regionen. Das ist ein sehr gutes Verhältnis von Aufwand zu Erkenntnis: Eine Bestellung, fünf geprüfte Bereiche. Vorausgesetzt, jemand sieht sich hinterher tatsächlich alle fünf an — und nicht nur, ob die Bestellung angekommen ist.

2:08 Fünf Schritte. Benennen Sie je Bereich, was funktionieren muss, um zu starten. Formulieren Sie die Kriterien als prüfbare Sätze, nicht als Wünsche — der Checkout funktioniert gut ist kein Kriterium. Benennen Sie Prüfende, und zwar nicht nur das Team, das gebaut hat; wer baut, sieht seine eigenen Annahmen nicht. Bereiten Sie realistische Testdaten vor.

2:29 Und trennen Sie die Befunde in blockierend und nachrangig. Ein Hinweis zur Auswertung: Testbestellungen und simulierte Transaktionen erscheinen nicht in Auszahlungen und Reports. Der erste Punkt beschreibt den Unterschied zwischen Test und Abnahme: Geprüft wird, was gebaut wurde, statt was gebraucht wird. Der zweite ist der Klassiker aus Modul zwei: Getestet wird mit drei Beispielprodukten statt mit dem echten Katalog.

2:54 Der dritte ist eine Falle mit unmittelbarer Umsatzwirkung, und sie steht so in der Dokumentation: Solange der Testmodus aktiv ist, sind keine echten Bestellungen möglich. Wer ihn nach der Abnahme anlässt, hat einen stillen Shop. Und der vierte macht Befundlisten unbrauchbar: Es fehlt die Trennung in blockierend und nachrangig.

Fachliche Testfälle

3:14 Weiter mit den Fällen, die zählen. Und das sind selten die, die man zuerst testet. Fachliche Testfälle prüfen nicht die Oberfläche, sondern die Regeln dahinter: Steuersätze je Region, Versandtarife je Produktgruppe, Rabattkombinationen, B2B-Konditionen — und die Benachrichtigungen, die aus all dem entstehen. Der Unterschied zu einem Oberflächentest ist erheblich. Eine Seite, die richtig aussieht, kann den falschen Steuersatz berechnen.

3:41 Und ein Fehler in einer Regel wiederholt sich bei jeder Bestellung, während ein Darstellungsfehler nur unangenehm aussieht. Deshalb gehört die Regelprüfung nach vorn. Fünf Fälle, und Sie erkennen die ganze Woche wieder. Eine Bestellung in den zweiten Markt deckt Steuer, Währung, Versand und Sprache auf einmal ab — Modul vierzehn.

4:01 Eine Bestellung im Namen eines Unternehmens prüft Katalogpreis, Staffel und Zahlungsziel — Modul fünfzehn. Zwei Rabatte gleichzeitig prüfen die Kombinierbarkeit und den Endpreis — Modul neun. Eine Teillieferung aus zwei Standorten prüft Versandkosten und Benachrichtigung — Modul elf. Und eine Retoure mit Umtausch prüft die Reihenfolge, über die wir dreimal gesprochen haben.

4:25 Für B2B-Tests müssen Kundenkonten aktiv sein und ein Testunternehmen mit Standort bestehen. Vier Gründe, und der erste ist der wichtigste: Benachrichtigungen sind die einzige Nachricht, die jede Kundschaft sicher liest. Die Produktseite sieht vielleicht jeder Zweite, die Bestellbestätigung öffnen fast alle. Sie tragen Pflichtangaben und den Weg in den Support.

4:47 Sie sind je Sprache und Markt zu prüfen, nicht nur einmal — ein übersetzter Shop mit deutscher Bestätigung ist halb fertig. Und sie brechen still, wenn ein Theme oder eine App sie überschreibt. Genau deshalb gehören sie in jeden Testlauf. Der erste Punkt ist die verständliche Abkürzung: Getestet wird nur der Normalfall, weil er schnell geht — und der Normalfall funktioniert fast immer.

5:09 Der zweite ist eine Annahme statt einer Prüfung: Der zweite Markt wird angenommen statt bestellt. Der dritte ist eine halbe Prüfung: Die Bestellbestätigung wird gelesen, die Versandbenachrichtigung nicht — dabei ist die zweite die mit der Sendungsnummer. Und der vierte ist der teuerste Zeitpunkt für eine Entdeckung: Rabattkombinationen fallen erst im Betrieb auf, mit echten Bestellungen und echten Preisen.

Technische Kontrollen vor dem Start

5:32 Jetzt vier Kontrollen, die man vorher macht — weil sie nachher deutlich teurer werden. Vier Kontrollen stehen vor dem Start: Barrierefreiheit, Ladezeit, Einwilligung und Tracking sowie die Weiterleitungen. Sie haben eines gemeinsam — alle vier wirken sofort auf Reichweite, Recht oder Umsatz. Und alle vier sind nachträglich schwer zu korrigieren.

5:53 Eine fehlende Weiterleitung kostet Rankings, die man nicht zurückkauft. Ein Tracking ohne Einwilligung ist ein Rechtsproblem ab dem ersten Tag. Das ist der Grund, warum diese vier hier stehen und nicht in einer Liste für später. Fünf Schritte in genau dieser Reihenfolge. Durchlaufen Sie die Kaufstrecke mit der Tastatur und messen Sie die Kontraste — Modul acht.

6:15 Messen Sie Startseite, Produkt- und Kollektionsseite und halten Sie sie gegen Ihr Budget — Modul sieben. Prüfen Sie, ob ohne Einwilligung tatsächlich nichts geladen wird, und zwar im Netzwerkprotokoll, nicht am Banner. Testen Sie die Weiterleitungsliste gegen die alten Adressen. Und entfernen Sie den Passwortschutz erst, wenn alle vier sauber sind. Ohne entfernten Passwortschutz erreicht auch die Sitemap keine Suchmaschine.

6:41 Vier Abhängigkeiten. Eine Weiterleitung wirkt erst, wenn die alte Adresse einen 404 liefert — Sie können sie also nicht vorher vollständig prüfen. Ohne entfernten Passwortschutz lässt sich die Indexierung nicht prüfen. Tracking ohne Einwilligung ist ein Rechtsproblem, kein Messproblem — es lässt sich nicht mit besseren Zahlen heilen.

7:00 Und Barrierefreiheitsbefunde sind vor dem Start billiger zu beheben, weil noch niemand die Seite benutzt. Die Reihenfolge ist also keine Vorliebe, sondern ergibt sich aus der Technik. Der erste Punkt ist die häufigste Reihenfolgeverletzung: Der Passwortschutz fällt zuerst, die Prüfungen laufen danach — und in der Zwischenzeit indexiert Google, was da ist.

7:22 Der zweite ist Papierarbeit ohne Prüfung: Weiterleitungen werden angelegt, aber nie aufgerufen. Testen Sie zehn Stück von Hand. Der dritte ist der Unterschied zwischen Optik und Wirkung: Das Consent-Gate wird optisch geprüft, nicht im Netzwerkprotokoll. Und der vierte ist eine unvollständige Messung: Die Performance wird nur auf der Startseite geprüft — die Produktseite trägt aber den Umsatz.

Go-live und danach

7:45 Zum Abschluss der Start selbst. Und die Zeit danach, die in Projektplänen regelmäßig fehlt. Zum Go-live gehören drei Dinge: die Domainumstellung, ein benannter Rückweg und eine Phase erhöhter Aufmerksamkeit danach. Diese dritte heißt Hypercare und bedeutet ganz konkret: Für einen festgelegten Zeitraum schaut ein benanntes Team täglich auf Bestellungen, Fehler und Rückfragen.

8:08 Nicht gelegentlich, nicht bei Bedarf — täglich und benannt. Denn die ersten Tage produzieren die Erkenntnisse, für die man sonst Monate braucht. Und sie produzieren sie mit echten Kundinnen und Kunden, die man nicht warten lassen sollte. Vier Phasen, und die dritte ist die, die gerne wegfällt. Abnahme, Umschaltung, Hypercare, Regelbetrieb.

8:28 Interessant ist der Übergang von drei nach vier: Er sollte eine Entscheidung sein, kein Auslaufen. Also ein Termin, an dem jemand sagt, dass die Hypercare endet, weil die Kennzahlen stimmen und keine Häufungen mehr auftreten. Wenn diese Entscheidung fehlt, endet Hypercare dadurch, dass die Beteiligten anderes zu tun bekommen — meist nach zwei Tagen und meist zu früh.

8:51 Vier Dinge, täglich. Bestellungen, die hängen bleiben oder im falschen Status stehen — Sie erinnern sich an die drei Statusarten aus Modul zwölf. Fehlerhafte Versandtarife und Steuerbeträge in echten Bestellungen; im Test sieht man nicht alles. Supportanfragen, die sich häufen und damit auf eine Lücke zeigen — das ist das wertvollste Signal überhaupt, weil es aus der Wirklichkeit kommt.

9:15 Und die Kennzahlen gegen die Werte vor der Umstellung. Vier Blicke, zusammen zwanzig Minuten am Tag. Der erste Punkt ist ein Plan ohne Probe: Der Rückweg wird beschrieben, aber nie durchgespielt — und im Ernstfall stellt sich heraus, dass ein Schritt fehlt. Der zweite ist die verkürzte Hypercare: Sie endet nach zwei Tagen, weil nichts passiert ist. Nichts passiert meistens am Anfang.

9:38 Der dritte ist ein Terminfehler mit Tradition: Die Umschaltung liegt auf einem Freitagnachmittag — und niemand ist da, wenn es klemmt. Und der vierte schließt an Modul sieben an: Nach dem Start prüft niemand die Indexierung der neuen Adressen.

Übung

9:53 Die letzte Übung dieses Seminars. Sie nehmen den Shop ab, den wir seit Montag gebaut haben — und entscheiden. Der Shop von Steglicht steht: Katalog, Storefront, Checkout, Versand, zweiter Markt, der Geschäftskunde Federhaus, drei Flow-Workflows und sechs Apps. Der Start ist für die kommende Woche geplant, die Domain zeigt noch auf den alten Shop.

10:14 Das ist die Situation, in der alle Beteiligten nervös werden und in der die Versuchung am größten ist, Befunde kleinzureden. Genau deshalb ist die Trennung in blockierend und nachrangig die eigentliche Prüfung — nicht die Checkliste selbst. Das Lernziel: Einen Shop entlang prüfbarer Kriterien abnehmen und blockierende von nachrangigen Befunden trennen.

10:35 Erfolgreich sind Sie, wenn die Checkliste Testbestellungen, fachliche Fälle, die vier technischen Kontrollen und den Rückweg abdeckt — und jeder Befund eingestuft und einer Rolle zugeordnet ist. Und wer früh fertig ist, benennt die fünf Entscheidungen, die er beim Abschluss begründen würde. Das ist zugleich eine gute Übung für die Rückschau auf diese Woche: Welche fünf Entscheidungen tragen diesen Shop?

10:57 Legen Sie zuerst die Abnahmekriterien je Bereich fest und benennen Sie Prüfende. Führen Sie dann Testbestellungen durch: Normalfall, zweiter Markt und B2B — drei Bestellungen, die zusammen fast alles berühren. Arbeiten Sie die vier technischen Kontrollen ab und notieren Sie die Werte. Stufen Sie die Befunde ein und beschreiben Sie den Rückweg.

11:17 Und entscheiden Sie zum Schluss über den Start — mit Begründung. Diese Entscheidung ist der eigentliche Abschluss des Seminars: Nicht ob der Shop fertig ist, sondern ob Sie ihn verantworten können. Vier letzte Punkte. Die Checkliste wird abgehakt, ohne die Prüfung wirklich durchzuführen — Haken sind billig. Der Testmodus bleibt nach der Abnahme aktiv, und damit sind keine echten Bestellungen möglich; das ist der teuerste Flüchtigkeitsfehler dieses Moduls.

11:44 Blockierende Befunde werden nachrangig gestellt, weil der Termin steht — dann verschiebt man nicht den Start, sondern das Problem. Und der letzte Punkt fasst diese ganze Woche zusammen: Der Start wird beschlossen, ohne dass jemand die Entscheidung verantwortet. Ein Shop braucht keine Perfektion. Er braucht eine Person, die sagt: Wir starten, und das hier ist der Grund.