De inhoud van je regressietest

In mijn opdrachten als testconsultant, komt dit onderwerp vaak weer terug bij het verzoek om een regressietest uit te voeren: '
'Wat moeten we testen en hoeveel tijd kost ons dat?'

Op dat laatste is wat moeilijker antwoord te geven (vaak hoeveel tijd er beschikbaar is). Op het eerste deel van de vraag is wél een antwoord te geven. Namelijk: 'Datgene waarvan je, als team én de business, zeker wilt zijn dat het werkt als je een (productie)release doet, én het past binnen de beschikbare tijd!' Als team wil je hier dus consensus over hebben.

Onderstaande punten dragen bij in de afweging voor de inhoud van je regressietest:

1. Kernfunctionaliteiten

Als dit nog niet gedaan is, stel dan in je team de kernfunctionaliteiten van de applicatie vast. Hiermee leg je de focus van je test op functies die essentieel zijn voor de juiste werking en waar gebruikers veel gebruik van maken.

2. Gewijzigde code

Juist de gewijzigde gebieden in je code zijn interessant om te testen. Hier is helaas niet altijd zicht op, maar de kans dat hier iets fout gaat is altijd aanwezig. Ook al heeft de code een unit-test ondergaan. Aannames mogen nooit worden gemaakt in de testwereld. Integratie in je pakket is vaak al erg complex.

3. Randgevallen

Robuustheid wordt vastgesteld door het testen van randgevallen en uitzonderlijke scenario's. Alleen als deze randgevallen behoren tot hoge risico’s zijn ze rendabel om mee te nemen in je regressietest. Randgevallen lenen zich er uitermate voor om geautomatiseerd te worden als daar de mogelijkheid toe is.

4. Integraties

In een paar korte testjes kun je de integratie van verschillende modules, randsystemen of componenten vaststellen om er zeker van te zijn dat ze (nog altijd) correct samenwerken. Ik raad aan om dit als één van je eerste tests te doen als een intake. Het geeft je direct inzicht in de kwaliteit van de opgeleverde software (of het gebrek ervan).  

5. Voorkom eerdere fouten

Eerder gevonden fouten uit het verleden wil je niet meer tegenkomen. Daarom is het handig om testgevallen toe te voegen om vast te stellen dat deze fouten niet opnieuw optreden. Dit toont ook aan dat je regressietest, waar nodig, dus ook altijd onderhouden moet worden.

6. De hoogste product risico’s

Dit is wellicht de belangrijkste van allemaal. In een vergevorderd en volwassen testproces vindt een Product Risico Analyse (PRA) plaats. Alle hoofd- en deelprocessen uit je product, die zijn beoordeeld met de hoogste risicoklasse, dienen te allen tijde te worden getest tijdens een regressietest. Dit geeft zowel het IT-team als de business vertrouwen om verantwoord te kunnen releasen.

Concluderend

Houdt rekening met de balans tussen volledigheid en efficiëntie om een effectieve regressietest te creëren. Waar ‘less = more’ en ‘keep it simple’ een belangrijke houvast zijn.

'Wat moeten we testen en hoeveel tijd kost ons dat?'

Misvattingen

Om deze blog af te sluiten schets ik een aantal misvattingen over het opbouwen van je regressietest. Tijdens een regressietest concentreer je je op het bevestigen dat bestaande functionaliteit nog steeds correct werkt na wijzigingen in de code. Soms wordt de regressietest te groot waardoor de essentie én de efficiëntie verloren gaat.

Wat laat je achterwege in een regressietest? Je leest het hieronder:

1. Nieuwe functionaliteiten

Regressietests richten zich op bestaande functionaliteit. Nieuwe functies worden doorgaans apart getest als onderdeel van acceptatietest of andere testfasen.
Later, als nieuwe functionaliteit beoordeeld wordt als hoogste risico, kan het altijd worden toegevoegd aan de regressietest.

2. Eenmalige gebeurtenissen

Test geen scenario's die slechts eenmalig plaatsvinden, zoals initiële installatie processen. Dit valt vaak onder andere testfases én een belangrijk gegeven is: ‘no risk = No test’.

3. Grote gegevensimport

Tijdens regressietests vermijd je meestal het testen van grootschalige gegevensimport (dataload/initial load), omdat dit specifieke prestatie- en integratietests vereist.

4. Veiligheidstests

Hoewel beveiliging belangrijk is, worden specifieke beveiligingstests doorgaans uitgevoerd in afzonderlijke testfasen, niet binnen regressietests. Daarnaast is het testen van de productveiligheid een bijzondere tak van sport en zal deze ook met de nodige specialisten moeten worden uitgevoerd.

5. Uitgebreide gebruikersacceptatietest

Regressietests richten zich op stabiliteit en eventueel herstel (bugfixes) van bestaande functionaliteit. Niet op uitgebreide acceptatietests die mogelijk betrekking hebben op het hele systeem.

Meer weten?

Wil je meer te weten komen over de regressietest of de Product Risico Analyse (PRA)? PTWEE helpt je graag aan de hand van een workshop om de juiste focus te hebben en een goed gestructureerd testproces te doorlopen.

Zie voor meer informatie ons aanbod aan workshops.