De verboden bugs bij regressietesten

Bij het maken van een regressietest, al of niet geautomatiseerd, gebeurt soms iets, wat eigenlijk niet zou moeten kunnen. Je komt een bug tegen, die nog niet gevonden is. Dit zou een zeer uitzonderlijke situatie moeten zijn, omdat de functionaliteit eerder getest moet zijn. Maar het opstellen van een regressietest gaat vaak samen met het verbeteren van het testen in het algemeen. Daardoor kan de kwaliteit van de test tijdens de regressietest veel hoger zijn dan de kwaliteit van de test, waarmee de functionaliteit hiervoor is getest. En hierdoor kunnen bugs naar boven komen, die nog niet eerder gevonden zijn.

Iets wat je vlak daarna vaak zal horen: maar de bugs zijn niet gemeld door onze gebruikers of klanten. Ook deze gaat meestal niet op. Als er behoefte is aan kwaliteitsverbetering in testen, is dit vaak omdat gebruikers en klanten te veel bugs melden. En juist in zo'n situatie concentreren klanten en gebruikers zich vooral op de belangrijkste. Ze hebben de tijd niet beschikbaar, om je alles wat ze tegenkomen te laten weten. Zeker niet als ze regelmatig bugs tegen komen. Dus je weet eigenlijk niet of deze bug al eerder ontdekt is door een klant of niet. Alleen dat er voor de klant in ieder geval belangrijkere bugs zijn.

Maar dan kom je in de volgende situatie: hoe ga je om met deze "verboden" bugs bij het opstellen van regressietesten? Als je dit leest, voor je begint met het invoeren of verbeteren van regressietesten, is de beste actie in de voorbereiding. Vertel je opdrachtgever of leidinggevende, dat je onbekende bugs kan tegenkomen. En leg uit waarom dit het geval is. Begrip is de basis. En maak meteen afspraken over de afhandeling van deze bugs. Ook achteraf, als de bugs al gevonden zijn, is dit een verstandige stap om alsnog te doen.

Er zijn twee belangrijke argumenten om deze bugs op te lossen. Ten eerste het algemene streven naar een kwalitatief goed product. Ten tweede het streven naar een goede, betrouwbare regressietest. De tweede vraagt misschien wat toelichting. Een regressietest moet testen of de applicatie nog steeds goed werkt. Hiervoor bepaal je een bepaalde dekking. Je test bijvoorbeeld alle velden in een scherm of alle situaties, die voortkwamen uit een bestaande testtechniek. Maar een bug maakt een goede dekking onmogelijk. Je kan niet alle velden of situaties goed en volledig testen, zonder de test elke keer te laten falen. Want je moet om de bug heen testen, waardoor je niet alle velden en situaties test. Of je moet de bug accepteren als goed, waardoor je niet echt test of de applicatie goed is. Of je moet de test steeds laten falen, waardoor de regressietest niet goed meer uitgevoerd kan worden.

Als je slechts 1 bug vindt, is dit nog wel overkomelijk. Maar hoe meer bugs, hoe beschadigder je regressietest wordt. En je krijgt uiteindelijk twee hele verschillende regressietesten: een niet bestaande, die zou testen hoe de applicatie goed werkt en de bestaande, die test rekening houdend met de gevonden bugs.

Het algemene streven naar kwaliteit lijkt een stuk simpeler. In de praktijk is juist dit het minder sterke argument. De bug komt niet van een klant of gebruiker af en zit waarschijnlijk al vrij lang in de applicatie. Dus zelfs als je de bug wil oplossen, zullen er altijd belangrijkere bugs zijn. Namelijk de bugs, die wel door de klant of gebruiker zijn gemeld. Zelfs als tester kan je tegen dit argument weinig inbrengen.

Van belang is dan ook om beide argumenten goed naar voren te brengen. De reden om toch deze bugs op te lossen, zit namelijk in de combinatie. Om goed te testen moet je een betrouwbare regressietest kunnen opstellen. Een, die niet om de fouten heen werkt. En als bedrijf moet je streven naar een kwalitatief goed product, ongeacht of de klanten alle bugs melden of niet. Ook bij niet gemelde bugs is het van belang goed te kijken naar de andere zaken, die prioriteit bepalen: hoe vaak kan de bug in de praktijk voorkomen en hoe groot zijn de gevolgen van de bug. Anders gezegd: hoe groot is de kans dat gebruikers (denk hierbij ook vooral aan nieuwe gebruikers) de bug (alsnog) tegenkomen en hoe groot zijn de gevolgen als dit gebeurt.

Maar ga er niet vanuit, dat alle bugs in een keer worden opgelost. Dit verwachten schept vaak al meteen een jij-tegen-zij houding. Ga voor een afspraak, waarin de bugs meegenomen worden in de planning. Het belangrijkste is, dat eraan gewerkt wordt. Maar hou wel statistieken bij. Hou bij hoeveel van dit soort bugs je hebt gevonden en hoeveel er zijn opgelost. Zeker in het begin kunnen de bugs in aantal zeer sterk groeien, maar het gezamenlijke doel moet zijn de groei te stoppen. Zowel voor jezelf als voor de organisatie is het dan ook van belang om na te kunnen gaan of dit doel gehaald wordt. Zodat je weet of je misschien nog iets harder moet vechten. En als dat zo is, heb je in ieder geval de onderbouwing, via de statistieken, al gestart.