Testautomatisering – van doel naar middel

Testautomatisering is ‘hot and happening’ op dit moment. Steeds meer bedrijven investeren in testautomatisering en in vrijwel alle testvacatures wordt tegenwoordig om kennis van testautomatisering gevraagd. En uiteraard is meerdere jaren ervaring met testautomatisering hierbij een must.

Het meest gebruikte argument om met testautomatisering te beginnen, is toch tijdsbesparing. En uiteindelijk dus ook geldbesparing. Dit is gelijk ook het grootste misverstand van testautomatisering. Wanneer er bij het testen een focus komt op het automatiseren van de testen, is er juist blijvend een extra investering nodig om dit op een goede manier te kunnen verwezenlijken. Het opstellen van de testen kost tijd, het onderhouden van de testen kost tijd, en niet alles kan geautomatiseerd getest worden. Dus handmatig testen zal altijd nog nodig zijn voor sommige onderdelen van de applicatie.

Dit betekent niet dat investeren in testautomatisering verspilde tijd is. Juist verre van! Computers (en dus ook testscripts) zijn uitermate goed in het precies vinden van de precieze requirements. Daar waar mensen na 10 keer het woord “menu” gezien te hebben gaan missen dat er een keer “manu” staat, kan het testscript deze nuance er altijd nog uit halen. En niet alleen met teksten is een testscript over het algemeen preciezer dan het menselijk oog. Ook als het gaat om kleuren, afmetingen en verhoudingen kan een computer dit sneller en preciezer dan de mens. Mits de juiste requirements zijn opgegeven uiteraard.

En in dat laatste zit nu juist de grootste tijdsinvestering; het testscript de juiste requirements geven. Welk framework er ook gebruikt wordt om de testen te automatiseren, er moet in de eerste plaats een basis neergezet worden. Daarna kan er pas in de code de precieze requirements ingezet worden. Hierbij is het niet voldoende om aan te geven dat de knop de kleur rood moet hebben. Want moet het FF­0000 of FF-0033 zijn? Voor ons mensen is het beide rood, maar het testscript haalt deze nuances eruit. Dus moeten wij als testers (c.q. programmeurs) de testscripts vertellen welke kleur rood het precies hoort te zijn.

Daar komt nog eens bij het onderhoud. Iedere wijziging kan potentieel invloed hebben op de testscripts. Afhankelijk van de wijziging kan het zijn dat het hele testscript faalt. En dan is het debuggen geslagen. Ook dit kan veel tijd in beslag nemen.

Zoals hierboven al even aangestipt is een testscript over het algemeen preciezer dan het menselijk oog. En als iets preciezer is, dan is het ook beter toch?

Niet per definitie. Als het bovenste licht van een stoplicht groen is in plaats van rood, is het echt precies de goede kleur groen. Of het juist is dat groen bovenaan zit, is een ander verhaal. Dit is ook het geval met testautomatisering. De kwaliteit van de testscripts is voor het overgrote deel afhankelijk van de kwaliteit van de opgevoerde testgevallen. En hier zit nu juist het gevaar van testautomatisering. Een testautomatiseringsscript met maar 2 testgevallen kan kwalitatief beter zijn dan eentje met 100 testgevallen, mits die 2 testgevallen ook echt zinvolle testen zijn.

Daar komt nog eens bij dat er wel geluisterd moet worden naar de uitkomsten van de testen. Onder tijdsdruk gebeurd het nog wel eens dat er niet gekeken wordt naar falende testen. Of doordat de testen al maanden c.q. jaren niet meer geüpdatet zijn, niet meer relevant zijn en dus overgeslagen worden. Ja, testen automatiseren kan zeker een meerwaarde leveren, maar dan moet er wel naar geluisterd worden en moeten de testen wel continu geüpdatet worden. Anders kan er naar de kwaliteit ook wel gefloten worden en heeft het geen enkele zin om tijd en energie te steken in testautomatisering.

Doordat testautomatisering goedkoper is (niet echt dus) en kwalitatief beter (nou, bijna dan), worden managers al snel enthousiast van het woord. Daar komt nog eens bij dat tegenwoordig iedereen begint over testautomatisering en een nieuwe hype is geboren! Regelmatig krijgen testers vragen van hun managers in de trant van “Hoeveel testen zijn en nu geautomatiseerd?” en “Wat is het dekkingspercentage van onze automatische testen?”. Een punt wat hierbij overgeslagen wordt is dat testautomatisering eigenlijk een middel is, en geen doel op zich. Alles kan op zich geautomatiseerd getest worden, maar wel moeten er keuzes gemaakt worden wat er automatisch getest moet worden. Of nog beter, wat er überhaupt getest moet worden.

100% alles altijd testen is onmogelijk. Daarvoor zijn er te veel (verborgen) edge cases. En vaak is de tijd om te testen ook niet onbeperkt. Daarom zullen er altijd keuzes gemaakt moeten worden wat er getest moet worden. Dit is ook een van de grootste taken van een tester: inzichtelijk maken van niet alleen alle mogelijke testen, maar ook welke prioriteit heeft. Op het moment dat er testcases bekend zijn, kan de tester nagaan welke manier van test het beste aansluit bij de testcases. Dat in veel van de standaard testcases het antwoord geautomatiseerd het antwoord is, is alleen maar prettig. Maar dit betekent dus niet dat altijd alles maar geautomatiseerd getest moet gaan worden.

Met name testen die maar eenmalig uitgevoerd moeten worden, is zonde om geautomatiseerd te laten testen. Het opstellen van de testscripts kost in veel gevallen aanzienlijk meer tijd dan zelf handmatig eenmaal de test uit te voeren.

Het lijkt een soort mantra die continu herhaald moet worden. Testautomatisering is een middel, testautomatisering is een middel, testautomatisering is een middel… Testen automatiseren is in veel gevallen handig, wenselijk, kwalitatief beter, maar het is en blijft een middel en geen doel. Goedkoper hoeft het niet per definitie te zijn, kwalitatief beter is ook niet gegarandeerd en niet alles moet je willen automatiseren.

Laten we dus testautomatisering maar blijven zien als een middel, en het doel goed testen laten.

Rianne Boortman
Medior tester