PathMai 2026
Warum wir Ihre Abläufe in einem echten Browser nachspielen
Es gibt drei Wege, einen Bestellprozess zu testen. Wir haben den langsamsten und teuersten gewählt — und hier steht, warum er als einziger die Frage beantwortet.
Drei Wege, einen Ablauf zu testen
- HTTP-Anfragen aneinanderreihen und einen Browser imitieren: schnell, günstig und falsch, sobald JavaScript, ein Anti-Replay-Token oder ein Zahlungs-Widget im Spiel ist.
- Einen abgespeckten Browser ohne Rendering steuern: sparsamer, aber manche Seiten erkennen die fehlende Darstellung und verhalten sich anders.
- Ein echtes Chromium starten — mit Rendering, Cookies und Drittanbieter-Skripten — und es die Handgriffe eines Kunden ausführen lassen.
Wir haben den dritten genommen. Er ist der langsamste und teuerste — und der einzige, der die eigentliche Frage beantwortet: kann ein Mensch bei Ihnen gerade kaufen?
Was das sichtbar macht
- Die Dauer jedes Schritts einzeln: die Anmeldung kann sofort gehen, der Warenkorb endlos dauern — ein Gesamtwert verdeckt das.
- Ein Screenshot des Fehlers, aufgenommen im Moment des Fehlers.
- Ein Video des fehlgeschlagenen Ablaufs — in den Tarifen, die es enthalten — wenn ein Screenshot nicht ausreicht.
- Die Netzwerkaufrufe jedes Schritts mit Statuscode und Dauer: dort taucht meist das schuldige Drittanbieter-Skript auf.
Was das kostet
Ein Browser belegt CPU und Speicher für die gesamte Dauer des Ablaufs. Deshalb werden Browser-Läufe in Minuten gezählt und ihr Takt ist weiter als bei einer HTTP-Prüfung: einige Male pro Stunde in den höheren Tarifen, einmal täglich in den Einstiegstarifen. HTTP-Monitoring läuft dagegen jede Minute.
Was wir nicht gemacht haben
Wir schreiben Ihre Szenarien nicht für Sie und liefern keinen Code-Editor. Sie zeichnen den Ablauf per Klick im Recorder auf und korrigieren Schritte von Hand, wenn sich ein Selektor verschiebt. Das ist Absicht: ein Szenario, das Sie nicht verstehen, reparieren Sie nicht — und ein defektes Szenario, das niemand repariert, wird irgendwann abgeschaltet.