Entwicklungstempo ohne Testtempo ist Kontrollverlust
KI hat die Softwareentwicklung überall beschleunigt. Dieselbe Engineerin, die früher ein Feature pro Woche auslieferte, refaktoriert heute drei Module und prototypisiert ein viertes. Wenn der Testprozess nicht im selben Mass komprimiert hat, fliessen mehr Änderungen durch dasselbe enge Tor, das Tor wird zum Engpass - oder schlimmer: es wird übersprungen, und die Produktion wird stillschweigend zur Testumgebung.
Mit mehr Testern holen Sie nicht auf. Was aufholt: eine Regressionssuite, die unbeaufsichtigt auf jedem Schritt vor dem Release läuft, gebaut und gepflegt von erfahrenen Engineers, die KI nutzen, um eine Woche Testskripten auf einen Nachmittag zu komprimieren. Genau das liefert dieser Service.
Sie möchten zuerst die ausführliche Argumentation? Lesen Sie Getestet ist nicht getestet.
Wann das passt
- Engineers liefern schneller (mit oder ohne KI-Unterstützung) und die Verifikation ist zum Engpass geworden.
- “Getestet” heisst heute ein Jira-Ticket mit Häkchen, nicht eine grüne CI-Pipeline, in der die volle Regressionssuite gelaufen ist.
- Releases verzögern sich, weil manuelle Testdurchläufe nicht mehr in den Takt passen, den das Geschäft heute erwartet.
- Das Produkt läuft in mehreren Sprachversionen, und Bugs treten nur in der Sprache auf, die niemand im Team liest.
- Eine Modernisierung, eine Migration oder ein grosser Refactor steht an, und das bestehende Testnetz würde die Regressionen nicht abfangen.
- Audit-, Aufsichts- oder Zertifizierungsarbeit braucht dokumentierte, wiederholbare Testbelege - nicht einen Screenshot-Ordner.
Was wir liefern
Teststrategie und -audit
Wir starten mit einem Audit dessen, was Sie heute haben: wo die Lücken tatsächlich sind, und was im nächsten Quartal den höchsten ROI bringt. Die Strategie, die daraus folgt, ist ISTQB-verankert - eine Test-Pyramide, risiko-basierte Priorisierung und eine explizite Karte davon, was wo läuft (PR-Check, Integrations-Build, Staging-Promotion, Pre-Prod-Gate). Tooling (Playwright, Cypress, Jest, JUnit, k6, Lighthouse, eigene Harnesses) wird aus Ihrem Stack gewählt, nicht aus einer Anbieterbroschüre. Was Sie mitnehmen, ist eine Roadmap zu einem Testnetz, das mitwächst - gemessen in Cycle-Time-to-Verified-Shippable, nicht in Tester-Stunden.
Automatisierung, die mitwächst
End-to-End-Suiten entstehen mit KI-gestützter Aufzeichnung: eine erfahrene Engineerin durchläuft das Feature einmal mit einem LLM-unterstützten Explorations-Tool, und der Durchlauf landet noch am selben Nachmittag in der Regressionssuite. Darunter passen Unit- und Integrationstests zur tatsächlichen Architektur - nicht eine dünne Schicht spröder UI-Tests, die vorgibt, Coverage zu sein. Alles läuft in CI: jeder Pull-Request durch die Pipeline, jede Staging-Promotion durch das Gate, nichts wird manuell vergessen. Ein Flake-Budget - Quarantäne beim ersten Flake, Fix-or-Delete im selben Sprint, Kill-Switch, wenn eine ganze Test-Klasse das Vertrauen verliert - hält die Suite vertrauenswürdig statt stillgelegt. Testdaten werden mit Datenschutzfokus verwaltet: keine echten Kundendaten in Testumgebungen.
API- und systemübergreifende Verifikation
UI-Tests sind eine Schicht. Die meisten Bugs, die in die Produktion entwischen, leben in den Nahtstellen zwischen Systemen - das Portal hat es angezeigt, aber die Backend-Integration hat es nie empfangen; die API gab 200 zurück, aber der nachgelagerte Datensatz ist falsch; der Staging-Vertrag funktioniert, der Prod-Vertrag nicht.
Unsere API-Test-Suiten zielen auf jede Umgebung - Dev, Staging, Pre-Prod, Read-Only-Prod - auf demselben Code-Pfad, damit Vertrags-Drift zwischen Stufen als Test-Failure auftaucht, nicht als Kunden-Ticket. Darauf aufgesetzt spielt die systemübergreifende Reconciliation einen realen Geschäftsfluss durch das Portal, die API und das integrierte Backend-System und prüft, dass der Zustand an jeder Stelle übereinstimmt: gleicher Datensatz, gleiche Felder, gleiche Summen, gleicher Audit-Trail. Wo es sich auszahlt, ergänzen wir consumer-driven Vertragstests, damit eine Drittanbieter-API-Änderung die Integration nicht zwei Sprints später still kaputt macht. Dieselben Flüsse laufen als synthetisches Monitoring in Produktion, damit eine Integrations-Panne innert Minuten aus dem Canary auftaucht, nicht innert Wochen aus einem Kunden-Ticket. Testdaten und Fixtures sind umgebungsbewusst - sie überleben die Rate-Limits, Daten-Resets und Isolations-Regeln der Integrations-Partner.
Performance, Barrierefreiheit und Resilienz
- Last- und Stresstests mit definierten SLOs und Regressionserkennung bei jedem Release.
- Barrierefreiheits-Prüfungen (WCAG 2.2 AA) in CI eingebaut - nicht ein einmaliges Audit vor dem Launch.
- Lighthouse- und Smoke-Tests bei jedem Deploy.
- Chaos- und Failure-Mode-Übungen für Systeme, in denen Verfügbarkeit der Vertrag ist.
Sicherheitsprüfungen in der Build-Pipeline
Der Code, der durch die Build-Pipeline läuft, trägt seine eigenen Sicherheitsgates. Wir behandeln SAST und DAST als erstklassige Qualitätsprüfungen der ausgelieferten Software - nicht als separaten Strom, der einmal pro Jahr läuft.
SAST läuft auf jedem Pull-Request: Geheimnisse, Injection-Sinks, unsichere Deserialisierung und kryptografischer Missbrauch werden erfasst, bevor der Code landet. DAST läuft auf jeder Staging-Promotion und prüft die laufende Anwendung gegen die OWASP-Top-10-Kategorien an echten Endpoints. Dependency-Scanning passiert zur Build-Zeit, damit eine neue verwundbare transitive Abhängigkeit den Build per Policy fehlschlagen oder warnen lässt - nicht erst drei Monate später durch Zufall. Befunde werden wie jeder andere Test-Failure triagiert: klassifiziert, mit Owner, zeitlich begrenzt, niemals stillschweigend stummgeschaltet. Alles, was nach dem Build-Artefakt lebt - SBOM-Tracking, Infrastruktur-CVE-Abgleich, Ausnutzbarkeitsbewertung - geht an Betrieb & Härtung.
Testen in der Sprache des Kunden
- Lokalisierungs- und i18n-Tests, die laut fehlschlagen, wenn CHF 1'000.50 als 1.000,50 gerendert wird oder “Mwst.” zu “MwSt.” wird.
- Datums-, Währungs- und Adressformat-Prüfungen für jede Sprachversion, die Sie ausliefern.
- Trilinguale Review der gerenderten UI - durch Menschen, die Deutsch, Französisch und Englisch tatsächlich lesen.
Wo KI in unserer Test-Schleife ansetzt
Wir nutzen KI, um Wochen auf Tage zu komprimieren - nicht, um etwas auszuliefern, was wir auch ohne sie nicht ausliefern würden.
KI-gestützte Testaufzeichnung ist die grösste einzelne Veränderung: ein Feature wird einmal durchlaufen, der deterministische Test landet noch am selben Nachmittag in der Suite. Wenn etwas fehlschlägt, fragt die Person im On-Call die Suite “warum ist das fehlgeschlagen” und bekommt eine priorisierte Hypothese von einem LLM, statt eine Wand voller Stack-Traces von oben nach unten lesen zu müssen. Generierte Testdaten und Edge-Cases decken kombinatorische Räume ab, die kein Mensch von Hand schreiben würde. Jedes KI-unterstützte Test-Asset geht durch ein Senior-Review-Gate - wer es einreicht, verantwortet es, genauso wie ohne KI. Und keine Kundendaten in öffentlichen LLMs ist unsere Voreinstellung: keine personenbezogenen Daten werden an KI-Tools gegeben, und wir bieten selbst gehostete Modelle in der Schweiz oder Europa, wenn die Arbeit es verlangt.
Wie wir arbeiten
Wir verankern uns am ISTQB Body of Knowledge: Teststrategie, Testmanagement, Testautomatisierung, Performance-Tests. So hält die Testarbeit stand, wenn Ihr Auditor sie prüft. Jedes Mandat startet mit einem klaren Scoping, hat verbindliche Zwischenstände und endet mit einem schriftlichen Bericht: Management-Zusammenfassung, was wo läuft, die Kennzahlen, die zählen (Cycle-Time-to-Verified, Escape-Rate, Flake-Rate), und die Prioritäten für den nächsten Sprint.
Für Application-Security-Tests, einschliesslich OWASP-konformer Pentests und Red-Team-Arbeit, siehe Betrieb & Härtung.
Warum Luzid
- Erfahrene Engineers, die Ihren Stack, die Sprache Ihrer Kunden und das Testdesign lesen können - nicht ein Remote-Tester-Pool, abgerechnet nach Stunden.
- Strategie, Design, Automation und Performance - ein Team. ISTQB-verankert, in einer Qualität, die Ihr Auditor erwartet.
- KI als Hebel auf der Testseite, nicht nur auf der Dev-Seite - damit die Verifikation gleich schnell komprimiert wie die Entwicklung.
- Test-Reports sprechen die Sprache der Stakeholder, nicht nur der Entwickler.
- Dreisprachig in Deutsch, Französisch und Englisch.
Ersetzen Sie unser internes QA-Team?
Nein. Wir arbeiten mit dem Team, das Sie haben - bringen Teststrategie, Automatisierungs-Muskel und KI-gestützte Aufzeichnung ein, wo das Tempo bringt. Das Endspiel ist, dass Ihr Team eine Suite besitzt, der es vertraut, nicht dass wir unentbehrlich werden.
Können Sie eine bestehende Cypress-, Playwright- oder Selenium-Suite übernehmen?
Ja. Wir starten mit einem Audit (was läuft, was ist stummgeschaltet, was ist flaky, welche Coverage ist echt), dann bringen wir alles unter ein einziges CI-Gate mit explizitem Flake-Budget. Der grösste Teil des Werts kommt aus der Strategie-Ebene, nicht aus dem Neuschreiben funktionierender Tests.
Testen Sie nur die UI oder auch APIs und integrierte Systeme?
Beides - und in der Regel legen wir das Gewicht auf die API- und systemübergreifende Schicht, weil dort die meisten produktionsrelevanten Bugs sitzen. Wir treffen APIs in jeder Umgebung auf demselben Code-Pfad und spielen Reconciliation-Flüsse, die einen realen Geschäftsfall durch das Portal, die API und das integrierte Backend-System führen - und prüfen, dass derselbe Datensatz mit denselben Feldern und demselben Audit-Trail an jeder Stelle erscheint. UI-E2E sitzt obendrauf, nicht als einzige Schicht.
Was bedeutet 'KI-gestützte Testaufzeichnung' konkret?
Eine erfahrene Engineerin durchläuft ein Feature mit einem LLM-unterstützten Explorations-Tool. Der Durchlauf wird in einen deterministischen, wiederholbaren End-to-End-Test überführt - reviewed und committed am selben Tag. Was früher eine Woche Testskripten war, ist ein Nachmittag. Das Asset läuft danach unbeaufsichtigt auf jeder Promotion-Stufe.
Wo sitzen SAST und DAST in Ihrer Testpipeline?
SAST läuft auf jedem Pull-Request - es liest den Code statisch und meldet Geheimnisse, Injection-Sinks, unsichere Deserialisierung und Krypto-Missbrauch, bevor die Änderung landet. DAST läuft auf jeder Staging-Promotion - es prüft die laufende Anwendung gegen OWASP-Top-10-Kategorien an echten Endpoints. Beides ist per Policy gegated und wird wie jeder andere Test-Failure triagiert, mit klassifiziertem Owner und Zeitfenster. Es sind Qualitätsprüfungen der ausgelieferten Software, kein einmaliges Audit pro Jahr.
Wie verhindern Sie, dass die Suite flaky wird?
Jedes Projekt bekommt eine explizite Flake-Politik: Quarantäne beim ersten Flake, Fix-or-Delete im selben Sprint, Kill-Switch, wenn eine ganze Test-Klasse das Vertrauen verliert. Ein stummgeschalteter Test ist schlimmer als kein Test.
Was kostet das Aufsetzen gegenüber dem Betrieb?
Das Aufsetzen ist ein einmaliger Block (Audit + Strategie + initiale Automatisierungs-Backbone), typischerweise Wochen, nicht Monate. Danach trägt jede Entwicklungs-Iteration zwei laufende Test-Kosten: die Test-Suiten anpassen, damit sie abdecken, was hinzugekommen oder verändert wurde, und die Suiten laufen lassen plus die Resultate auswerten - inklusive der Triage, die Ihnen Defekt für Defekt sagt, ob der nächste richtige Schritt eine Code-Korrektur, eine Konfigurations-Korrektur oder eine operative Behelfslösung ist, die die Stellung hält, bis ein richtiger Fix ausgeliefert werden kann. Im stationären Zustand landet das bei 30% bis 50% der Feature-Engineering-Kapazität auf den meisten Produkten. Wir wollen diesen Anteil komprimieren, nicht erhalten.
Machen Sie auch Pentests und Red-Team-Engagements?
Ja - die liegen unter Betrieb & Härtung, unserem Betriebs- und Sicherheitsservice, neben SBOM-getriebener CVE-Antwort und Infrastruktur-Introspektion. Wir behandeln szenario-getriebene Sicherheitsarbeit und die produktionsseitige Sicherheitslage als eigene Disziplin, damit der QA-Service auf funktionaler, performance-, lokalisierungs- und pipeline-interner Sicherheitsverifikation fokussiert bleibt.