QA The Other WayKwaliteitsborging voor het tijdperk van door AI geschreven tests. QA The Other Way.
Testontwerp

Een groen vinkje bewijst niet dat de test klopt

AI-agenten schrijven end-to-end-tests, maar een succesmelding bewijst niet dat gegevens zijn opgeslagen. Controleer het resultaat via een onafhankelijke route.

8 minuten leestijdQA The Other Way
Een ontvangstbewijs naast een schuifmaat, ter illustratie van onafhankelijke metingen.
Door AI gegenereerde redactionele illustratie.
Illustratieve video bij dit artikel. Engelse tekst op het scherm; selecteer ondertitels voor deze taal.

Vertaalde editie. Technische identificatiegegevens blijven in hun oorspronkelijke vorm.

De test klikt op "Verzenden". Er verschijnt een melding: "Opgeslagen". De test controleert die melding en slaagt. Drie weken later meldt een gebruiker dat de instellingen niet zijn bewaard. Dit is een voorbeeld, geen verslag van een werkelijk incident.

Niets aan dit verhaal is nieuw, en niets ervan vereist AI. Het is de standaardmanier waarop end-to-end-tests liegen: de controle let op de gebruikersinterface, en de gebruikersinterface is het ding dat wordt getest. Wanneer een AI-agent de tests schrijft, komt dezelfde faalwijze op industriële schaal terecht, omdat de agent ook leert wat hij moet beweren door naar de interface te kijken.

Het orakelprobleem, in één paragraaf

Elke test bestaat uit twee helften. De eerste helft doet iets. De tweede helft beslist of het resultaat goed is. Die tweede helft is het orakel, en het is de helft die ertoe doet. Een zwak orakel controleert het dichtstbijzijnde zichtbare signaal: een toost, een spinner die stopt, een URL-wijziging. Een sterk orakel controleert de uitkomst vanuit een onafhankelijke richting: het record in de database, de reactie van de API die de pagina oproept, de staat na een nieuwe herlaadbeurt.

Playwright's eigen gids met best practices maakt het aangrenzende punt over acties: tests moeten het gedrag verifiëren dat de eindgebruiker kan zien, en koppeling aan implementatiedetails zoals CSS-klassen vermijden. Hetzelfde principe toegepast op controleen geeft je de regel voor het AI-tijdperk. Beweer de uitkomst die een gebruiker zou controleren, via een pad dat de bug niet kan nabootsen.

Waarom door AI geschreven tests in de richting van zwakke orakels evolueren

Een agent die uw app verkent en tests schrijft, leert de app kennen vanaf het oppervlak. Het klikt, het kijkt wat er verandert, en het codeert precies dat: klik hierop, dan verandert dit. Een melding is een handig, deterministisch ogend signaal, zo beweert de agent over de melding. De agent is niet onzorgvuldig. Het heeft eenvoudigweg geen toegang tot uw intentie, alleen tot uw pixels.

Het automatische wachten van de toneelschrijver zorgt ervoor dat dit veiliger aanvoelt dan het is. Uitvoerbaarheidscontroles bevestigen dat een element zichtbaar en stabiel is en gebeurtenissen ontvangt voordat de klik terechtkomt. Beweringen die automatisch opnieuw worden geprobeerd, wachten op de verwachte voorwaarde. Beide verminderen timinggerelateerde fouten. Geen van beiden vraagt ​​of de voorwaarde de juiste was. Een test kan volkomen stabiel en volkomen fout zijn.

Drie Oracle-upgrades die vandaag werken

Herlaad en lees. Na het opslaan navigeert u weg en terug, of herlaadt u, en beweert dat de waarde er nog steeds is. Hiermee wordt de persistentie gecontroleerd zoals een gebruiker de afwezigheid ervan zou opmerken.

Beweer één laag lager. Toneelschrijver kan wachten op de netwerkreactie waarvan de gebruikersinterface afhankelijk is. Koppel de UI-controle met expect(response).toBeOK() op de API-aanroep die daadwerkelijk wordt opgeslagen, of voer direct na de UI-stroom een ​​query uit op de API en vergelijk de opgeslagen waarde.

Bekijk de bijwerking buiten de band. Voor een aanmelding vermeldt u dit in de outbox, het auditlogboek of de beheerderslijst, en niet op de welkomstbanner. De banner is ontworpen om te verschijnen; het record bestaat alleen als het systeem werkte.

De beoordelingsvraag die alles verandert

Als u agenten tests laat schrijven en mensen deze laat beoordelen, besteed dan beoordelingstijd aan één vraag per test: wat beweert dit en zou dit kunnen slagen als de functie kapot is? Het beoordelen van het gelukkige pad is het lezen van de test. Het beoordelen van het orakel is het testen van de test.

Dit is ook de eerlijke manier om een ​​tool als AnyTest te gebruiken. De agenten verkennen uw app vanaf een URL, bouwen end-to-end-tests en laten deze ter beoordeling achter. Het beoordelingsoppervlak toont elke stap en het resultaat ervan. Goed gebruikt, is die beoordeling de plaats waar de orakelcontrole plaatsvindt: niet "klikte de agent op de juiste dingen", maar "bewees de test die hij schreef iets". Uit het materiaal van de verkoper blijkt dat mensen nog steeds beslissen. Dit is de beslissing die ertoe doet.

Een groen vinkje geeft aan dat de test is uitgevoerd. Er staat nooit dat de test goed was.

Veelgestelde vragen

Wat is een testorakel?

Het deel van een toets dat beslist of je wel of niet slaagt. Een controle over een succesboodschap is een zwak orakel. Een controle over een onafhankelijk geverifieerde status, zoals gegevens na een herlaadbeurt of een API-query, is sterk.

Bewijst een geslaagde end-to-end-test dat de functie werkt?

Nee. Het bewijst dat de specifieke omstandigheden die de test beweerde waar waren. Als de controle alleen naar de gebruikersinterface kijkt, kan de functie eronder worden verbroken terwijl de test groen blijft.

Hoe controleer ik tests die zijn geschreven door een AI-agent?

Vraag bij elke test wat deze beweert en of deze kan slagen als de functie niet werkt. Geef de voorkeur aan tests die de persistente status verifiëren via een tweede pad: opnieuw laden, API-query of een out-of-band record.

Bronnen