FAQ

Wir entwickeln automatisierte Prüfungen für browserbasierte Software, Portale und Webanwendungen über die Benutzeroberfläche und binden sie in Ihre CI/CD ein. Ziel ist Release-Sicherheit: kritische Flows werden regelmäßig automatisch geprüft, statt bei jedem Update manuell nachgetestet zu werden.

Standardmäßig nein. Automatisiert wird gegen Stage/QA/UAT. Produktion ist ausgeschlossen, außer ausdrücklich und schriftlich vereinbart.

Funktionsfähige Stage-Zugänge, stabile Testkonten sowie verlässliche und zuverlässig rücksetzbare Testdaten (Reset-Mechanismus). Zusätzlich müssen WAF/Rate Limits/Anti-Bot so konfiguriert sein, dass Automatisierung nicht blockiert wird.

Robuste Locators sind Voraussetzung. Bevorzugt werden Rollen, Labels und andere nutzernahe Attribute; data-testid oder eine gleichwertige Test-ID können vereinbart werden, wenn das nicht reicht. Ohne eine belastbare Locator-Strategie pausieren wir und fordern Nachbesserung an.

Automatisierte Prüfungen der zu testenden Webanwendung über die Benutzeroberfläche im Browser. Externe Systeme (z. B. Payment, SSO, E-Mail) sind nur als separat beauftragte Zusatzmodule enthalten und ausschließlich mit Sandbox- oder Testzugängen.

Browser und Viewports werden passend zu den kritischen Nutzerflüssen gemeinsam festgelegt und im Angebot beschrieben. Möglich sind vereinbarte Desktop- oder mobile Playwright-Viewports; echte Geräte und Emulatoren sind nicht Bestandteil der Leistung.

Im Repository des Auftraggebers, in der vorhandenen CI. GitHub Actions ist ein häufiges Beispiel; andere CI-Systeme sind möglich. Ausführung erfolgt automatisch im Kunden-Repo, der Report wird als Artefakt bereitgestellt. Im Rahmen eines optionalen Pflegevertrags unterstützen wir zusätzlich bei der Secrets-Rotation, sofern Zugriff eingeräumt wird.

Standard ist der Playwright HTML-Report. In der vorhandenen CI werden Reports, Traces und Screenshots bereitgestellt. GitHub Actions ist ein häufiges Beispiel; andere CI-Systeme sind möglich. Weitere Integrationen (z. B. JUnit, Allure, Testmanagement) nur nach Beauftragung.

„Flaky" heißt: Ein Test wechselt zufällig zwischen Pass und Fail, obwohl das System unverändert ist. Die Ursache wird sauber dokumentiert und zugeordnet: Testproblem oder Umgebung/Testdaten/Rate Limits/WAF.

Für browserbasierte Software jeder Art - beispielsweise SaaS, Online-Shops, Portale, Admin-Oberflächen, ERP-/SAP-Weboberflächen, CRM-Systeme, Inventur- oder interne Unternehmensanwendungen.

Nein. Die QA-Beratung ist keine ausgelagerte manuelle Testabteilung. Ziel ist, Testabdeckung, Priorisierung, QA-Prozesse und Testbarkeit so zu verbessern, dass Qualität systematisch abgesichert werden kann.

Wenn noch unklar ist, welche Abläufe wirklich kritisch sind, welche Tests benötigt werden oder welche Testfälle sich für Automation eignen. Dann sollte zuerst die Testbasis strukturiert und priorisiert werden.

Ja. Im vereinbarten Bereich können auch Usability-Reviews und Accessibility-Prüfungen eingeplant werden. Usability-Ergebnisse werden als priorisierte Beobachtungen festgehalten. Accessibility umfasst unter anderem Tastatur, Fokusprüfung, semantische Struktur und Screenreader.

Im kostenlosen virtuellen Erstgespräch werden Produkt, Bedarf und gewünschter Leistungsbereich besprochen. Danach kann Velvionix einen klar abgegrenzten Auftrag mit Leistungsumfang, Ergebnis, Abnahmekriterien und Preis anbieten.

Der Aufwand hängt stark von Anwendungskomplexität, Einarbeitung, vorhandener Dokumentation, Testzugängen, Prozessen und gewünschtem Ergebnis ab. Ein belastbarer Preis ist deshalb erst möglich, wenn der konkrete Leistungsbereich verstanden wurde.

Ja. QA-Beratung und Playwright-Testautomatisierung können getrennt beauftragt werden. Wenn bereits klar ist, welche Pfade automatisiert werden sollen und die technischen Voraussetzungen stimmen, kann direkt mit der Automatisierung gestartet werden.

Ja. Wenn weitere Unterstützung sinnvoll ist, wird der nächste Bereich separat vereinbart. So kann eine langfristige Zusammenarbeit entstehen, ohne einen unbegrenzten Auftrag zu schaffen.

Nein. Abstimmungen, Workshops, Analysen und technische Umsetzung finden vollständig remote statt.

Die Abnahme erfolgt modular nach vereinbartem Prüfumfang. Bei nachweislich falschen oder unvollständigen Prüfungen sind zwei Korrekturschleifen pro Modul enthalten. Automatisierte Prüfungen werden als fokussierte Flows umgesetzt - keine monolithischen Abläufe, die mehrere Bereiche in einem Test abdecken und lange Laufzeiten erzeugen.

Wir automatisieren nicht die gesamte Webanwendung auf einmal. Im Erstgespräch legen wir gemeinsam einen ersten sinnvollen Scope fest, der sich in einem überschaubaren Schritt liefern lässt. Diesen Teil setzen wir um und stellen ihn zur Abnahme bereit. Nach der Abnahme rechnen wir diesen Schritt ab. Erst danach beginnt der nächste vereinbarte Teil. Wie wir die Arbeit in Meilensteine teilen, besprechen wir gemeinsam. Maßgeblich sind die kritischen Pfade, die technische Ausgangslage und welcher nächste Schritt den größten Nutzen bringt.

Ja - optional, aber klar empfohlen. Je nach Vereinbarung umfasst die Pflege monatliche Playwright- und Dependency-Updates (inkl. erforderlicher Anpassungen zur Wiederherstellung der Lauffähigkeit im vereinbarten Umfang), die Pflege und Anpassung der CI-Workflows (z. B. Job-Anpassungen, Reports/Artefakte, Unterstützung bei Secrets-Rotation und Required Checks, sofern Zugriff vorhanden) sowie eine Reaktionszeit von 48 Stunden an Werktagen für Analyse und Rückmeldung mit Plan bei gemeinsam als kritisch eingestuften CI- oder Test-Ausfällen. Infrastruktur, VPN-Zugänge sowie Einrichtung oder Betrieb von selbst gehosteten Runnern sind nicht Bestandteil und werden vom DevOps-Team des Kunden bereitgestellt. Neue Testfälle oder neue Bereiche sind separat zu beauftragen.

Im Technischen Erstgespräch werden Zielsetzung, kritische User-Flows (Prio 1) und die technische Ausgangslage geklärt. Dazu gehören insbesondere Stage/QA/UAT, stabile Testkonten, verlässliche Testdaten, ein Reset-Mechanismus sowie WAF/Rate Limits. Anschließend wird ein erstes Modul (Testumfang) definiert und ein transparentes Angebot inklusive Abnahmekriterien und Zeitplan erstellt.

Die Umsetzung gliedert sich in Module: 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. Alles außerhalb des vereinbarten Modulblatts wird vorab transparent als Change Request angeboten.