Wie wir wirklich arbeiten
Fünf Phasen, verfeinert über 17 Jahre und Projekte in Fintech, E-Commerce, HR Tech, Logistik und mehr. Jeder Schritt basiert auf dem, was sich wiederholt bewährt hat — und was nicht.
Phase 1 · Discovery
Produkt verstehen & Risiko kartieren
Jedes Projekt beginnt mit derselben Frage: Wo kostet ein Bug am meisten? Bei einer Payment-Integration ist das der Checkout-Flow. Bei einer E-Commerce-Plattform sind es Suche, Warenkorb und Inventory-Sync. In einer regulierten Umgebung sind es Datenkorrektheit und Audit-Trails. Der erste Schritt ist eine strukturierte Analyse des Stacks, der vorhandenen Testabdeckung (oder deren Fehlen) und der geschäftskritischen Flows — kein generisches Checklisten-Review, sondern eine echte Einschätzung der Risikolage.
- →Anforderungs- und Architektur-Review
- →Risikobasierte Testumfangsdefinition
- →Analyse von Lücken in der bestehenden Abdeckung
- →JIRA / XRay Workspace-Setup und Issue-Struktur
- →Abstimmung über manuelle vs. automatisierte Aufteilung
Phase 2 · Test Design
Testfälle entwerfen, die wirklich Bugs finden
Das Testdesign ist die Phase, in der die meisten QA-Prozesse ihren Wert verlieren — generische Happy-Path-Tests, die echte Defekte nie entdecken. Der Ansatz hier: Cucumber BDD für automatisierungsgebundene Szenarien (Given/When/Then direkt an Akzeptanzkriterien geknüpft) und strukturierte manuelle Testfälle für explorative Abdeckung und Edge Cases. KI-gestützte Erstellung via Test Scribe beschleunigt die erste Entwurfsrunde aus JIRA-Tickets, ohne das nötige Urteilsvermögen beim Review zu ersetzen.
- →Cucumber / Gherkin-Szenarien aus JIRA-Akzeptanzkriterien
- →Manuelle Testfälle für Edge Cases und explorative Abdeckung
- →KI-gestützte Erstgenerierung mit Test Scribe (Ollama oder Gemini API)
- →XRay-Rückverfolgbarkeit: Anforderung → Testfall → Ausführungsergebnis
- →Testdatenstrategie — reale Eingaben, Grenzwerte, negative Pfade
Phase 3 · Automatisierung
Framework bauen, das das Team selbst pflegen kann
Ein von Grund auf gebautes Framework sollte nicht dauerhaft vom Ersteller gewartet werden müssen. Frameworks wurden bei CoachHub (NightWatch.js + Cucumber.js), Home24 (Codeception), Cornelsen (Protractor + Mocha), autoTicket (SoapUI + Groovy) und anderen aufgebaut oder neu strukturiert. Das durchgehende Prinzip: das richtige Tool für den vorhandenen Stack wählen, die Architektur einfach genug halten, damit das Team sie erweitern kann, und CI vom ersten Commit an angebunden — nicht als Nachgedanke.
- →Framework-Auswahl passend zum vorhandenen Tech-Stack
- →Projektstruktur und Coding-Konventionen von Anfang an definiert
- →Wiederverwendbare Komponenten: Page Objects, API-Clients, Data Factories
- →GitLab CI oder Jenkins Pipeline-Integration ab dem ersten Commit
- →Parallele Ausführung und Test-Reporting vor der Übergabe konfiguriert
Phase 4 · Ausführung & Abdeckung
Tests dort ausführen, wo es zählt — UI, API, Mobile, Last
Abdeckung ist kein Prozentsatz. Sie ist eine Funktion davon, welche Flows in Produktion fehlschlagen und ob die Testsuite sie vorher erkennt. Die Ausführung erfolgt mehrschichtig: API-Tests laufen bei jedem Commit schnell durch, UI-Tests bei Merge Requests, Performance-Tests vor Releases oder Kampagnen. Mobile-Abdeckung via WebdriverIO (iOS und Android) wird ergänzt, wenn das Produkt eine native oder Hybrid-App ausliefert.
- →API-End-to-End-Tests — REST, GraphQL, SOAP, RabbitMQ
- →UI-Automatisierung — Cross-Browser, Cross-Platform
- →Mobile-Automatisierung — iOS und Android (WebdriverIO / Appium)
- →Performance- und Lasttests — K6, Gatling, JMeter
- →Ausführungsergebnisse in XRay mit Pass/Fail-Rückverfolgbarkeit synchronisiert
Phase 5 · Übergabe & Kontinuität
Das Team besser zurücklassen als man es vorgefunden hat
Ein QA-Projekt, das damit endet, dass das Team vom Berater abhängig ist, hat nicht wirklich Erfolg gehabt. Wissenstransfer ist von Anfang an eingebaut — durch dokumentierte Architektur, Code-Kommentare bei nicht offensichtlichen Entscheidungen und praxisnahe Schulungen für die Ingenieure, die die Suite betreiben und erweitern werden.
- →Framework-Dokumentation und Runbook
- →Praxisnahe Schulungen für QA- und Entwicklungsteam
- →Test-Wartungsrichtlinien und Contribution-Workflow
- →Pipeline-Monitoring und Alerting-Konfiguration
- →Einstellungskriterien und Onboarding-Material (Team-Aufbau-Projekte)
Bereit für Ihre QA-Transformation?
Lassen Sie uns über Ihren Stack, Ihre Risiken und den richtigen Einstiegspunkt sprechen.
Projekt besprechen