Testautomatisering in gewone taal

Testautomatisering in gewone taal is geautomatiseerd testen waarbij de test een zin is en geen script. Je schrijft wat er zou moeten gebeuren — ‘log in als een standaardgebruiker, leg een laptop in het mandje en controleer of het totaal wordt bijgewerkt inclusief btw’ — en de tool bepaalt met welke elementen hij moet werken en of het resultaat klopte.

Het belang zit niet in bespaard typwerk. Het zit erin dat het verandert wie een test mag schrijven. Een suite met scripts kan alleen worden geschreven door mensen die programmeren, en dat is in de meeste organisaties een kleine en zwaar belaste groep. Een beschreven suite kan worden geschreven door wie dan ook die weet wat de software hoort te doen.

Twee generaties, vaak door elkaar gehaald

Producten in dit veld werken op een van twee behoorlijk verschillende manieren, en dat verschil telt zwaarder dan welke functievergelijking ook.

Gestructureerde gewone taal. Het Engels dat je schrijft komt uit een vastgelegd commandovocabulaire. De tool ontleedt je zin tot bekende acties en vindt elementen via locators. testRigor en Testsigma werken zo.

Vrije beschrijving. Je schrijft de zin zoals je wilt, en een AI-agent interpreteert de bedoeling tijdens de uitvoering en bepaalt zelf hoe hij die uitvoert. Testmode en Functionize werken zo.

	Gestructureerde grammatica	Vrije beschrijving
Wat je schrijft	Engels uit een gedocumenteerde commandoset	Elke zin
Leercurve	Een vocabulaire om te leren	Geen
Consistentie	Hoog — een test leest twee keer hetzelfde	Hangt af van hoe je schrijft
Determinisme	Hoger	Iets lager
Gedrag na een herontwerp	Locators moeten mogelijk worden bijgewerkt	De bedoeling wordt opnieuw geïnterpreteerd
Dubbelzinnigheid	Bij het schrijven afgewezen	Tijdens de uitvoering opgelost, soms verkeerd

Geen van beide is in het abstracte beter. Gestructureerde grammatica’s ruilen flexibiliteit in voor voorspelbaarheid, wat de juiste ruil is voor een grote, gereguleerde suite. Vrije beschrijving ruilt wat voorspelbaarheid in voor het feit dat niemand iets hoeft te leren, wat de juiste ruil is wanneer het alternatief is dat je helemaal geen tests hebt.

Hoe je een beschrijving schrijft die werkt

Dit is het deel dat leveranciersdocumentatie meestal overslaat, en waar de meeste praktische moeilijkheid zit. Een suite in gewone taal is niet beter dan haar zinnen.

Benoem de begintoestand. ‘Leg een artikel in het mandje’ veronderstelt een ingelogde gebruiker, een product op voorraad en een leeg mandje. Zeg het erbij. De meest verrassende mislukkingen zijn onuitgesproken voorwaarden.

Beschrijf de uitkomst, niet de mechaniek. Schrijf ‘de bestelling staat in het besteloverzicht’ in plaats van ‘klik op de derde rij van de tabel’. Mechaniek is wat breekt bij een herontwerp; uitkomsten zijn waar het je werkelijk om gaat.

Wees precies waar precisie ertoe doet. Als het totaal € 1.247,50 moet zijn, schrijf het bedrag op. Een beschrijving nodigt uit tot benaderen, tenzij je dat afsluit.

Eén flow per test. Een zin die zes dingen beschrijft faalt als geheel en vertelt je niets over welk van de zes stukging.

Schrijf het zo dat een nieuwe collega het kan volgen. Dat is de betrouwbare toets. Als een bekwaam mens die jouw zin leest een verduidelijkende vraag zou moeten stellen, heeft de AI hetzelfde probleem — alleen zal die niet vragen.

Waar de aanpak spaak loopt

• Werkelijk dubbelzinnige verwachtingen. ‘Controleer of de pagina er goed uitziet’ is in geen enkele methodiek een test.
• Interactie op pixelniveau. Slepen en neerzetten, tekenen op een canvas, kaarten bedienen en games zijn eenvoudiger voor te doen met een opname dan te beschrijven. Tools die om opnames heen zijn gebouwd, zoals Autify, gaan hier beter mee om.
• Uitputtende datagedreven gevallen. Tweehonderd varianten van een prijsregel zijn een lus in code, geen tweehonderd zinnen.
• Harde auditeisen. Waar je precies moet kunnen aantonen wat er is uitgevoerd, is het determinisme van code of van een gestructureerde grammatica meer waard dan het gemak van proza. Zie Testmode versus Virtuoso QA.

Wat het niet wegneemt

Gewone taal neemt het scripten weg. Het neemt het denken niet weg, en teams die dat wel verwachten komen bedrogen uit.

Je moet nog steeds bepalen welke flows ertoe doen, wat correct gedrag eigenlijk is, wat je doet als er iets faalt en hoe vaak je de suite draait. Dat zijn product- en risico-afwegingen. Wat er is veranderd, is dat die afweging maken niet langer vereist dat je haar in TypeScript kunt uitdrukken.

Tools die zo werken

Gestructureerd: testRigor, Testsigma, Virtuoso QA.

Vrij: Testmode, Functionize.

Aanpalend, maar geen gewone taal: Autify en Testim beginnen bij een opname; Rainforest QA stelt stappen op met AI en laat jou ze visueel bewerken.

Het hele veld, geordend naar wat elke tool van je nodig heeft voordat hij kan helpen, staat in het overzicht van AI-testtools.