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

Deze valkuilen zijn opgedaan op basis van Menno zijn ervaringen in de afgelopen 10+ jaar. Bij elke valkuil een korte toelichting en een mogelijke oplossing. Herken jij een valkuil? Hopelijk kun je iets met de suggestie voor een oplossing.
Uiteraard bestaan er nog veel meer valkuilen. Bij elk project zijn eigen veel voorkomende 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.

9. Testen draaien amper

Testautomatisering die niet regelmatig draait, is waardeloos. Langzaamaan vallen er altijd testen om. Bijvoorbeeld doordat de code is aangepast en de testen niet aangepast zijn. Zodra je de testen lange tijd niet draait, en dan wel een keer, zul je merken dat een boel testen falen. Het gevolg is dan vaak dat men deze fails negeert of de testen worden zelfs uitgeschakeld c.q. verwijderd. Met als gevolg dat mogelijke bugs negeert worden en het de testdekking verlaagt.
Wordt wel onderzocht wat mis is, dan is de oorzaak doorgaans niet meer te vinden, omdat je niet weet sinds wanneer de testen falen. Dus daaruit valt 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 work-around is dan maar het “uitschakelen” van testen. Oftewel, ze worden niet meer gedraaid. Vaak zonder dat dit duidelijk is. 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 in 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 getagt, 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, ben je al snel geneigd die alle 20 te gaan testen. Ook al zijn maar 2 van die elementen je testdoel.
Indien dan 1 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.
Daarbij komt dat als je bijvoorbeeld 100 testen hebt die allemaal die 20 elementen testen, en de code veranderd waardoor 1 van die 20 elementen wijzigt, 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 bewust dat bijvoorbeeld voor al die 20 elementen een test nodig is.
• En als je besluit dat bijvoorbeeld testcase 100 de resterende 8 elementen test, omdat die anders niet getest worden, neem dit dan duidelijk op in het testdoel.

12. TA!>Software

In 1 van mijn opdrachten was de stelling: “het test framework moet 3 keer zo goed zijn als de software die we testen”.
Dit klinkt misschien vreemd, want waarom zorg je niet dat de software zelf 3 keer zo goed is? Echter, de software is veel complexer en veel grootser. Om die 3 keer zo goed te krijgen, zonder testen die aantonen hoe goed het is, kost enorm veel tijd.
En 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. Terwijl je het liefste ziet 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 bij “Instabiele Testomgeving” (deel 2/3). Falen je testen dan ook nog eens door een falend test framework, krijg je nog meer false negatives, of nog erger, false positives.

• Dus zorg 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.
  • Dus check 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.