Platform
Geautomatiseerde QA voor serieuze AI-softwarelevering
Elke door AI geschreven wijziging wordt getest zoals een gebruiker het zou ervaren — in een echte browser, vóór publicatie en nadat hij live gaat.
Ciao QA is de geautomatiseerde testlaag van het platform: deterministische browser-replays, self-healing tests, smoke gates vóór publicatie en productiechecks na publicatie. In tegenstelling tot testsuites die rotten naarmate de applicatie verandert, herstellen de tests van Ciao zichzelf wanneer de UI evolueert — zodat dekking gelijke tred houdt met ontwikkeling op AI-snelheid in plaats van erachteraan te lopen.
Gepubliceerd 2026-07-03 · Laatst bijgewerkt 2026-07-03
AI schrijft sneller dan mensen kunnen testen
AI-assisted development verplaatst het knelpunt. Code die vroeger een sprint kostte, komt in een middag binnen — en elk van die wijzigingen kan checkout, login of het rapport dat een directeur elke maandag leest breken. Handmatig door de app klikken schaalt niet naar dat tempo, en traditionele testsuites verval het moment dat de UI eronder verschuift.
Ciao QA is gebouwd voor dat tempo. Het draait deterministische browser-replays, self-healing tests, smoke gates vóór publicatie en productiechecks na publicatie — automatisch, bij elke wijziging, als onderdeel van dezelfde loop die de code schreef.
Hoe QA werkt
QA draait als onderdeel van de delivery-loop — niets hier is een apart tool om aan te nemen of een pipeline om te onderhouden.
1. Flows worden vastgelegd als replays
Belangrijke gebruikersreizen — inloggen, een record aanmaken, afrekenen — worden vastgelegd als deterministische browser-replays: dezelfde stappen, dezelfde invoer, dezelfde verwachte resultaten, elke run.
2. Tests draaien in een echte browser
Replays draaien tegen de echte applicatie zoals een gebruiker het zou ervaren — echte rendering, echt netwerk, echte auth — niet tegen gemockte componenten.
3. Tests herstellen in plaats van te rotten
Wanneer de UI legitiem verandert — een knop verplaatst, een label wordt herschreven — werken self-healing tests zichzelf bij om de nieuwe realiteit te matchen in plaats van te falen op een verouderde selector en verwijderd te worden.
4. Smoke gates houden de deur
Vóór elke publicatie draaien smoke gates de kritieke replays. Een falende gate stopt de publicatie, zodat de kapotte versie er niet doorheen gaat.
5. Productiechecks sluiten de loop
Na publicatie draaien checks tegen de live applicatie om te bevestigen dat de release zich gedraagt in productie, waar configuratie en data echt zijn.
6. Fouten komen terug als werk
Een falende check landt terug in de loop met context — welke stap faalde en wat werd verwacht — waar de fix kan worden gebouwd en herverifieerd.
Waarom dit ertoe doet
Deterministisch is belangrijk omdat flaky tests teams leren rood te negeren. Wanneer een replay faalt, is er echt iets veranderd — wat het signaal de moeite waard maakt om op te handelen en de gate de moeite waard om te vertrouwen.
Self-healing is belangrijk omdat het alternatief een suite is die stilletjes sterft. Dekking die zichzelf onderhoudt houdt gelijke tred met verandering op AI-snelheid, zodat de honderdste wijziging net zo grondig wordt getest als de eerste. En gates aan beide kanten van publicatie betekenen dat 'het werkte in preview' en 'het werkt in productie' allebei geverifieerd zijn, niet aangenomen.
De gewoonte die dit bouwt is het punt. Wanneer elke publicatie gated is en elke release in productie wordt gecontroleerd, houdt leveren op een daad van moed te zijn. Teams maken meer wijzigingen, in kleinere stukken, omdat de kost van ongelijk hebben een gestopte publicatie is in plaats van een gebroken maandag — en de audit trail toont elke gate die elke release doorstond.
Wie gebruikt het
QA is een van de zes rollen in de AI-software-organisatie van Ciao, en verschillende mensen leunen er anders op.
- Niet-engineers die echte apps leveren — Mensen van wie niet verwacht kan worden dat ze testsuites schrijven krijgen er toch een — vastgelegd vanuit de flows die hun app daadwerkelijk heeft.
- Engineering-leiders — Gates in plaats van beloftes: een publicatie die zijn smoke gate niet doorstond gaat niet uit, wie het ook aanvroeg.
- Bureaus — Elke klantapplicatie krijgt beschermde reizen zonder een QA-budget per project of een handmatig onderhouden suite per klant.
- Operations- en supportteams — Productiechecks vangen regressies in de live app op, zodat problemen als bevindingen naar boven komen in plaats van supporttickets.
Security- en governance-notities
- ✓ Smoke gates draaien vóór elke publicatie; productiechecks draaien erna.
- ✓ Replays zijn deterministisch — dezelfde stappen, dezelfde data, dezelfde verwachte uitkomst elke run.
- ✓ Self-healing houdt dekking levend naarmate de UI evolueert.
- ✓ QA-resultaten voeden projectstatus in Conductor, zichtbaar over de fleet.
- ✓ Testuitkomsten sluiten aan bij de append-only audit trail naast merges en deploys.
Een handmatig onderhouden suite vs Ciao QA
Het contrast met een handmatig onderhouden suite is structureel, niet cosmetisch.
| Handmatig onderhouden testsuite | Ciao QA | |
|---|---|---|
| Schrijven | Engineers schrijven en updaten scripts | Flows vastgelegd als replays terwijl de app wordt gebouwd |
| UI-wijzigingen | Selectors breken; tests worden overgeslagen | Tests herstellen zichzelf om de nieuwe UI te matchen |
| Vóór release | CI draait als iemand het heeft opgezet | Smoke gates stoppen een falende publicatie |
| Na release | Monitoring, indien geconfigureerd | Productiechecks verifiëren de live app |
| Flaky fouten | Opnieuw draaien en hopen | Deterministische replays — rood betekent dat er iets is veranderd |
Veelgestelde vragen
Wat betekent deterministisch hier?
Replays draaien elke keer dezelfde stappen met dezelfde invoer en dezelfde verwachtingen. Een fout betekent dus dat de applicatie is veranderd, niet dat de test wiebelde — wat het redelijk maakt om een publicatie erop te gaten.
Moet ik zelf tests schrijven?
Nee. Belangrijke reizen worden vastgelegd terwijl de applicatie wordt gebouwd, en je kunt de flows toevoegen die het belangrijkst zijn voor je bedrijf. Engineers kunnen inspecteren en uitbreiden wat draait — het is onderdeel van het project, geen black box.
Wat gebeurt er als een smoke gate faalt?
De publicatie stopt. De fout komt terug met context — de stap, de verwachting, wat er in plaats daarvan gebeurde — zodat de fix kan worden gemaakt en herverifieerd. Wanneer de gate groen is, gaat de publicatie door.
Wat zijn productiechecks, en waarom draaien na publicatie?
Preview en productie verschillen: configuratie, data, integraties en verkeer zijn alleen echt in een van beide. Productiechecks draaien tegen de live applicatie na elke release om te bevestigen dat hij zich gedraagt waar het telt, en bevindingen stromen naar Doctor en SysOps voor diagnose en respons.
Vervangt dit QA-engineers?
Nee — het verandert waar ze tijd aan besteden. Het mechanische werk om browsertests levend te houden is geautomatiseerd; mensen beslissen welke reizen kritiek zijn, reviewen wat de gates opvangen en verhogen de lat na verloop van tijd.