Playwright E2E in Aktion
So übernimmt Playwright später Maus, Tastatur und Browser.
Steuern Sie den Roboter kurz selbst: Jede Bewegung folgt einer klaren Anweisung. Genau so führt Playwright später programmierte E2E-Szenarien im Browser aus - aus Kundensicht, mit Klicks, Tastatureingaben und automatisierten Prüfungen.
Bewegen Sie die Maus über den Roboter. Im echten Projekt übernimmt Playwright diese wiederholbaren Browser-Abläufe automatisch, damit Entwickler Regressionen nach Updates nicht jedes Mal manuell nachtesten müssen. Berühren Sie den Roboter. Im echten Projekt übernimmt Playwright wiederholbare Browser-Abläufe automatisch, damit Regressionen nach Updates nicht jedes Mal manuell geprüft werden müssen.
Bundesweit digitale Zusammenarbeit, auch für deutsch- und englischsprachige Software-Teams außerhalb Deutschlands. Fokus auf Playwright-Testautomatisierung für Websites, Portale und Webanwendungen (Node.js/TypeScript).
Sie haben bereits automatisierte Tests? Wir starten von Grund auf mit sauberer Architektur und Best Practices - für wartbare, stabile Tests, die mit Ihrer Anwendung mitwachsen.
- Stage/QA/UAT als Standard, Produktion nur nach ausdrücklicher schriftlicher Vereinbarung
- Stabilität durch deterministische Selektoren (data-testid) statt fragilem XPath/CSS
- Wartbare Architektur (TypeScript, Page Object Model) plus Dokumentation, Übergabe und Schulung
© Velvionix Passt das zu Ihrem Team?
Passt, wenn
- +Sie große Websites, Portale oder Webanwendungen betreiben und Releases zuverlässig absichern möchten
- +Eine Stage/QA/UAT-Umgebung mit stabilen Testkonten und Testdaten vorhanden ist
- +Ihr Team stabile Selektoren bereitstellen kann (data-testid oder gleichwertig)
Passt nicht, wenn
- -Sie automatisierte Prüfungen dauerhaft gegen Produktion ausführen wollen
- -Testdaten nicht kontrollierbar sind oder die Umgebung regelmäßig instabil ist
- -WAF/Rate Limits/Anti-Bot Testausführungen blockieren und nicht angepasst werden können
Modulare Umsetzung mit klarer Abnahme
Wir liefern in Modulen. Alles außerhalb des vereinbarten Modulblatts wird als Change Request transparent angeboten, bevor wir umsetzen.
M1 Analyse und Scope-Workshop
Kritische Flows, Priorisierung, Browser-/Viewport-Matrix, Testdatenstrategie, Reset-Mechanismus. Ergebnis: klare Prio-1 Testliste und Umsetzungsplan.
M2 Framework-Setup
Projektstruktur, Konventionen, Page Object Model, Dokumentation, lokale Ausführung. TypeScript als Standard.
M3 Initialpaket: 10 Prio-1 Prüfungen
Stabile Assertions, nachvollziehbarer Scope, Playwright HTML-Report. Desktop, Chromium als Basis.
M3a Zusatzmodul: Tablet/Mobile Viewports
Erweiterung auf zusätzliche Viewports (deutlich höherer Aufwand durch UI-Varianten).
M4 CI-Pipeline (GitHub Actions)
Automatische Ausführung im Kunden-Repo, Report als Artefakt, Traces/Screenshots nach Vereinbarung.
M5 Übergabe und Schulung
Remote-Session: Projektstruktur, lokal/CI ausführen, Troubleshooting-Grundlagen.
Scope-Regeln
- • Default-Scope: ausschließlich die Webapp des Auftraggebers über die Weboberfläche.
- • Tests werden als fokussierte Flows umgesetzt - keine monolithischen End-to-End-Tests, die mehrere Bereiche in einem Test abdecken und lange Laufzeiten erzeugen.
- • Externe Systeme (Payment, SSO, E-Mail) nur, wenn explizit als Zusatzmodul beauftragt und mit Sandbox/Testzugängen realistisch automatisierbar.
- • Keine echten mobilen Geräte oder Emulatoren - Mobile nur über Playwright-Viewports.
- • Produktion ist standardmäßig ausgeschlossen.
Voraussetzungen für stabile Tests
- • Funktionsfähige Stage/QA/UAT-Zugänge, Testkonten und Testdaten müssen verfügbar sein.
- • Testdaten müssen zuverlässig bereitgestellt oder zurückgesetzt werden können (Reset-Mechanismus).
- • WAF/Rate Limits/Anti-Bot dürfen Automatisierung nicht blockieren. Falls nötig: Whitelisting oder ein Identifikationsmechanismus.
- • Stabile Selektoren (data-testid) sind Pflicht. Ohne diese pausieren wir und fordern Nachbesserung an.
CI/CD und Reporting
Standard ist der Playwright HTML-Report. In GitHub Actions wird der Report als Artefakt bereitgestellt. Weitere Reporting-Integrationen (z.B. JUnit, Allure, Testmanagement) nur nach gesonderter Beauftragung.
Abnahme und Qualitätskriterien
- Abnahme erfolgt pro Modul (vereinbarter Testumfang), nicht pro Testfall.
- Bei nachweislich falschen oder unvollständigen Tests gibt es zwei Korrekturschleifen pro Modul.
- Flaky-Quellen werden sauber dokumentiert und zugeordnet (Testproblem vs. Umgebung/Testdaten/Rate Limits).
Abrechnung und Beauftragung
Die Vergütung erfolgt modular auf Basis eines Modulblatts, netto zzgl. USt. Jedes Modul wird vor Umsetzung mit Leistungsumfang, Abnahmekriterien und festem Preis beschrieben. Nach Fertigstellung wird das Modul zur Abnahme bereitgestellt. Nach Abnahme stellen wir die Rechnung für das abgeschlossene Modul. Die Bearbeitung weiterer Module beginnt erst nach Zahlung der vorherigen Rechnung, sofern nichts anderes schriftlich vereinbart wurde. Change Requests werden vor Umsetzung transparent angeboten und erst nach Freigabe umgesetzt, inklusive Leistungsbeschreibung, Aufwand/Preis und Auswirkungen.
Optional: Pflegevertrag für Updates und CI
- Monatliche Updates von Playwright und Dependencies (inkl. erforderlicher Anpassungen zur Wiederherstellung der Lauffähigkeit im vereinbarten Umfang).
- Pflege und Anpassung der CI-Workflows (GitHub Actions) im vereinbarten Umfang, z.B. Workflow- und Job-Anpassungen, Reports/Artefakte sowie Unterstützung bei Secrets-Rotation und Required Checks (sofern Zugriff vorhanden). Infrastruktur, VPN-Zugänge sowie Einrichtung oder Betrieb von Self-hosted Runnern sind nicht Bestandteil und werden vom DevOps-Team des Kunden bereitgestellt.
- Reaktionszeit bei kritischen CI- oder Test-Ausfällen (gemeinsam als kritisch eingestuft): Analyse und Rückmeldung mit Plan innerhalb von 48 Stunden an Werktagen.
Technisches Erstgespräch
Wir prüfen Scope, Stage, Selektoren und CI-Voraussetzungen und schlagen ein sinnvolles Modulpaket vor.
Technisches Erstgespräch anfragen