12 valkuilen in testautomatisering

Bijna op de kop af vier jaar geleden schreef Menno een drieluik over de valkuilen van Testautomatisering. Deze kwamen we tegen en we vonden ze te goed om niet mee te nemen naar de nieuwe website.

Hier alweer deel 3 met de laatste vier valkuilen. Vandaag de dag nog relevant of niet?

Iedereen mag fouten maken, maar waarom niet leren van andermans valkuilen in testautomatisering en het wiel opnieuw uitvinden? Hieronder deel 3 met tips die je kunnen helpen valkuilen bij je testautomatisering te voorkomen.

Deze valkuilen zijn opgedaan op basis van ervaringen van Menno in de afgelopen 10+ jaar. Bij elke valkuil is een korte toelichting en een mogelijke oplossing toegevoegd. Herken jij een valkuil? Hopelijk kun je iets met de suggestie voor een oplossing.

Uiteraard bestaan er nog veel meer valkuilen. Elk project heeft zijn eigen valkuilen en elk project kan weer baat hebben bij net iets andere oplossingen. Probeer vooral diverse oplossingen uit. Wil je sparren over jouw project of heb je vragen? Mail dan gerust: menno@newspark.nl.

De 12 valkuilen zijn opgedeeld in 3 blogs. Lees hier deel 1/3 en deel 2/3 uit de serie.

12 valkuilen in testautomatisering - deel 3/3

9. Testen draaien amper

Testautomatisering die niet regelmatig draait is waardeloos. Langzaamaan vallen er altijd testen om, bijvoorbeeld doordat de code is aangepast maar de testen onveranderd zijn gebleven. Zodra je de testen een lange tijd niet draait en dan weer wel een keer, dan zal je merken dat een boel testen falen. Het gevolg is vaak dat men deze fails negeert of zelfs de testen worden uitgeschakeld c.q. verwijderd. Dit heeft als gevolg dat mogelijke bugs genegeerd worden en de testdekking verlaagd is. Wordt wel onderzocht wat er mis is, dan is de oorzaak doorgaans niet meer te vinden omdat je niet weet sinds wanneer de testen falen. Daaruit valt dus ook niets op te maken.

Zorg dat testen in ieder geval minimaal elke sprint / elke week draaien. Desnoods als windows job o.i.d.
Draai bij voorkeur de TA vanuit de pipeline. Dan draait het zeker vaak en weet je ook duidelijk wat getest is.

10. Niet opgelost, maar uitgeschakeld

Het komt nog wel eens voor dat een test faalt, maar er dan niet voor gezorgd wordt dat die test weer slaagt. Het gevolg: de volgende run faalt hij waarschijnlijk weer. Misschien negeer je een bug, accepteer je sneller dat een test faalt en mogelijk zie je andere falende testen over het hoofd. Een veel gebruikte workaround is dan maar het “uitschakelen” van testen. Oftewel, ze worden niet meer gedraaid. Vaak zonder dat dit duidelijk is gecommuniceerd. Zo mis je een stuk testdekking en mogelijk negeer je een gevonden bug.

Los falende testen altijd snel op. Alleen zo houd je duidelijk inzicht en het geloof in de testautomatisering hoog. Daarnaast zorg je ervoor dat het werk zich niet ophoopt. Ophopende falende testen maken de kans groter dat ze genegeerd worden.
Faalt een test omwille van een bug, tag hem dan met die bug en maak dat duidelijk in de rapportage. Hierdoor zie je in één oogopslag dat een falende test komt door een reeds bekende bug. Is er geen bug aan getagd, dan moet je die dus snel onderzoeken. Dit taggen kan al simpelweg door de testnaam te laten beginnen met bijvoorbeeld “jira-234” (verwijzend naar de bug in Jira).

11. Testcases checken te veel

Als het goed is, heb je met een testcase een testdoel (deel 2/3), maar vaak test je tegelijk een boel meer. Krijg je een bericht terug met 20 elementen erin, dan ben je al snel geneigd die alle 20 te gaan testen. Ook al zijn maar twee van die elementen je testdoel.
Indien dan een van die andere 18 elementen niet correct is, faalt je test, maar daarmee heb je niet je testdoel bereikt. Je kunt dus niet snel achterhalen wat er mis is. Als je bijvoorbeeld 100 testen hebt die allemaal die 20 elementen testen en de code verandert, waardoor 1 van die 20 elementen wijzigt, dan krijg je de situatie waarbij alle 100 testen falen. Je moet dan 100 testen aanpassen, maar misschien is dit bij 99 van de 100 wel ten onrechte.

Zorg dat je testcase vooral test wat het doel van de test is, en liefst niet meer.
Wees je daarbij wel altijd van bewust dat bijvoorbeeld voor al die 20 elementen een test nodig is.
Als je besluit dat bijvoorbeeld testcase 100 de resterende acht elementen test, omdat die anders niet getest worden, neem dit dan duidelijk op in het testdoel.

12. TA kwaliteit < Software kwaliteit

In een van mijn opdrachten was de stelling: “het test framework moet drie keer zo goed zijn als de software die we testen”.
Dit klinkt misschien vreemd, want waarom zorg je niet dat de software zelf drie keer zo goed is? Echter, de software is veel complexer en veel groter. Om die drie keer zo goed te krijgen, zonder testen die aantonen hoe goed het is, kost enorm veel tijd.
Nog veel belangrijker:
Stel, je test framework is net zo goed als je software. In de helft van de gevallen heeft de TA dan een falende test door de software en in de andere helft van de gevallen door het test framework. Het liefst zie je natuurlijk dat je TA een falende test heeft door een bug.
Daarbij zijn er doorgaans nog veel meer factoren waardoor testen falen, zonder dat er sprake is van een bug. Kijk bijvoorbeeld naar “Flaky testen” (deel 1/3) en “Instabiele Testomgeving” (deel 2/3). Falen je testen dan ook nog eens door een falend test framework, dan krijg je nog meer false negatives, of nog erger, false positives.

Zorg dus altijd dat je TA framework zo goed mogelijk is, liefst duidelijk beter dan de software die je test.
Dit doe je o.a. door voor je framework op zijn minst dezelfde kwaliteitchecks te hanteren als voor de software.
- Check dus ook alles in in Git.
- Werk alles bij middels pull requests die gereviewd worden door een andere testautomatiseerder of een programmeur.
Bouw unittesten in die checken of je framework inderdaad nog steeds dezelfde resultaten geeft in specifieke foutsituaties.

Naar Menno’s idee is er altijd een oplossing mogelijk en als je maar wilt, dan vind je de juiste voor jouw project. We zijn benieuwd welke van deze tips jou gaan helpen in het verbeteren van jouw Testautomatisering. Veel succes ermee.

12 valkuilen in testautomatisering - deel 3/3

9. Testen draaien amper

10. Niet opgelost, maar uitgeschakeld

11. Testcases checken te veel

12. TA kwaliteit < Software kwaliteit