Home Algemeen Regressietesten, beetje saai maar onontbeerlijk

Regressietesten, beetje saai maar onontbeerlijk

1014

Wil je tevreden klanten, software met een minimum aan bugs en goede gebruikerservaringen, zorg dan dat het regressietesten hoog op de agenda staat. In de praktijk blijkt dat nogal eens lastig door tijdsbeperkingen, dat eeuwige onderhoud en de afhankelijkheid van mensen met de juiste kennis. Het vertragen van de release cyclus ligt dus op de loer door deze mogelijke knelpunten of er wordt bewust gekozen om de prioriteit te verlagen met alle risico’s van dien.

Wat is regressietesten?

Regressietests zijn simpel gezegd reeksen testen die controleren of de toepassing werkt zoals bedoeld. Elke keer dat er nieuwe code wordt toegevoegd aan de applicatie of als er wijzigingen worden doorgevoerd zal er weer een regressietest moeten plaatsvinden. Het kan zijn dat zelfs een kleine wijziging aan de code een ongekend effect heeft op de werking van de applicatie.

Het betreft dus het testen van het ongewijzigde deel van de software na aanpassing van de applicatie. Als de oude functionaliteiten nog steeds goed werken dan heeft er geen regressie plaatsgevonden. Een regressietest is een soort verzekering. Je hebt het mogelijk niet nodig, maar je wilt zeker weten dat je geen risico loopt.

De meeste testers vinden handmatige regressietests bijzonder vervelend en saai. Je zoekt naar die bekende naald in de hooiberg die er mogelijk helemaal niet is. En dit telkens na elke wijziging in de code. Daarbij wordt het aantal uit te voeren testen met de evolutie van de applicatie ook nog eens alleen maar groter.

Waarom regressietesten automatiseren?

Door Agile en DevOps is er de noodzaak om ook snel kwaliteit te leveren. Automatisering ervan krijgt dus meer en meer aandacht, haalt het routinematige en saaie uit het werk en betekent dat je in dezelfde tijd significant méér kunt testen.

Geluk bij een ongeluk; regressietesten is vanwege zijn repetitieve en voorspelbare karakter een ideale kandidaat voor automatisering. Overigens sluit dit het handmatig uitvoeren van regressietesten niet uit. In het algemeen is er wel een balans tussen de twee vormen. Het gaat tenslotte om de efficiëntie en tijdsoptimalisatie van het totale testproces.

Testers zullen hierbij altijd nog belangrijke taken als monitoring, evalueren en het up-to-date houden van de opgezette testen in het takenpakket houden. Ook blijft het signaleren van potentiële valkuilen natuurlijk mensenwerk.

Wat gaat dat opleveren?

Resources, schaalbaarheid en onderhoud
Dure mankracht kan nu worden ingezet voor testen en bugfixing die niet zo makkelijk geautomatiseerd kunnen worden en voor ongebruikelijke gevallen die speciale aandacht vereisen. Dit verbetert de kwaliteit van de software en dat ervaren klanten graag.

Door het testen te automatiseren kunnen de testen met een snelheid en frequentie worden uitgevoerd die handmatig niet te realiseren is. Dit betekent dat er meer code getest kan worden en dus de kwaliteit omhoog gaat.

Door ook nog eens een testautomatiseringstool te kiezen waarvoor geen codering vereist is, kun je zéér veel tijd besparen op het “bouwen” van de tests, maar zeker ook op het onderhoud van de test suite.

Directe Feedback, 24×7
Vroeger, in het waterval tijdperk, werd als laatste stap voor de release de regressietest uitgevoerd. Met de introductie van automatisering wordt het echter mogelijk om iteratief te testen, direct te analyseren waarom een test niet geslaagd is en kunnen storingen sneller opgelost worden.

Continue regressietests (24×7) zorgen ervoor dat testers eerder op de hoogte worden gebracht van bugs. Deze kunnen dan door de visuele opnames en logs, snel en efficiënt worden opgelost.

Eisen aan een regressietest-tool

Er is een groot aantal tools beschikbaar om regressietesten te automatiseren. Selenium is een veel gebruikte tool omdat het een open source-framework is en het mogelijk maakt om acties in de browser te automatiseren. Selenium heeft echter ook zijn nadelen: het kost tijd om het te leren gebruiken, vereist een behoorlijke hoeveelheid onderhoud en kan alleen worden gebruikt om acties te automatiseren in de browser.

Het grootste nadeel van selenium is waarschijnlijk dat er redelijk veel gecodeerd moet worden. Dit betekent specialistische kennis voor het opzetten en onderhouden van de tests waardoor het rendement van de automatisering voor een groot deel weer wordt tenietgedaan.

Evalueer daarom je tool o.a. op onderstaande punten:
-Korte leercurve en eenvoud in gebruik, alle teamleden moeten testen kunnen opzetten;
-Visueel en zonder te hoeven coderen;
-Mogelijkheden tot samenwerking;
-Schaalbaar, mogelijkheden voor scheduling;
-Cross-technologisch, werkt met alle web-, mobiele en desktop-apps en -technologieën;
-Geschikt voor testen van een volledige keten;
-Vastlegging waarom testcases mislukken in video’s en logboeken.

Een tool die hieraan voldoet vindt je hier.

Frequentie van regressietests

Het antwoord is voor de hand liggend, zo vaak mogelijk. Dus liefst na elke nieuwe deployment/build van de applicatie. Het risico van elke doorgevoerde wijziging is tenslotte dat er nieuwe, onverwachte problemen naar voren komen. Als het een grote applicatie betreft dan kan dat enkel door automatisering.

In agile teams is het niet ongebruikelijk om elk uur een nieuwe release live te brengen. Door het inzetten van Low Code development is dit zeker niet meer ongebruikelijk. Dit betekent dus minimaal 8x per dag de regressietesten uitvoeren, dit naast het uitbreiden en onderhouden van de testen. Het gebruik van een scheduler, liefst aanwezig in de tool, is dan een mooie aanvulling. Zeker wanneer er gebruik gemaakt wordt van testschema’s die ook gedurende de niet-werkbare uren kunnen worden gestart.

Ook als er geen wijziging in de applicatie is doorgevoerd kan een regressietest zinvol zijn. Ook database- of systeemupdates, nieuwe browserversies kunnen een grote impact hebben ook de correcte werking van de applicatie.

Regressietesten: misschien niet het meest uitdagende onderdeel van de software ontwikkelcyclus. Automatiseren is dus de sleutel, want zonder kunnen we echt niet.

Evert Jan Bos, Business Development Manager bij Inforza Information Technologie

 

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in