PrestaShop 9.2 One Page Checkout testen: Ein praktischer QA-Plan

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.

Dieser Plan gilt für PrestaShop 9.2 RC1 auf einer isolierten Testinstallation. Dokumentieren Sie neben der Kernversion die genauen Versionen von Checkout-Modul, Theme und Zahlungsmodulen. Die offizielle Checkout-Dokumentation hebt Modulkompatibilität ausdrücklich hervor; die Implementierung kann sich unabhängig von Annahmen in eigenen Shopskripten weiterentwickeln. Referenz zur Modulintegration.

Die folgenden Fälle sind vorgeschlagene Tests. Sie behaupten nicht, dass diese Kombinationen bereits bestanden haben.

Verstehen Sie zunächst, wie der native One Page Checkout den Kauf verändert; der Abnahmeplan sollte den beabsichtigten Checkout einschließlich seiner Zahlungs- und Versandintegrationen abdecken.

Testdaten erstellen, die falsche Ergebnisse offensichtlich machen

Verwenden Sie einen kleinen, bewusst vielfältigen Katalog: einen normalen physischen Artikel, einen Artikel mit Versandbeschränkung, ein Produkt mit Kombinationen und, sofern angeboten, einen virtuellen Artikel. Setzen Sie Bestand und Preise auf bekannte Werte. Vermeiden Sie einen großen Zufallskatalog, der jeden Fehler schwer erklärbar macht.

Erstellen Sie einen Gast, einen registrierten Kunden mit einer Adresse und einen registrierten Kunden mit mehreren Adressen. Verwenden Sie synthetische Daten. Definieren Sie mindestens zwei Ziele mit unterschiedlicher Versandzulässigkeit. Unterscheidet sich die steuerliche Behandlung, halten Sie vor dem Test die laut Händlerkonfiguration erwartete Berechnung bereit.

Erstellen Sie eine Versandfreigrenze und Gutscheine, die die tatsächlich genutzten Shopregeln prüfen. Nehmen Sie die Reihenfolge von Rabatten und Schwellen nicht an; notieren Sie die beabsichtigte Konfiguration und die erwartete Summe je Testdatensatz.

Bewahren Sie für jeden Test Folgendes auf:

• Kern-, Theme- und Modulversionen sowie Shop- und Sprachkontext.
• Ausgangswarenkorb, Kundenzustand und relevante Konfiguration.
• Genaue Aktionen, erwartete und tatsächliche Ergebnisse.
• Warenkorb- und Bestellkennungen, Zahlungs-Sandbox-Referenz und Zeitstempel.
• Geschwärzte Screenshots oder Anfrageprotokolle, wenn sie zur Fehlererklärung nötig sind.

Ein Screenshot belegt sinnvoll, was der Kunde gesehen hat. Bestelldatensatz und Zahlungsergebnis zeigen, was der Shop verbindlich gespeichert hat. Erfassen Sie beides.

Kundenidentität als Zustandsübergang testen

Abschluss als Gast

Beginnen Sie in einer sauberen Browsersitzung. Fügen Sie ein Produkt hinzu, geben Sie gültige Kontakt- und Adressdaten ein, wählen Sie den Versand und schließen Sie eine Sandbox-Zahlung ab. Prüfen Sie, dass genau eine beabsichtigte Bestellung entsteht, die Kundendaten korrekt sind und der gespeicherte Betrag zur Endübersicht passt.

Wiederholen Sie den Fall mit einem fehlenden Pflichtfeld. Der Checkout sollte das Problem erkennen, ohne andere gültige Eingaben zu verwerfen. Korrigieren Sie das Feld und senden Sie erneut. Ein Validierungsfehler darf keine versteckte Teilbestellung hinterlassen, die später ein Duplikat erzeugt.

Wiederkehrender Kunde

Melden Sie sich mit einem Konto mit zwei Adressen an. Wählen Sie die nicht standardmäßige Adresse und schließen Sie die Bestellung ab. Prüfen Sie das Ziel in der gespeicherten Bestellung, nicht nur den ausgewählten Optionsknopf.

Beginnen Sie dann einen weiteren Warenkorb, wechseln Sie die Identität über den unterstützten An- oder Abmeldeablauf und kehren Sie zum Checkout zurück. Prüfen Sie, dass kundenspezifische Adressen, Preise und Versandoptionen zur aktuellen Identität gehören. Akzeptieren Sie die sichtbare Adresse eines vorherigen Kunden nicht als harmlosen Anzeigefehler.

Aktualisierung und Navigation

Aktualisieren Sie nach Adresseingabe, Versandwahl und Rückkehr von einer abgebrochenen Zahlung. Verwenden Sie die Zurückfunktion, wo der Ablauf sie zulässt. Die erwartete Speicherungspolitik sollte dokumentiert sein, und der Kunde sollte fortfahren können, ohne unwissentlich doppelt zu bezahlen.

Abhängige Entscheidungen bei Adressänderungen korrekt ungültig machen

Das wichtige Szenario ist nicht einfach die Eingabe zweier Adressen. Es ist die Änderung der Adresse, nachdem der Checkout bereits andere Zustände daraus abgeleitet hat.

Führen Sie auch einen Fall mit schneller Bearbeitung aus: Ändern Sie ein relevantes Feld zweimal, bevor die erste Aktualisierung abgeschlossen ist. Der endgültig angezeigte und gespeicherte Zustand sollte der zuletzt akzeptierten Eingabe entsprechen. Netzwerkdrosselung im Browser kann ein Reihenfolgeproblem aufdecken, ohne Zugriff auf Modulinterna zu erfordern.

Bewahren Sie bei Fehlern Abfolge und Zeitablauf auf. „Versand ist falsch“ bietet einem Entwickler wenig zum Reproduzieren; „Land nach Abholstellenauswahl geändert, dann blieb die alte Option in der Bestellung“ ist konkret bearbeitbar.

Versand, Gutscheine und Steuern gemeinsam prüfen

Versand und Aktionen scheitern häufig an Grenzwerten. Setzen Sie den Warenkorb knapp unter die konfigurierte Versandfreigrenze, erreichen Sie die Grenze und unterschreiten Sie sie wieder. Wenden Sie den relevanten Gutschein an jedem sinnvollen Punkt an und entfernen Sie ihn.

Prüfen Sie nicht nur, ob sich die Summe ändert. Vergleichen Sie den Betrag mit der unabhängig vorbereiteten Testberechnung und kontrollieren Sie die Versandposition in der entstandenen Bestellung. Eine optisch plausible Summe kann trotzdem falsch sein.

Wählen Sie bei Versandmodulen eine Abholstelle oder einen Liefertermin, sofern genutzt. Wechseln Sie den Versanddienstleister und anschließend zurück. Prüfen Sie, dass jede wiederhergestellte Auswahl für aktuelle Adresse und Warenkorb gültig bleibt. Schließen Sie die Bestellung ab und prüfen Sie die zur Abwicklung verwendeten Daten.

Verwenden Sie für Steuern bekannte Shopkonfigurationen und erwartete Ergebnisse. Beziehen Sie einen Zielwechsel und einen Kundengruppenfall ein, sofern relevant. Das ist Software-QA anhand konfigurierter Regeln, keine Beratung zur rechtlich korrekten steuerlichen Behandlung.

Testen Sie bewusst eine unzulässige Kombination. Ein beschränktes Produkt und ein nicht unterstütztes Ziel sollten einen verständlichen gesperrten Zustand erzeugen, statt einen scheinbar verfügbaren Zahlungsbutton, der erst am Ende scheitert.

Fehlgeschlagene Zahlungen als normale Abnahmefälle behandeln

Verwenden Sie die dokumentierten Sandbox-Ergebnisse jedes Anbieters. Decken Sie Erfolg, Ablehnung, Abbruch und eine unterbrochene Browserrückkehr ab, sofern die Integration diese Simulationen unterstützt.

Ein zuverlässiger Fall vergleicht drei Beobachtungen: was der Anbieter meldet, was das Zahlungsmodul speichert und was der Kunde sieht. Diese können asynchron konsistent werden; definieren Sie daher ein angemessenes Beobachtungsfenster für das Modul, statt jedes Ergebnis sofort zu erwarten.

Beziehen Sie diese Prüfungen ein:

1. Einmal senden und die beabsichtigte Beziehung zwischen Bestellung und Zahlung prüfen.
2. Doppelklicken oder die unterstützte Sendeaktion wiederholen und auf doppelte Geschäftseffekte prüfen.
3. Extern abbrechen und bestätigen, dass die Wiederaufnahme die Bestellung nicht fälschlich als bezahlt markiert.
4. Nach Erfolg zurückkehren und die Bestätigungsseite aktualisieren, ohne eine weitere Bestellung zu erzeugen.
5. Warenkorb nach einem Fehlversuch ändern, erneut versuchen und den neuen Betrag prüfen.
6. Wenn die Anbieter-Sandbox es erlaubt, eine Benachrichtigung erneut abspielen und die Duplikatbehandlung prüfen.

Erfinden Sie keine Callbacks und umgehen Sie keine Anbieterprüfung, um einen Test erfolgreich erscheinen zu lassen. Nutzen Sie unterstützte Sandbox-Werkzeuge der Integration und beziehen Sie deren Betreuer ein, wenn ein Fehlermodus nicht sicher simuliert werden kann.

Ein Fehler bei der Wiederaufnahme ist etwas anderes als ein Fehler beim Starten der Zahlung. Melden Sie beides getrennt, damit der betroffene Vertrag klar ist.

Mobile Bedienung und Shop-Isolation prüfen

Wählen Sie reale Gerätegrößen, die Ihre Kunden repräsentieren. Testen Sie mit geöffneter Bildschirmtastatur, Autofill, langer Adresse und einem Validierungsfehler oberhalb des sichtbaren Bereichs. Prüfen Sie, dass die Endaktion auffindbar bleibt und Summen vor dem Absenden geprüft werden können.

Verwenden Sie am Desktop reine Tastaturnavigation. Prüfen Sie bei Abschnittsaktualisierungen, dass der Fokus sinnvoll bleibt und Fehler auffindbar sind. Ein erfolgreicher Maustest belegt nicht, dass alle Kunden den Ablauf bedienen können.

Erstellen Sie für Multistore bewusst unterschiedliche Konfigurationen in zwei Shops: einen nur in einem verfügbaren Versanddienstleister, einen nur wie vorgesehen gültigen Gutschein und, sofern unterstützt, eine eigene Zahlungskonfiguration. Wiederholen Sie den relevanten Checkout in jedem Shop mit getrennten Sitzungen. Prüfen Sie die Shopzuordnung der Bestellung und das Integrationskonto, das das Testereignis erhält.

Das Ziel ist nicht, jede mögliche Kombination zu testen. Priorisieren Sie Kombinationen, die Geld bewegen, Versandzulässigkeit ändern oder die Konfiguration eines Shops in einen anderen übertragen können. Ergänzen Sie risikoärmere Darstellungsfälle, nachdem diese Invarianten abgedeckt sind.

Stellen Sie vor einer Wiederholung den Ausgangszustand wieder her oder erstellen Sie ihn neu. Ein bereits in einer früheren Bestellung verbrauchter Gutschein, reduzierter Bestand oder ein im vorherigen Versuch angelegtes Kundenkonto kann das Ergebnis verändern. Geben Sie Testdaten vorhersehbare Kennungen und dokumentieren Sie wiederverwendbare Objekte. So wird Testverunreinigung nicht als Checkout-Regression gemeldet, und die Reproduktion durch andere Tester wird deutlich zuverlässiger.

Halten Sie das erwartete Ergebnis unabhängig vom beobachteten Bildschirm. Die angezeigte Summe als erwartete Summe in den Testbericht zu kopieren, würde eine falsche Berechnung sich selbst bestätigen lassen.

Ergebnisse in eine hilfreiche Abnahmeentscheidung überführen

Ordnen Sie Fehler nach ihrer geschäftlichen Wirkung ein. Falsche Zahlungen oder doppelte Bestellungen verhindern die Abnahme. Eine ungültige Versandwahl ist ebenfalls ein Korrektheitsfehler. Ein kosmetisches Ausrichtungsproblem hat einen anderen Schweregrad, sofern es den Kunden nicht am Verstehen oder Abschließen des Kaufs hindert.

Testen Sie nach einer Korrektur die genaue fehlerhafte Abfolge erneut und danach benachbarte Fälle mit derselben Abhängigkeit. Eine Korrektur der Zahlungsaktualisierung rechtfertigt beispielsweise die Prüfung adress- und versandbedingter Aktualisierungen. Grundloses Wiederholen unzusammenhängender Fälle kostet Zeit, ohne die Wirkung der Korrektur zu erklären.

Halten Sie ungeklärte Grenzen im Freigabeprotokoll sichtbar. Ein als „nicht geprüft“ markierter Fall ist nicht bestanden. Eine Anbieterbestätigung ist ein hilfreicher ergänzender Beleg, ersetzt aber nicht das Testen der eigenen Shopkonfiguration.

Das Endergebnis sollte die getestete Versionskombination, bestandene kritische Szenarien, verbleibende Fehler und die für die nächste Entscheidung verantwortliche Person nennen. Solange 9.2 RC-Software bleibt, betrifft diese Entscheidung die Bereitschaft zur weiteren Bewertung, nicht die Erlaubnis, den Kandidaten in einem Live-Shop zu installieren.

Für den zugrunde liegenden Plattformkontext lesen Sie unseren Leitfaden für ein sicheres Upgrade von PrestaShop 8 auf 9 und wenden Sie die obigen versionsspezifischen Prüfungen auf die Installation an, die Sie bewerten.