Regressie testen is een belangrijk onderdeel van de werkzaamheden van een software tester. Grof gezegd testen deze tests de functionaliteit van de softwareonderdelen die niet gewijzigd werden tijdens het ontwikkelproces. Dus waarom zijn ze dan zo belangrijk? Hieronder geef ik u graag meer uitleg.
Regressie testen in beheer
Laat u uw software testen in beheer dan is het het eerste doel van uw software testers om te kijken hoe uw werkomgeving reageert op de nieuwe software (en vice versa). De eerste aandacht gaat zo uit naar die gebieden waar de software zich anders gedraagt dan ‘normaal’ te verwachten is. Deze probleemgebieden worden aangepast om zo de werking van het programma beter af te stemmen op de specifieke context waarin het programma opereert of zou moeten opereren.
Aanpassingen die zo worden aangebracht kunnen echter ook een effect hebben op andere facetten van het programma, facetten die nochtans onaangeroerd bleven. Deze vaststelling is misschien zelfs wel een van de natuurwetten van de informatica te noemen. Het is een weerkerende fenomeen: nieuwe implementaties kunnen nieuwe fouten creëren of oude, slapende fouten reactiveren.
Zo’n fout (bug) kan optreden door slecht nazicht van een herstelling (fix) of gewoon door een menselijke fout. Soms is het ook gewoon de aard van het beestje. In veel gevallen is een eerste fix bovendien te karakteriseren als ‘fragile’ (fragiel). Dat betekent dat hij niet altijd even goed functioneert, of dat hij aanvankelijk wel werkt, maar later niet meer. Daarnaast kan een fix in het ene domein ook problemen veroorzaken in een ander, of kunnen designfouten worden overgedragen van implementatie op implementatie.
Regressie testen versus acceptatie testen
Het is deze (‘ongewijzigde’) programmatuur die vervolgens wordt ‘hertest’ via een regressietest. Met deze tests gaat de software tester met andere woorden op zoek naar nieuwe bugs ten gevolge van aanpassingen aan (andere domeinen van) het systeem. De tests verzekeren dus dat nieuwigheden geen nieuwe disfuncties genereren. Wat dat betreft wordt de regressietest overigens onderscheiden van niet-regressietesten (of acceptatietesten). Deze testen controleren namelijk of een doorgevoerde wijziging het gewenste effect heeft.
Veelgebruikte regressie testen
In concreto is een veelgebruikte methode hier het opnieuw uitvoeren van eerder vervolledigde tests. Daarbij wordt vervolgens gecontroleerd hoe het programma zich nu gedraagt: of er veranderingen optreden in het gedrag, en of fouten die voorheen hersteld werden al dan niet weer opduiken. Efficiëntie en effectiviteit worden ondertussen verkregen door een geschikte, minimale set van testen samen te stellen, afgestemd op de beoogde aanpassingen. Regressietesten kunnen daarbij overigens zowel betrekking hebben op de werking van het programma als op de (kwaliteit van de) output ervan.
Regressie testen als ‘best practice’
Aangezien regressie-problematieken een wezenlijk deel uitmaken van het designproces worden regressietesten ook gezien als een integraal onderdeel van goed coderen. Wanneer een bug wordt gelokaliseerd en gefixt, dienen er tegelijk voldoende regressietesten te worden ondernomen. Alleen zo kan worden aangetoond dat de bug inderdaad gefixt is en dat die fix geen andere problemen veroorzaakt. Deze tests kunnen manueel worden ondernomen, maar verlopen vaak ook automatisch. Sommige projecten gebruiken zelfs geautomatiseerde systemen die automatisch regressietesten ondernemen na specifieke intervallen. Daarbij worden bugs systematisch gerapporteerd. Men spreekt dan van regressietesten als onderdeel van Extreme Programming Software Development.
Types van regressie testen
Vanuit dit kader kunnen regressietesten, tot slot, onderverdeeld worden in twee grote categorieën: functionele testen en unit testen. Het eerste type test het volledige programma via verschillende inputs. Het tweede type test individuele functies, subroutines of objectmethodes. De gebuikte tools zijn doorgaans gespecialiseerd en maken als dusdanig geen regulier onderdeel uit van het onderzochte softwarepakket. Meestal betreft het, zoals gezegd, ook geautomatiseerde toepassingen. Een functionele test is meestal een serie input-scripts, waarin doorgaans ook een mechanische mouse-bediening wordt geïntegreerd. Een unit test is een set van aparte functies die een reactie vragen van de broncode, zij het zonder de geteste code te wijzigen.
Wilt u meer weten over de mogelijkheden van regressietesten voor uw organisatie? Neem dan contact met ons op. Ik sta u graag te woord.
Over de auteur
Met zijn jarenlange ervaring als software tester gecombineerd met zijn uitgebreide kennis van retail processen en kassasystemen kan Berry van der Rijk (www.retailtester.nl) in een korte periode op basis van een product risico analyse uw (kassa) systeem testen en u inzicht geven in de kwaliteit en de openstaande risico’s aan de hand waarvan u kunt bepalen of u de opgeleverde release wel of niet in gebruik wilt gaan nemen.
Bent u geïnteresseerd in de diensten van Berry, neem dan contact op via berry@vanderrijk.nl of bel direct op +31628452551