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.
Wir arbeiten remote mit Unternehmen in Deutschland, Österreich und der Schweiz. Englischsprachige Projekte übernehmen wir auch für Unternehmen in weiteren Ländern der Europäischen Union. Der Fokus liegt auf Playwright-Testautomatisierung für Websites, Portale und Webanwendungen (Node.js/TypeScript).
Vor einer größeren Umsetzung prüfen wir Zugänge, Testumgebung und repräsentative Abläufe in einem technischen Pilot. Erst wenn die Machbarkeit geklärt ist, legen wir den weiteren Testumfang gemeinsam fest.
- 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 Zugänge und Machbarkeit
Testumgebung, Repository-Zugriff, Testkonten, Testdaten, Selektoren und technische Abhängigkeiten werden geprüft. So ist vor dem größeren Auftrag klar, welche Abläufe zuverlässig automatisierbar sind.
M2 Repräsentative Pilot-Flows
Eine kleine Auswahl typischer Abläufe wird als technischer Pilot umgesetzt. Damit prüfen wir Architektur, Zugänge und Zusammenspiel mit der Anwendung unter realen Projektbedingungen.
M3 Abgestimmter Scope
Kritische Nutzerflüsse, Prioritäten, Browser und Viewports, Testdatenstrategie sowie Abnahmekriterien werden gemeinsam festgelegt und im Angebot eindeutig beschrieben.
M4 Architektur und Umsetzung
Wir entwickeln die vereinbarten Playwright-Flows mit stabilen Assertions, wartbarer TypeScript-Struktur, nachvollziehbarer Dokumentation und passenden Desktop- oder mobilen Viewports.
M5 CI und Reporting
Die automatischen Prüfungen werden nach Vereinbarung in die vorhandene CI eingebunden. Reports, Traces und Screenshots machen Ergebnisse und Fehlerursachen nachvollziehbar.
M6 Übergabe und Unterstützung
In einer Remote-Session erklären wir Projektstruktur, lokale und automatische Ausführung sowie Troubleshooting-Grundlagen. Weitere Pflege kann separat vereinbart werden.
Optional: UI/UX-Analyse als separater Auftrag
Auf Wunsch prüfen wir zusätzlich Bedienbarkeit, Nutzerführung und erkennbare Reibungspunkte der Webanwendung. Die Ergebnisse werden in einem eigenen Bericht mit priorisierten Beobachtungen dokumentiert. Umfang, Ziele und Vergütung werden getrennt von der Testautomatisierung vereinbart.
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