Hoe je een applicatie test die je niet zelf hebt geschreven

Een applicatie bouwen vereist niet langer dat je weet hoe hij gebouwd is. Teams leveren software op die door AI-programmeertools is gegenereerd, op low-code-platformen in elkaar is gezet, of door een externe leverancier is geleverd. Het resultaat werkt — tot het stilletjes niet meer werkt.

Het gebruikelijke advies is tests schrijven. Dat advies gaat ervan uit dat je de codebase goed genoeg begrijpt om hem te testen, en dat is precies de aanname die niet meer opgaat.

Begin aan de buitenkant

Wanneer je niet over de binnenkant kunt redeneren, test dan wat gebruikers werkelijk doen. Niet ‘geeft deze functie de juiste waarde terug’ maar ‘kan iemand een product kopen’.

Dat heeft een nuttige eigenschap: het vraagt helemaal niet om de code te lezen. Je moet weten wat de software hoort te doen, en dat weet je vrijwel zeker, want je hebt erom gevraagd.

Schrijf je belangrijkste flows op in gewone taal:

1. Een nieuwe bezoeker kan een account aanmaken en inloggen.
2. Een terugkerende klant kan een artikel in het mandje leggen en de bestelling afronden.
3. Een mislukte betaling toont een duidelijke fout en maakt geen bestelling aan.
4. Een beheerder kan een bestelling vinden en een terugbetaling doen.

Die lijst is meer waard dan een grote suite unittests tegen code die niemand begrijpt.

Rangschik flows naar wat het kost als ze breken

Niet elke flow verdient evenveel aandacht. Sorteer op de kosten van een storing:

• Omzetflows — alles met betalen, abonnementen of afrekenen te maken.
• Toegangsflows — inloggen, wachtwoordherstel, rechten. Breekt hier iets, dan zit iedereen tegelijk buitengesloten.
• Data-integriteitsflows — alles wat records wegschrijft die je niet eenvoudig kunt reconstrueren.
• Al het overige.

Dek de eerste drie fatsoenlijk af voordat je aan de vierde begint.

Test de faalpaden, niet alleen het gelukkige pad

Gegenereerde code gaat doorgaans goed om met het bedoelde geval en slecht met het onbedoelde, omdat de prompt het bedoelde geval beschreef.

Test dus wat er gebeurt als de kaart wordt geweigerd, als een verplicht veld leeg is, als hetzelfde formulier twee keer wordt verstuurd, als een sessie halverwege het afrekenen verloopt. Daar breekt snel geschreven software meestal.

Draai ze voortdurend opnieuw

De reden dat dit voor door AI gegenereerde en low-code-applicaties zwaarder telt is de snelheid van verandering. Wanneer een functie in een middag opnieuw kan worden gegenereerd, is een testsuite die één keer per release draait vrijwel nutteloos. Wat je ook gebruikt, de tests moeten vaak genoeg draaien om een regressie op te merken op de dag dat hij verschijnt.

Waar dit heen leidt

De praktische hindernis is meestal niet weten wat je moet testen — de lijst hierboven is niet moeilijk te schrijven. Het is dat die lijst omzetten in geautomatiseerde tests van oudsher een engineer vereiste, terwijl de hele reden dat de applicatie bestaat is dat er geen engineer beschikbaar was.

Dat gat is wat Testmode wil dichten: de flows hierboven, geschreven in dezelfde gewone taal waarin je ze net beschreef, uitgevoerd door synthetische gebruikers tegen de echte applicatie, zonder dat toegang tot de broncode nodig is.