En dan heb je Scrum, met korte sprints. Sprints, waarin de tijd dus al beperkt is. Bij een sprint van twee weken heeft een regressietest van twee dagen een flinke impact.Maar als je alles wil testen in een grote applicatie, is twee dagen zelfs vaak nog te weinig. Niet voor niets wordt vaak gezegd dat handmatig regressietesten en Scrum gewoon niet samengaan. Je hebt de tijd er niet voor. Dus heb je meerdere opties: de regressietest overslaan en gokken dat de kwaliteit toch goed is, de oplevering uitstellen tot een sprint waarin je een hele lange regressietest plant of natuurlijk de regressietest automatiseren.
Waarom zou je hierover nadenken?
Aan iedereen, die altijd de volledige regressietest handmatig uitvoert, zou ik het volgende willen vragen: reken uit hoeveel uren je aan de regressietest besteed hebt. En kijk daarna naar de bugs die je hebt gevonden. Als deze bugs nu via de helpdesk of via de klant binnen zouden komen, hoeveel uur zou je er dan aan mogen besteden? Een validatiefout is zeker belangrijk, maar als je 8 uur nodig zou hebben om hem op te lossen, zou dat mogen? Waarschijnlijk zou er vaak gezegd worden: als het meer dan 4 uur is, dan kunnen we onze tijd beter besteden. Doe is een schatting van de tijd, die je aan het oplossen van de gevonden bugs zou mogen besteden. En vergelijk dit aantal uren met de tijd, die de regressietest heeft gekost. Als de tijd voor de regressietest lager is of ongeveer even hoog, dan moet je vooral zo door blijven gaan. Als de tijd overduidelijk hoger is, vraag je dan het volgende af: als ik deze tijd niet mag besteden aan het oplossen, waarom zou ik die tijd dan wel willen besteden aan het vinden van de bugs?En dan de vraag voor de groep, die de regressietest maar overslaat: hoeveel tijd kost het eigenlijk om de regessietest niet te doen? Hoe vaak wordt er een bug door de klant gemeld, die je met een regressietest had kunnen voorkomen? Hoeveel tijd kost het om deze bug te analyseren en en om de bug met de klant te bespreken? Hoeveel tijd is het team als geheel kwijt met klachten van klanten over de kwaliteit in het algemeen? Hoeveel tijd zou je besparen als je zelf de bug zou ontdekken en de bug niet van een klant af hoeft te komen? Zou regressietesten dan uiteindelijk geen tijd besparen?
Maar hoe moet je dan handmatig regressietesten?
Binnen het testen is risk based testing vrij normaal. Je kijkt naar testsoorten, dekkingsgraden, etc. En mede op basis van de kans op een fout en de gevolgen als de fout optreedt, bepaal je hoever je gaat met je testen. Waarom zou je zo'n soortgelijke techniek niet bij regressietesten toepassen?Er zijn onderdelen, die altijd moeten werken. Die onderdelen test je daarom altijd met een regressietest. Maar vaak geldt wel voor regressietesten: als het fout gaat, gaat het vaak altijd fout. Daar bedoel ik mee: als een knop eerst werkte, is bij de regressietest de kans groot dat de knop nu altijd werkt of altijd niet werkt. De kans dat de knop soms wel en soms niet werkt, is meestal niet zo groot. Dus een groffe handmatige regressietest, waarbij je alle belangrijke functies 1 keer raakt, kan met minder tijd al een flinke vermindering in risico opleveren.
Wanneer een knop toch plotseling soms wel en soms niet werkt, is er vaak sprake van enig raakvlak met een uitgevoerde aanpassing. De knop was bijvoorbeeld in hetzelfde scherm als de aanpassing. Of de algemene functionaliteit voor het actief en inactief maken van elementen is aangepast. Of het scherm voorafgaande aan de scherm met de knop is aangepast. Stel dat er dus een aanpassing in een scherm is geweest. Dan kan het zeer verstandig zijn de regressietest voor dit scherm wel uitgebreider te doen. Het kan ook verstandig zijn om een werkproces, waar dit scherm een onderdeel van is, wat uitgebreider te regressietesten. Overleg eventueel met het team en de productowner hoe ver je wil gaan? Hoe groot is het risico dat de aanpassing iets onverwachts heeft geraakt? Welke onderdelen of processen hebben het grootste risico op een fout? En hoe ernstig is dat?
