Plattform
Automatisierte QA für ernsthafte KI-Softwarelieferung
Jede KI-geschriebene Änderung wird so getestet, wie ein Nutzer sie erleben würde — in einem echten Browser, bevor sie veröffentlicht wird und nachdem sie live gegangen ist.
Ciao QA ist die automatisierte Testebene der Plattform: deterministische Browser-Replays, selbstheilende Tests, Smoke-Gates vor der Veröffentlichung und Produktionsprüfungen danach. Anders als Testsuiten, die verrotten, während sich die Anwendung ändert, reparieren sich Ciaos Tests selbst, wenn sich die UI weiterentwickelt — sodass die Abdeckung mit KI-Tempo-Entwicklung Schritt hält, statt dahinter zurückzufallen.
Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03
KI schreibt schneller, als Menschen testen können
KI-gestützte Entwicklung verschiebt den Engpass. Code, der früher einen Sprint brauchte, kommt an einem Nachmittag an — und jede dieser Änderungen kann Checkout, Login oder den Report kaputt machen, den ein Direktor jeden Montag liest. Manuelles Durchklicken der App skaliert nicht mit diesem Tempo, und traditionelle Testsuiten verfallen in dem Moment, in dem sich die UI unter ihnen verschiebt.
Ciao QA ist für dieses Tempo gebaut. Es führt deterministische Browser-Replays, selbstheilende Tests, Smoke-Gates vor der Veröffentlichung und Produktionsprüfungen danach aus — automatisch, bei jeder Änderung, als Teil desselben Kreislaufs, der den Code geschrieben hat.
Wie QA funktioniert
QA läuft als Teil des Delivery-Loops — nichts hier ist ein separates Tool, das man einführen muss, oder eine Pipeline, die man pflegen muss.
1. Abläufe werden als Replays erfasst
Wichtige Nutzer-Journeys — anmelden, einen Datensatz anlegen, zur Kasse gehen — werden als deterministische Browser-Replays erfasst: dieselben Schritte, dieselben Eingaben, dieselben erwarteten Ergebnisse, bei jedem Lauf.
2. Tests laufen in einem echten Browser
Replays laufen gegen die tatsächliche Anwendung, so wie ein Nutzer sie erleben würde — echtes Rendering, echtes Netzwerk, echte Authentifizierung — nicht gegen gemockte Komponenten.
3. Tests heilen, statt zu verrotten
Wenn sich die UI berechtigterweise ändert — ein Button verschiebt sich, ein Label wird umformuliert — aktualisieren sich selbstheilende Tests, um der neuen Realität zu entsprechen, statt an einem veralteten Selektor zu scheitern und gelöscht zu werden.
4. Smoke-Gates halten die Tür
Vor jeder Veröffentlichung laufen Smoke-Gates die kritischen Replays. Ein fehlgeschlagenes Gate stoppt die Veröffentlichung, sodass die kaputte Version nicht dadurch ausgeliefert wird.
5. Produktionsprüfungen schließen den Kreislauf
Nach der Veröffentlichung laufen Prüfungen gegen die Live-Anwendung, um zu bestätigen, dass das Release sich in Produktion verhält, wo Konfiguration und Daten echt sind.
6. Fehlschläge kommen als Arbeit zurück
Eine fehlgeschlagene Prüfung landet mit Kontext zurück im Kreislauf — welcher Schritt fehlschlug und was erwartet wurde — wo die Korrektur gebaut und erneut verifiziert werden kann.
Warum es wichtig ist
Deterministisch ist wichtig, weil flackernde Tests Teams beibringen, Rot zu ignorieren. Wenn ein Replay fehlschlägt, hat sich tatsächlich etwas geändert — was das Signal handlungswert macht und das Gate vertrauenswürdig.
Selbstheilung ist wichtig, weil die Alternative eine Suite ist, die still stirbt. Abdeckung, die sich selbst erhält, hält mit KI-Tempo-Änderungen Schritt, sodass die hundertste Änderung so gründlich getestet wird wie die erste. Und Gates auf beiden Seiten der Veröffentlichung bedeuten, dass „es hat in der Vorschau funktioniert“ und „es funktioniert in Produktion“ beide verifiziert sind, nicht angenommen.
Die Gewohnheit, die das aufbaut, ist der Punkt. Wenn jede Veröffentlichung gegated ist und jedes Release in Produktion geprüft wird, hört Ausliefern auf, ein Akt des Mutes zu sein. Teams machen mehr Änderungen, in kleineren Stücken, weil die Kosten eines Fehlers eine gestoppte Veröffentlichung sind statt ein kaputter Montag — und das Audit-Protokoll zeigt jedes Gate, das jedes Release bestanden hat.
Wer es nutzt
QA ist eine der sechs Rollen in Ciaos KI-Softwareorganisation, und verschiedene Menschen stützen sich unterschiedlich darauf.
- Nicht-Ingenieure, die echte Apps ausliefern — Menschen, von denen man nicht erwarten kann, dass sie Testsuiten schreiben, bekommen trotzdem eine — erfasst aus den Abläufen, die ihre App tatsächlich hat.
- Engineering-Führungskräfte — Gates statt Versprechen: Eine Veröffentlichung, die ihr Smoke-Gate nicht bestanden hat, geht nicht raus, egal wer sie angefordert hat.
- Agenturen — Jede Kundenanwendung bekommt geschützte Journeys ohne QA-Budget pro Projekt oder eine handgepflegte Suite pro Kunde.
- Betriebs- und Support-Teams — Produktionsprüfungen fangen Regressionen in der Live-App ab, sodass Probleme als Befunde auftauchen statt als Support-Tickets.
Hinweise zu Sicherheit und Governance
- ✓ Smoke-Gates laufen vor jeder Veröffentlichung; Produktionsprüfungen laufen danach.
- ✓ Replays sind deterministisch — dieselben Schritte, dieselben Daten, dasselbe erwartete Ergebnis bei jedem Lauf.
- ✓ Selbstheilung hält die Abdeckung lebendig, während sich die UI weiterentwickelt.
- ✓ QA-Ergebnisse fließen in den Projektzustand in Conductor ein, sichtbar über die gesamte Fleet.
- ✓ Testergebnisse treten dem unveränderlichen Audit-Protokoll neben Merges und Deployments bei.
Eine handgepflegte Suite vs Ciao QA
Der Kontrast zu einer handgepflegten Suite ist strukturell, nicht kosmetisch.
| Handgepflegte Testsuite | Ciao QA | |
|---|---|---|
| Erstellung | Ingenieure schreiben und aktualisieren Skripte | Abläufe werden erfasst, während die App gebaut wird |
| UI-Änderungen | Selektoren brechen; Tests werden übersprungen | Tests heilen sich selbst, um der neuen UI zu entsprechen |
| Vor der Veröffentlichung | CI läuft, wenn jemand es eingerichtet hat | Smoke-Gates stoppen eine fehlschlagende Veröffentlichung |
| Nach der Veröffentlichung | Monitoring, falls konfiguriert | Produktionsprüfungen verifizieren die Live-App |
| Flackernde Fehlschläge | Neu ausführen und hoffen | Deterministische Replays — Rot bedeutet, dass sich etwas geändert hat |
Häufig gestellte Fragen
Was bedeutet deterministisch hier?
Replays laufen mit denselben Schritten, denselben Eingaben und denselben Erwartungen jedes Mal. Ein Fehlschlag bedeutet daher, dass sich die Anwendung geändert hat, nicht dass der Test gewackelt hat — was es vernünftig macht, eine Veröffentlichung darauf zu gaten.
Muss ich selbst Tests schreiben?
Nein. Wichtige Journeys werden erfasst, während die Anwendung gebaut wird, und du kannst die Abläufe hinzufügen, die für dein Geschäft am wichtigsten sind. Ingenieure können prüfen und erweitern, was läuft — es ist Teil des Projekts, keine Black Box.
Was passiert, wenn ein Smoke-Gate fehlschlägt?
Die Veröffentlichung stoppt. Der Fehlschlag kommt mit Kontext zurück — der Schritt, die Erwartung, was stattdessen passiert ist —, sodass die Korrektur gemacht und erneut verifiziert werden kann. Wenn das Gate grün ist, geht die Veröffentlichung weiter.
Was sind Produktionsprüfungen, und warum laufen sie nach der Veröffentlichung?
Vorschau und Produktion unterscheiden sich: Konfiguration, Daten, Integrationen und Traffic sind nur in einer von beiden echt. Produktionsprüfungen laufen nach jedem Release gegen die Live-Anwendung, um zu bestätigen, dass sie sich dort verhält, wo es zählt, und Befunde fließen an Doctor und SysOps zur Diagnose und Reaktion.
Ersetzt das QA-Ingenieure?
Nein — es verändert, womit sie ihre Zeit verbringen. Die mechanische Arbeit, Browser-Tests am Leben zu halten, ist automatisiert; Menschen entscheiden, welche Journeys kritisch sind, prüfen, was die Gates abfangen, und heben die Messlatte mit der Zeit.