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.

Wat denk jij, zijn de eerste 4 valkuilen nog relevant vandaag de dag?

Iedereen heeft het recht fouten te maken en er zijn genoeg valkuilen in testautomatisering. Wil jij echter bij je testautomatisering al bekende fouten voorkomen en het wiel niet opnieuw uitvinden? Gebruik dan onderstaande handige tips en voorkom valkuilen in je testautomatisering.

Op basis van zijn ervaring in de afgelopen 10+ jaar met testautomatisering stelde Menno deze valkuilen op. Bij iedere valkuil vermeldt hij een korte toelichting en een mogelijke oplossing. Herken jij een valkuil? Hopelijk kun je dan iets met de genoemde suggestie voor een oplossing.
Natuurlijk zijn er nog veel meer valkuilen mogelijk. Elke project kent zijn eigen veel voorkomende valkuilen en ieder project kan baat hebben bij net iets andere oplossingen. Wil je sparren over jouw project of heb je vragen? Mail dan gerust met menno@newspark.nl.

4 van de 12 valkuilen (deel 1)

De 12 valkuilen zijn opgedeeld in 3 blogs. Hieronder deel 1 en de rest verschijnt binnenkort in deel 2 en 3.

1. Te veel TA

Er is te veel geautomatiseerd en het draaien duurt dus te lang waardoor de testen niet meer gedraaid worden.

Selecteer heel goed wat echt nodig is om te draaien en wat niet. Beperkt het bijvoorbeeld de dekking? 100% dekking bestaat niet, je maakt altijd keuzes. Vraag gebruikers/PO wat de belangrijkste onderdelen van de applicatie zijn.
Kijk goed welke testen hoeveel tijd kosten. Combineer eventueel testen die lang in uitvoer zijn, maar kort in “controle tijd”. Zo verkort je de doorlooptijd. Wel is minder snel duidelijk, als een test faalt, wat er mis gaat, maar dat is altijd beter dan testen helemaal niet draaien.
Maak eventueel als tussenoplossing een opdeling. Bijvoorbeeld een sub-selectie (smoketest) voor in de pipeline bij elke check-in, een grotere selectie voor elke nacht en een complete set voor elke sprint.
Draai testen parallel. Jenkins kan meerdere slaves aanroepen die ieder een eigen deel van de testen uitvoeren. Laat bijvoorbeeld de testen op verschillende browsers door verschillende slaves doen.

2. Flaky testen

Flaky testen zijn testen die met dezelfde software en uitgangssituatie soms slagen en soms falen. In dit artikel lees je wel mooi hoe google omgaat (6 jaar geleden) met flaky testen. Ook google kan het aantal flaky testen niet terugbrengen naar 0%, maar weten de resultaten wel zo goed mogelijk te benutten.

Gebruik nooit sleeps met een vaste waarde om te wachten tot een element bijvoorbeeld zichtbaar is om op te klikken. Dit zorgt namelijk dat je testen standaard veel langer duren dan nodig en het geeft beperkte zekerheid. Hoe lang moet je de sleep wel niet instellen om er echt zeker van te zijn dat het bijvoorbeeld 1.000 keer achter elkaar goed gaat?
Gebruik in de plaats daarvan een sleep met een check. Dus check of de knop er is. Zo ja, klik er op. Zo niet, wacht nog 1 of 5 ms en check het opnieuw. Is de knop na bijvoorbeeld 3 seconden nog niet zichtbaar, dan kun je een foutmelding geven.
Draai je testen op verschillende systemen onder verschillende omstandigheden om flaky testen op te sporen. Zodra je ze kent, kun je gaan zoeken naar verbeteringen.
Zorg in de pipeline dat falende testen een keer opnieuw draaien, en indien nodig, nog eens opnieuw. Mogelijk tot wel 10 keer. Zo weet je of de software functioneel gezien wel goed is.
Moet je accepteren dat een test flaky is, tag deze dan als flaky.
Rapporteer bij voorkeur wel welke flaky testen flaky presteerden en negeer dit niet. Laat dit echter niet leiden tot een falende pipeline, tenzij ze natuurlijk alle 10 keren faalden.
Draai de, nog niet als flaky getagte, testen wel ook automatisch opnieuw in de pipeline, maar rapporteer die wel duidelijk. Zo kun je bepalen of je ze te verbeteren zijn tot niet flaky, dan wel je ze ook als flaky moet taggen.
Probeer je system under test zo stabiel mogelijk te krijgen door stubs en mocking.

3. Onduidelijke logging

Testen falen nou eenmaal weleens. Helaas is dat vaak vanwege een flaky test, een omgevingsissue, een implementatiefoutje in de testen zelf of een nog niet bijgewerkte test. Het is dus belangrijk goed te weten wat er mis gaat en hoe dit op te lossen is.
Vooral als het wel een bug is, moet snel duidelijk worden wat het probleem is. Als het iedere keer een puzzel is om te achterhalen wat er fout gaat is, bestaat de kans dat die puzzel snel aan de kant te schuiven en dan mis je mogelijk bugs.

Rapporteer duidelijk het te verwachte resultaat en wat het werkelijke resultaat is.
Geef testcases een uniek nummer en zorg dat dit ook terugkomt in de logging. Zo zie je snel welke testcase er mis ging.
Probeer of het mogelijk is onderscheid te maken tussen een fail en een investigate. Dit voorkomt ongeloof in de TA. Geeft de TA dagelijks fails, maar nooit een bug, dan letten we al snel niet meer op de falende TA. En als je een investigate rapporteert, bijvoorbeeld door een falende testomgeving, kun je inzichtelijker maken wat de issues zijn. Hopelijk krijg je da ook tijd krijgen om die te verbeteren.
- Verwacht je als uitkomst bijvoorbeeld 318, en je krijgt 321, dan kan dat best een bug zijn.
- Denk je dat de uitkomst bijvoorbeeld 318 is en je krijgt geen antwoord, maar een HTTP 500, is dat vrijwel zeker geen bug. Waarschijnlijk gaat het hier om een omgevingsissue of een fout in je testen. Dit moet je onderzoeken en het is dan in ieder geval met veel minder zekerheid te zeggen dat het een bug is.

4. Resultaatopslag

Elke keer dat een test draait, levert dit testresultaten op. Echter worden die vaak niet opgeslagen. Op die manier kun je niet achterhalen of iets überhaupt goed getest is. Faalt een test dan kun je ook niet achterhalen sinds wanneer deze faalt en waardoor dit mogelijk komt of hoe vaak die test faalt. Zo weet je dus niet of het een flaky test is waarvan je helaas moet accepteren dat die soms faalt of dat het een test is die alleen nu faalt en er dus wel iets aan de hand moet zijn.

Er zijn diverse test management tools die dit goed doen, maar het is maar net de vraag of die goed te combineren zijn met jouw TA framework. Zo niet, sla gewoon vooral alle resultaten op. Dat kan simpelweg op een shared drive. Iets waar alle testers bij kunnen, en de pipeline ook natuurlijk.
Zorg bij voorkeur dat de testen in de pipeline draaien en daar ook de resultaten opgeslagen worden. Dan weet je altijd welke versie getest is en wat de uitslag voor die versie was. Zowel de code als de TA code zijn aan verandering onderhevig, dus het gaat altijd om een momentopname.
Het is ook handig de geschiedenis van de resultaten van de testcases te bewaren. Je weet dan of een test iedere week een keer faalt of dat dit nog nooit eerder voorgekomen is.

Nog een tip van Menno; Probeer vooral diverse oplossingen uit. Naar mijn 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 helpen in het verbeteren van jouw Testautomatisering, veel succes

12 valkuilen in testautomatisering - deel 1/3

4 van de 12 valkuilen (deel 1)

1. Te veel TA

2. Flaky testen

3. Onduidelijke logging

4. Resultaatopslag