E2E-Tests, die du
Das Vibe-Coding-Tool für E2E-Testing. Beschreib den Ablauf in natürlicher Sprache — ein KI-Agent steuert einen echten Browser, führt ihn aus und belegt jeden Schritt mit Log und Screenshots. Kein Framework, keine brüchigen Selektoren.
Selbst gehostet · Postgres RLS Mandantentrennung · argon2id
Öffne die Startseite, melde dich mit den hinterlegten Zugangsdaten an, leg einen Artikel in den Warenkorb und geh zur Kasse. Prüfe, dass die Bestellübersicht erscheint.
- navigate/ — Startseite geladen
- fill_fieldusername, password (verschlüsselt)
- click„Anmelden“
- click„In den Warenkorb“
- click„Zur Kasse“
- doneBestellübersicht sichtbar
So funktioniert's
Von einem Satz zum ausgeführten Test
- 1
Test in Prosa schreiben
Beschreib den Nutzer-Flow so, wie du ihn erklären würdest. Optional hängst du Zugangsdaten und Adressdaten an — der Agent sieht nur die Feld-Keys, nie die Werte.
- 2
Agent führt ihn aus
Gemini betrachtet jeden Screenshot, entscheidet die nächste Aktion, Playwright führt sie im echten Chromium aus — Screenshot, Aktion, Screenshot, bis „done“ oder „fail“.
- 3
Ergebnis prüfen
Ein Schritt-für-Schritt-Log mit Screenshots streamt live in die Run-Ansicht. PASSED oder FAILED — on demand ausgelöst oder nach Zeitplan.
Features
Alles drin, was ein E2E-Portal braucht
Vom ersten Prosa-Test bis zum geplanten Smoke-Check in Produktion — mit Sicherheit als Fundament, nicht als Nachgedanke.
Tests in natürlicher Sprache
E2E-Coverage als Prosa — kein Test-Framework, keine brüchigen Selektoren, kein Skript-Wartungsaufwand.
Echter Browser, echte Vision
Gemini reasoned über jeden Screenshot; Playwright klickt, tippt und navigiert im echten headless Chromium — nicht simuliert.
Schritt-Log & Screenshots
Jede Aktion samt Screenshot wird persistiert und streamt live in die Run-Ansicht. Nachvollziehbar statt Blackbox.
Zeitplan & durable Queue
Stündlich, täglich oder per Custom-Cron. Eine DB-gestützte Queue verteilt Runs sicher über mehrere Worker (FOR UPDATE SKIP LOCKED).
Mandantentrennung per DB
Jede Query läuft durch withTenant; Postgres Row-Level-Security erzwingt die Isolation. Cross-Tenant-Zugriff endet in 404 — IDOR ist strukturell ausgeschlossen.
Zugangsdaten bleiben geheim
Passwörter und Adressfelder sind AES-256-GCM-verschlüsselt, in Screenshots maskiert und erreichen die KI nie — Werte werden erst lokal beim Ausführen injiziert.
SSRF-Guard auf jede URL
Ziel-URLs werden bei Annahme und bei Ausführung geprüft: nur http(s), localhost / private / Link-Local / Cloud-Metadata werden blockiert, inkl. DNS-Auflösung.
Health & Prometheus-Metriken
Der Worker liefert /health und /metrics (Uptime, Runs, Queue). Deploy als Docker-Compose: Web und Worker getrennt gegen dein Postgres.
Sicherheit ab Phase 1
DevSecOps-Grundsätze, in die Architektur eingebaut
Sicherheit ist hier kein Feature-Toggle, sondern die Datenbank- und Ausführungsschicht selbst. Ein vergessenes WHERE kann keine fremden Daten leaken — Row-Level-Security lässt es gar nicht zu.
- Mandantentrennung DB-erzwungen (RLS) — nicht anwendungsseitig
- AES-256-GCM für Zugangs- & Adressdaten, nie im KI-Prompt
- SSRF-Guard bei Annahme und bei Ausführung, inkl. DNS-Check
- argon2id-Passwörter, JWT-Sessions (Auth.js v5)
- Model-Output ist untrusted — jede Aktion an ein zod-Schema gebunden
- Generische Fehlermeldungen an Clients, Details nur serverseitig geloggt
Für wen
Gebaut für Teams, die Coverage brauchen — nicht Skripte
QA ohne Automatisierung
E2E-Tests als Prosa — ganz ohne Framework.
Kleine Dev-Teams & Startups
Kritische Flows abgedeckt, ohne eigene Automation-Engineers.
Product Manager & Stakeholder
Akzeptanzkriterien selbst schreiben — technikfrei.
Agenturen & Dienstleister
Viele Kundenseiten, sauber getrennt: Tenant-Isolation, projektbezogene Credentials.
DevOps / SRE
Geplante Smoke- & Uptime-Checks auf die wichtigsten Journeys.
Schreib deinen ersten Test in einem Satz
Leg ein Projekt an, beschreib einen Flow, drück „Run“ — und sieh dem Agenten beim Testen zu.