12 valkuilen in testautomatisering

Bijna op de kop af 4 jaar geleden schreef Menno een 3-luik aan blogs over de valkuilen van Testautomatisering. Deze kwamen we tegen en we vonden ze te goed om niet mee te nemen naar de nieuwe website.

Vorige week kwamen de eerste 4 valkuilen aan bod, vandaag 5-8. Dezelfde vraag blijft staan: zijn deze nog relevant vandaag de dag?

Iedereen komt valkuilen in testautomatisering tegen en heeft het recht op zijn eigen fouten maken. Ook als anderen die fouten al eens hebben gemaakt. Maar waarom niet leren van andermans fouten en zelf opnieuw het wiel uitvinden? Gebruik onderstaande tips die je kunnen helpen bij je testautomatisering.

Deze valkuilen zijn op basis van Menno zijn ervaringen als testautomatiseerder in de afgelopen 10+ jaar. Naar zijn idee is er altijd een oplossing mogelijk. En als je echt wilt, vind je de juiste oplossing voor jouw project. Wil je sparren over valkuilen in jouw project of heb je vragen? Mail dan gerust: menno@newspark.nl.

De 12 valkuilen zijn opgedeeld in 3 blogs. Lees ook de rest in deel 1/3 en binnenkort verschijnt deel 3/3. Iedere valkuil is voorzien van een korte toelichting en een mogelijke oplossing. Herken jij een valkuil? Hopelijk heb je dan iets aan de suggestie voor een oplossing. Natuurlijk zijn er nog veel meer valkuilen. Ieder project kent eigen veel voorkomende valkuilen en ook elk project kan baat hebben bij net iets andere oplossingen. Probeer vooral diverse oplossingen uit.

5. Preconditie check (systeem is niet schoon)

Vaak verwacht een test dat de SUT (System Under Test) in een bepaalde conditie is. Bepaalde gegevens zitten bijvoorbeeld in de DB of juist niet. Of een test verwacht dat een SUT “schoon” is. Echter, heel veel voorgaande testen laten sporen achter. Dit hoeft niet altijd slecht te zijn, maar soms is het dat wel. Ga er dus niet standaard vanuit dat de SUT “schoon” is, want dan kan je bedrogen uitkomen en faalt je test om lastig verklaarbare redenen.

Ruim niet achteraf op, maar vooraf.
- Vroeger maakte men na afloop van een test vaak het systeem “schoon” middels een wrapup. Echter, is de wrapup van bijvoorbeeld test nummer 5 niet goed gegaan, dan kan test 6 falen (een dag later bijvoorbeeld). Mogelijk heb je dan geen idee waarom. Dus bespaar de tijd van het achteraf schoonmaken van de SUT. Verwacht een test een “schone” SUT, dan moet die daarvoor zorgen. En wat is schoon? Alleen wat die test verwacht dat schoon is, hoeft hij maar schoon te maken.
Doe vooraf een check vooraf om te zien of de SUT is zoals je die verwacht. Bij voorkeur incl. de stappen om de SUT naar de gewenste situatie te krijgen. Dit is feitelijk je “Given” stap.
Faalt die check faalt of lukt de preparatie naar “schoon” niet, dan heb je dus geen bug te pakken, maar een investigate. Je kunt immer je testen niet uitvoeren. Rapporteer dat dan ook als investigate en niet als bug / falende test.

6. Instabiele testomgeving

Vaak ben je niet de enige die gebruikmaakt van de testomgeving. Mogelijk heb je wel je eigen SUT, maar zit die verbonden met andere systemen die anderen ook gebruiken. Hierdoor kan je SUT een verkeerd antwoord terugkrijgen met als gevolg dat de testen falen.

Doe bij voorkeur altijd een preconditie check. Niet alleen op je eigen SUT, ook op de aanpalende systemen waarvan je afhankelijk bent, als het maar even kan. Faalt die preconditie check, dan heb je een investigate en niet een falende test en al helemaal geen bug.
Shift left. Test zoveel mogelijk in unittesten, anders in componenttesten of in systeemtesten met gestubte externe systemen.

7. Kennis en enthousiasme vloeien weg, -> testautomatisering weg

Een testconsultant (of developer) introduceert vaak een test framework door en onderhoudt dit test framework met de nodige passie en enthousiasme. Na verloop van tijd gaat de desbetreffende test consultant naar een volgende opdracht. Met hem verdwijnt dan een boel kennis en ook de passie voor de testautomatisering. Regelmatig heeft een nieuwe consultant een nieuwe kijk op het test framework en is de oude testautomatisering niet goed overgedragen. Gevolg; hij kan het niet goed onderhouden en dus zet hij iets nieuws op. Deels weggegooid geld van de vorige consultant Hoe zorg je nu dat jouw inzet over 2-3 jaar niet ok deels weggegooid geld is?

Als consultant is het jouw plicht je werk zo goed mogelijk over te dragen, doe dat dus ook. Documenteer secuur, maar leg vooral ook goed uit. De documentatie moet slechts als naslagwerk dienen voor de details en de visie moet duidelijk zijn. Probeer ook je passie over te dragen, hoe moeilijk ook.
Ga niet pas rond je vertrek overdragen, maar probeer tijdens je werkzaamheden al meer collega’s eigenaar te maken van de testautomatisering. Hoe meer collega’s hierover enthousiast zijn en er goed mee kunnen werken, hoe minder verlies van kennis wanneer jij weggaat.
De techniek gaat snel. Net als een versie van een programmeertaal, moet je soms ook een versie van een test framework upgraden. Of upgraden van bijvoorbeeld Fitnesse naar Cucumber. Zorg dat testen goed zijn opgesteld met bijvoorbeeld een helder testdoel. Zo zijn testen goed te migreren van het ene naar het andere test framework zonder dat kennis en werk verloren gaan.
Houd het simpel en overzichtelijk. Met een test zijn wel 100 dingen te controleren, maar is het testdoel 5 dingen controleren, doe dat dan ook. Begrijp je opvolger niett wat je hebt gedaan en waarom, dan zal hij eerder je werk weg doen.

8. Geen testdoel

Regelmatig zijn falende testen het gevolg van een onduidelijk testdoel. Hierdoor is het lastig te bepalen of er een bug is of dat de testcase aangepast moet worden. Waarom verwachten we dat er 5 uitkomt en is het dus fout nu er 7 uitkomt? Hierdoor komt het nog wel eens voor dat een test verwijderd / niet meer gedraaid wordt, terwijl juist dan er sprake is van een bug. En is het geen bug, maar die test wordt wel geskipt, gaat in ieder geval de testdekking achteruit.

Stel simpelweg altijd een testdoel op voor het verder uitschrijven van een testcase en zeker bij het automatiseren daarvan. Wat gaan we aantonen met deze test? Wat is het nut van deze test? Soms checkt een test wel 10 dingen, maar zijn 9 daarvan overlappend met 8 andere testen. Feitelijk is het testdoel van die test dan enkel het checken van dat 10e ding, meer niet.
Ook als je moet besluiten een testset te verkleinen of efficiënter te maken, is een testdoel essentieel. Zijn bovenstaande 9 testen bijvoorbeeld samen te voegen tot 1, 2 of 3 testen? Dit is pas echt te bepalen wanneer duidelijk is wat het doel is van die testen.

We zijn ben benieuwd welke van bovenstaande tips jou helpen in het verbeteren van jouw Testautomatisering, laat het gerust weten of contact menno@newspark.nl voor overleg. Heel veel succes met je testautomatisering.

12 valkuilen in testautomatisering - deel 2/3

5. Preconditie check (systeem is niet schoon)

6. Instabiele testomgeving

7. Kennis en enthousiasme vloeien weg, -> testautomatisering weg

8. Geen testdoel