In mijn nog jonge carrière deed ik ondertussen een aardig aantal testopdrachten. Eén ding kon ik eigenlijk bij geen enkele regressietest loslaten. De vraag of ik niet te veel of juist te weinig automatiseerde? Om jou bij deze vraag te helpen, schreef ik deze blog. Hopelijk geeft het je inzicht in hoe jij je testautomatisering beter kunt aanpakken. Ik merkte dat het in een beginnend project namelijk wel erg makkelijk is om maar gewoon alles te automatiseren. Je hoort ook van de business: 100% automatiseren, we willen niets meer met de hand doen! Echter, om ook op de langere termijn te zorgen dat je testautomatisering nog stabiel en overzichtelijk blijft, kan je het beste een teststrategie opstellen. Aan de hand van die teststrategie beslis je daarna wat wel en wat niet te automatiseren.
Daarnaast is er de vraag, welke testcases neem je op in je regressietestset? Deze vraag begint altijd bij in wat voor soort project je zit. Het is lastig hierop een antwoord te geven die voor alle soorten projecten geldt, terwijl juist ieder project maatwerk is. Daarom probeer ik weer te geven wat de gemene deler is.
Voor verschillende projecten kunnen dezelfde regels gelden, maar ik ga ook, aan de hand van mijn ervaring, in op specifieke gevallen.
Eerst even wat over mijzelf. Ik ben Jurgen en tijdens mijn gedane projecten ontwikkelde ik deze kijk op testautomatisering. Ook ben ik erg benieuwd naar de ervaringen van anderen. Als testautomatiseerder heb ik kennis van selenium, java, robot framework en veel randzaken die daarbij om de hoek komen kijken. Ik richt me voornamelijk op de GUI, maar ook op API’s. Bij verschillende opdrachtgevers, de Universiteit van Utrecht, de Belastingdienst en Energie Data Services Nederland, verrichtte ik diverse werkzaamheden. Er waren projecten waarin ik alles zelf mocht opzetten en projecten waarvoor al een zeer uitgebreide testautomatiseringssuite aanwezig was. Ook maakte ik mee dat de set zelfs weer in omvang moest afnemen.
Zowel bij de start met een geheel nieuw framework als het werken met iets dat al jaren staat, kun je tegen hetzelfde probleem aanlopen. Welke testcases moet ik automatiseren? Om een start te maken wordt er natuurlijk snel gewezen naar de testpiramide. Het grootste deel van de testen moet op unitniveau geschreven. Een kleiner deel op de middleware en nog maar een heel klein deel op de GUI. Dit betekent dat paden die logica behandelen vrijwel uitsluitend middels unittesten worden getest. Uiteindelijk is er nog maar een klein aantal testen die op de GUI moeten gebeuren. Een probleem van de testpiramide is echter dat die ene vraag nog niet is beantwoord. Welke testen gebruik je dan voor je regressieset? Het antwoord op die vraag; welke testen neem je wel op in je regressieset en welke specifiek niet, hoor of lees je niet vaak. Hieronder daarom een aantal tips waarvan ik denk dat ze voor veel verschillende soorten projecten toepasbaar zijn:
1: Automatiseer niet alles.
In mijn opdrachten heb ik ondertussen geleerd, dat je niet altijd alle onderdelen van de GUI wilt automatiseren. Het kost te veel tijd om grote aantallen nieuwe testcases toe te voegen en dan ook nog te onderhouden. Dit vraagt simpelweg dusdanig veel tijd, dat je regressieset niet meer te combineren is met een snelle voortbrenging van een nieuwe release. Probeer altijd focus te houden op risk-based testing. Ga na wat de grootste productieproblemen zou veroorzaken en neem dat op in je regressieset. Kijk daarnaast naar testcases van onderhanden software. Hier zit vaak het grootste risico dat het fout gaat. Dit betekent ook dat je na verloop van tijd weer testcases uit je regressieset haalt.
2: Haal oude testcases uit je regressieset.
Er is een verschil tussen dat wat in je regressieset staat en dat wat je geautomatiseerd hebt. Niet alles wat je automatiseert, moet ook direct in een geautomatiseerde regressieset opgenomen worden. Als je een tijd bezig bent met nieuwe software en een deel van je applicatie is stabiel en “af” dan kun je kiezen dit weer uit je regressieset te halen. Daarbij hoef je die regressietesten niet weg te gooien, je kunt ze ook archiveren. Op deze manier zijn ze later nog bruikbaar. Bijvoorbeeld als naslagwerk of als de applicatie op die locatie nog eens wordt aangeraakt.
3:Gebruik tags om alleen dat te testen wat is aangeraakt.
Je kunt kiezen om te werken met tags die alleen specifieke testcases aftrappen na aanpassing van bepaalde stukken van de software. Zo verlaag je drastisch de doorlooptijd van je regressieset en draai je alleen relevante zaken. De totale regressieset wordt er wellicht niet korter van, maar je gaat wel efficiënter met je tijd om.
4: Maak een product risico analyse (PRA).
Een PRA kan helpen bij het bepalen waar de focus moet liggen. Levert een bug in productie geen major issue op, dan hoef je hiervoor niet direct een GUI testcase in je regressieset op te nemen. Zijn die testen er al, gebruik ze dan niet in je regressieset, maar sporadisch als je team met de functionaliteit bezig is. Natuurlijk is het belangrijk hierbij na te gaan hoe snel je een bug in productie kan oplossen. Voor veel bedrijven is iedere dag software naar productie een utopie. Vraag jezelf dus af wanneer iets een major issue is. Ontstaat dit als een cruciaal proces niet meer werkt, of wellicht al veel eerder.
5: Bedenk goed wat de kosten van testautomatisering zijn.
Bedenk van tevoren goed of een aanpassing aan je testautomatiseringsframework misschien wel tot meer kosten leidt, dan wat een eventuele bug op productie ooit gaat kosten. Neem bij het kijken naar de kosten en baten dus niet alleen mee hoeveel tijd een testcase maken vergt, maar ook de tijd om die te onderhouden. Hoe stabiel kan je een test maken? Aan de andere kant moet je ook rekening houden met wat een bug je kost. Loop je bijvoorbeeld de kans, naast de kosten van het fixen van het issue, ook imagoschade te krijgen?
6: Vergeet het handmatige testen niet!
Misschien niet echt een tip over welke testen te automatiseren, maar wel een belangrijk inzicht dat ik in de loop der jaren opdeed. Als je alles wilt automatiseren, gaat al je aandacht daar naartoe. Eigenlijk kan je bij geautomatiseerd testen niet zeggen dat je aan het testen bent. Het zijn meer geautomatiseerde checks. Bij testen draait het ook om de onvoorziene situaties en die kom je niet tegen als je alles automatiseert.
Een grote valkuil van testautomatisering is alle testen die mogelijk zijn, automatiseren. En dan zijn er ook nog partijen die dat het liefst allemaal in de GUI zien gebeuren. Dit wordt dusdanig groot dat het niet meer beheersbaar is. Stopt de goeroe binnen je team, dan heb je een probleem. Onderhoud is niet meer mogelijk en op een gegeven moment gaan steeds meer testen falen. De knowhow om te achterhalen of dit issues in het testen of daadwerkelijke bugs is dan niet meer aanwezig. Probeer dus continu te beoordelen of oude testen nog in je regressieset moeten meedraaien. Zit je in een project waar je vaak naar productie gaat met nieuwe software, is een bug in productie doorgaans ook snel te fixen. Dit is een belangrijke factor in hoeveel testcases je in je regressieset meeneemt. Gaat je project minder vaak naar productie ben je wellicht geneigd meer testen te automatiseren. Een langer lopende regressieset lijkt dan minder pijnlijk. Bedenk ook in die situatie dat, ondanks het feit dat je niet vaak naar productie gaat, een snelle set veel vaker feedback kan geven of de belangrijkste functionaliteit nog werkt. Onverwachte situaties vang je dan met manueel testen op.
Jurgen Alebregtse
