Auteur: Kees Blokland ● kees.blokland@polteq.com
Wanneer is een test geslaagd? Die vraag zaait weleens verwarring in gesprekken, bij presentaties of bij trainingen. Mensen die de automatiseringsgolf van de twintigste eeuw hebben meegemaakt, vertellen over testgevallen die, wanneer ze werden uitgevoerd en het verwachte resultaat toonden, als geslaagd werden beschouwd. Met een groenkleurig vinkje erbij. Als alles groen is, krijgt het product de testmedaille uitgereikt: hij kan! Anderen betogen juist dat een test waarmee een bug is gevonden, geslaagd is. Een roodkleurig kruisje staat dan model voor ‘geslaagd’. De testmedaille kent kennelijk nog een keerzijde. Maar wanneer is een test nu geslaagd?
ISTQB
Of iets geslaagd is, hangt af van het doel ervan en of dat is gehaald. Wat is over het algemeen het doel van testen? Ik herinner me een ISTQB-foundation slide met de volgende testdoelstellingen:
- ‘Vertrouwen krijgen in het product’
- ‘Fouten vinden in het product’
Een uitgevoerde test die laat zien dat het product werkt zoals de tester verwacht, draagt bij aan doelstelling één. Een uitgevoerde test die een bevinding oplevert, draagt bij aan doelstelling twee. Op basis van de ‘ISTQB-doelen’ kunnen we dus concluderen dat in beide gevallen de tests geslaagd zijn.
TMap
‘Het vaststellen van de kwaliteit van het product en onderzoeken of er nog risico’s zijn die het in gebruik nemen in de weg staan.’ Op die manier steekt TMap in, zo heb ik destijds geleerd. Goed beschouwd komt dat best goed in de buurt van de ISTQB testdoelen. Nog steeds is een test die faalt en de test die niet faalt in feite succesvol!
Bevinding en testgeval
Ik herinner me managers die bevindingen consequent gekoppeld willen zien met testgevallen. Alsof een bevinding hetzelfde is als een ‘gefaald’ testgeval. Maar fouten zitten niet precies op plaatsen waar testgevallen over gaan. Juist met het losgekoppeld houden van testgevallen en bevindingen houd je de focus op verschillende testdoelen. Wel kan het een goed idee zijn om een regressietestgeval toe te voegen die checkt dat de opgeloste bevinding later niet terugkomt.
Checken en testen
Tests die op basis van specificaties zijn gemaakt, laten zien dat het product bepaalde dingen kan. We noemen die ook wel ‘checks’. Na uitvoering is de status rood (niet oké) of groen (oké). Geautomatiseerde regressietestsets bestaan uit dit soort checks. Als alles ‘groen’ is, dan is de verleiding groot om te concluderen: het product is goed! Helaas. De blog ‘Testing is’ van Michael Bolton geeft een lange waslijst aan antwoorden op de vraag ‘what is testing?’. De verschillende testdoelstellingen in die lijst zijn evenzoveel aanleidingen om te twijfelen aan de geschiktheid van het product om in gebruik te nemen. De verschillende manieren van testen helpen om de bijbehorende risico’s een voor een te tackelen. Het zicht op mogelijke problemen die het in gebruik nemen van het product in de weg staan wordt steeds beter naar mate er meer getest is.
Eind aan de verwarring
Wat mij betreft komt hiermee een eind aan de verwarring: iedere test die zinvolle informatie oplevert over het product kun je als geslaagd beschouwen!
En de testmedaille kan de prullenbak in: aan twee zijden heb ik niet genoeg….
“Wel kan het een goed idee zijn om een regressietestgeval toe te voegen die checkt dat de opgeloste bevinding later niet terugkomt.”
Wat mij betreft juist een ontzettend slecht idee!
Een regressietestsuite zou niet meer moeten doen dan de bedrijfskritische onderdelen valideren. Als je er meer in gaat stoppen, wordt de test duurder (want iemand moet dat toch echt doen en het zal onderhouden moeten worden) en voor je het weet zit er een FTE in het onderhouden van een suite die vrijwel nooit iets oplevert…en als wat eruit komt dan ook nog eens niet bedrijfskritisch is, ben je volgens mij niet goed bezig.
Ik heb regressietestsuites meegemaakt waaraan jaren ‘validaties van bugfixes’ waren toegevoegd. Vaak was de bugfix van dien aard, dat het originele issue technisch onmogelijk meer op kon treden…en jaar na jaar, nacht na nacht wordt dus gecontroleerd of iets dat technisch onmogelijk is inderdaad niet is opgetreden…
Dit kwam dan meestal aan het licht na verplaatsen of verwijderen van (niet bedrijfskritische) functionaliteit…na zo’n actie faalden de regressietesten dan en was je dagen aan het controleren of er geen gefaalde testen tussen zaten die daadwerkelijk een probleem waren.
Een bugfix die de oorzaak van de bug niet aanpakt is wat mij betreft een slechte fix, het is een pleister. Even terug naar de basis: no risk, no test. Een pleister i.p.v. een echte bugfix elimineert het risico niet. Het risico blijft, de test blijft, de kosten blijven. Het risico elimineren, elimineert ook de noodzaak tot testen en dan is opnemen in de regressietest sowieso niet aan de orde.
Hallo Robin,
Je betoog is helder.
Over het opbouwen en onderhouden van regressietestsets zijn vele blogs te schrijven!
Bij TDD maakt de ontwikkelaar eerst een test die de bug reproduceert en gaat dan de bug oplossen. Die test is dan onderdeel geworden van de unittestset die in de CI pipeline meedraait.
Unittests zijn goedkoop en snel, maar tests op businessprocesniveau zijn veel duurder dus moet je inderdaad goed bedenken waar je die voor gebruikt.
Dank voor je bijdrage en fijn weekend
Kees