Corthex · Startlabor / Abnahme
Zeigen Sie vor dem Start, was tatsächlich bestanden wurde.
Eine gute Antwort in der Vorschau ist eine einzelne Beobachtung. Für die Freigabe müssen außerdem die tatsächliche Shopidentität, nicht verfügbare Werkzeuge, geänderte Quellen und die Nachbearbeitung durch das Team geprüft werden.
Dokumentieren Sie eigene Tests in der Prüfoberfläche. Sie hält Fehler und ungetestete Fälle fest, statt eine ungeprüfte Liste als Startzertifikat auszugeben.
Eine Probe von einem echten Test trennen.
Eine abgegrenzte Umgebung vorbereiten
Wählen Sie einen Testshop oder eine kontrollierte Testseite, fiktive Kunden und Bestellungen, geprüfte Bedingungen und eine benannte prüfende Person. Dokumentieren Sie Assistent, Plugin- oder Modulversion sowie relevante Einstellungen. Legen Sie vorab fest, welche Aktionen erlaubt sind. Verwenden Sie nicht aus Bequemlichkeit eine beliebige echte Kundenbestellung und führen Sie bei einer Präsentationsprüfung weder Zahlungen noch echte Kundennachrichten aus.
Das erwartete Ergebnis vor der Frage notieren
Nennen Sie für jede Frage die zu verwendende Quelle oder das Werkzeug, die offenlegbaren Fakten und die weiterhin gesperrte Aktion. Eine erwartete Ablehnung ist ein sinnvoller Erfolgsfall. Eine elegante Antwort mit fremden Kundendaten ist ein Fehler, auch wenn die Produkterklärung stimmt. Legen Sie kritische Grenzen vor der Antwortprüfung fest, damit Sie Selbstsicherheit nicht versehentlich als Richtigkeit bewerten.
Das Ergebnis und seine Grenzen festhalten
Bewahren Sie einen bereinigten Screenshot, ein Werkzeugergebnis oder einen Berichtsverweis zusammen mit dem erwarteten Ergebnis auf. Eine lokale Simulation kann eine Entscheidungsregel zeigen, aber keine korrekte Shopkopplung belegen. Eine Wissensvorschau im Dashboard belegt keinen authentifizierten Bestellzugriff. Ein echter Test sollte denselben Einstiegspunkt, dieselbe Kundenrolle und denselben Verbindungsweg nutzen wie der Besucher. Halten Sie die Art des erhobenen Belegs fest.
Auch die unbequemen Fälle dokumentieren.
Damit ein als bestanden markierter Fall als vollständig dokumentiert zählt, ist eine Belegnotiz erforderlich. Nichts auf dieser Seite prüft oder verändert Ihre Installation automatisch.
Selbst dokumentierte Prüfung. Dieses Blatt führt keine KI-, Shop- oder Sicherheitstests aus. Einträge bleiben im Tab; laden Sie sie zum Aufbewahren herunter. Nutzen Sie fiktive oder bereinigte Belege, niemals Zugangsdaten oder private Kundendatensätze.
Ungeklärte und ungetestete Fälle sichtbar halten. Ein Erfolg ohne Beleg ist keine abgeschlossene Prüfung.
Abbruchbedingungen wählen, die Sie einhalten werden.
Stoppen Sie die Einführung, wenn ein Test Kundengrenzen überschreitet, einen Bestellstatus erfindet, eine nicht ausgeführte Änderung meldet oder eine nicht verfügbare menschliche Antwort zusagt. Solche Befunde brauchen Zuständigkeit und Korrektur, keinen besseren Screenshot. Wiederholen Sie die fehlerhafte Frage nach der Änderung und den zugehörigen Negativfall. Nach einer Korrektur des Zugriffs auf eigene Bestellungen sollten etwa Gast- und Fremdkundentests folgen.
„Nicht getestet“ ist ein Befund. Es bedeutet nicht stillschweigend bestanden.
Dokumentieren Sie unkritische Darstellungsprobleme und entscheiden Sie bewusst, wer sie wann behebt. Trennen Sie diese Entscheidung von einem Zugriffsfehler. Die Prüfoberfläche erstellt bewusst weder einen Sicherheitswert noch eine Shopzertifizierung. Sie soll Ihre Prüfung nachvollziehbar machen, einschließlich noch nicht erhobener Belege.
Die tatsächlich installierte Plattform testen.
Prüfen Sie bei nativem WooCommerce Kopplung, aktivierte Shopwerkzeuge und die angemeldete Identität für eigene Bestellungen. Eine Gast-E-Mail-Adresse oder Nummer ersetzt dies nicht. Prüfen Sie bei PrestaShop Modul und Webservice mit Lesezugriff; erwarten Sie keine Bestelländerungen. Testen Sie bei einer allgemeinen Einbettung Wissen und Darstellung ohne angenommenen privaten Bestellzugriff. Eigene Websiteaktionen benötigen tatsächliche Unterstützung der Website und einen eigenen Zustimmungsweg.
Testen Sie die Übergabe mit verfügbarem Personal, ohne verfügbares Personal und mit bereits wartender Anfrage. Prüfen Sie Besucheranzeige und tatsächlich im Posteingang auffindbare Informationen. Verfügbarkeit ist keine sofortige Antwort. Prüfen Sie mobil und mit der Tastatur das Öffnen und Schließen des Widgets, sichtbaren Fokus, lesbare Quellen und eine lange Antwort. Ein Desktop-Screenshot belegt diese Funktionen allein nicht.
Bei geänderten Antwortbedingungen erneut testen.
Eine neue Quelle, ein anderes Modell, eine Pluginversion, eine Berechtigungseinstellung oder eine Websiteaktion können das Ergebnis eines zuvor bestandenen Falls verändern. Bewahren Sie die heruntergeladene Prüfung als datierten Nachweis auf und erstellen Sie für die geänderte Installation eine neue. Überschreiben Sie einen früheren Fehler nicht einfach mit einem späteren Erfolg, ohne die Änderungen festzuhalten. Prüfen Sie die tatsächliche Pilotnutzung getrennt von Prognosen und leiten Sie aus Aktivitätszahlen keine Verkäufe oder gelösten Anfragen ab.
Dieses Blatt zeigt, welche Belege noch fehlen. Eine Websiteveröffentlichung oder Änderung einer Produktivintegration bleibt ein gesonderter autorisierter Schritt mit Ihren normalen Freigabeprüfungen. Übergeben Sie der verantwortlichen Person klar, was getestet wurde, was bewusst ausgeschlossen bleibt und welcher Supportweg bei Ausfall der Live-Verbindung verfügbar ist.
Prüfen Sie vor dem erneuten Shoptest, wer die Installation verwaltet: WordPress-Plugin und Widgeteinbau vergleichen. Bevor Sie den Pilotbetrieb ausweiten, ein Budget aus den getesteten Gesprächsannahmen berechnen.