(Geen) Testverbetering: Als SMART doelen niet SMART zijn

Als je aan de gang gaat met verbetering, kom je al snel op SMART. Om na te gaan of je je doelen bereikt, moeten ze specifiek, meetbaar, acceptabel, realistisch en tijdgebonden zijn. En dat geldt dus zeker ook voor testverbeteringen. Je wil na kunnen gaan of je je doel bereikt op een duidelijke en objectieve wijze. En je wil ze communiceren, zonder al te veel kans op misverstanden.

Op zich dus niets mis mee. Maar regelmatig loopt het opstellen van duidelijke doelen uit op een teleurstelling. De SMART goals zijn gehaald, toch is het eindresultaat een teleurstelling. Wat kan er mis gaan?

Het checklist effect

Stel je wil het aantal bugs, dat door de klant gebracht wordt terugbrengen. Als een van de onderdelen om dit te bereiken, wil je je testtraject verbeteren. Je wil daarom je regressietesten uitbreiden, de testdekking vergroten, unit testen invoeren en de kennis van je tester uitbreiden. Op basis van deze doelen voor testverbeteringen maak je een mooi plan met hierin elk onderwerp beschreven als een volledig correct en SMART doel.

Vervolgens gaat iedereen met het plan aan de gang. Elk doel wordt gehaald. Een jaar later krijg je opnieuw de statistieken over het aantal bugs van klanten onder ogen. En ondanks het uitstekende gevoerde plan, is het aantal bugs niet gezakt. Wat blijkt? Het grootste percentage bugs bevindt zich in de rapportages. En in geen enkele van de aanpassingen is de test van de rapportages verder uitgebreid.

Wat hier gebeurt, is dat het uiteindelijke doel uit het oog is verloren. Men heeft een lijstje met doelen gekregen en dat lijstje is een doel op zich geworden. Dit kan al gebeuren bij slechts 1 doel. Maar zeker als het er meer zijn, is de neiging groot om niet meer te weten wat het echte doel eigenlijk is. Soms wordt het je niet eens meer verteld. Het is tenslotte niet van belang, je weet op basis van het SMART doel toch wel wat je moet doen?

Wat zou moeten gebeuren, is het volgende:
Er wordt niet alleen gekeken naar het netjes geformuleerde SMART doel. Nee, er wordt ook gekeken naar het hogere doel. Breiden we de testen uit op een wijze, die werkelijk de bugs van klanten terug kan brengen? Melden klanten bugs over de applicatie onderdelen, die we willen aanpassen? En zo ja, hoeveel en hoe vaak dan? Het SMART doel gecombineerd met het kijken naar het hogere doel leiden vervolgens tot een goede aanpak en een goede testverbetering.

Zorg er ook voor dat je dit hogere doel objectief kan controleren. Er moeten minimaal statistieken zijn, die dit hogere doel meten en die je regelmatig kan controleren. Dit geeft je de optie je aanpak tussendoor te evalueren en eventueel aan te passen.

Ieder zijn deeltje

Neem nu 1 item van deze checklist: het uitbreiden van de regressietesten. Deze taak komt bij een tester terecht. Deze vraagt vervolgens: "Welke testen moet ik uitbreiden?". De maker van het plan was er heilig van overtuigd, dat dit toch wel door de tester bepaalt zou worden. Maar de tester is van mening, dat dit al uitgewerkt had moeten zijn in de taak. Beide hebben een manager, die ze gelijk geeft: ze hebben het al druk, ze moeten geen onnodig werk op zich nemen.

Hoeveel mensen je ook in een SMART doel neerzet, uiteindelijk moet er 1 hoofdverantwoordelijke zijn. Deze heeft als doel, ongeacht wie, wat of welke afdeling, ervoor te zorgen dat vragen beantwoord worden en problemen opgelost worden. Je kan niet alles in een SMART doel vastleggen. Tenslotte is het verstandig zo'n doel qua tekst niet al te lang te maken. Maar juist daarom hoort iedereen te weten, bij wie je terecht kan met vragen en problemen. Want hoe SMART een doel ook is, alleen dan is deze ook werkelijk haalbaar.

Het beloningseffect

SMART doelen zijn ideaal om mensen te beoordelen en te belonen. Waarbij ik belonen nu even ruim zie: zowel met complimenten voor goed werk als financieel. Er is een probleem: het is zeer moeilijk om een SMART doel op te stellen, wat zich niet tegen de opdrachtgever kan keren. Als iemand de opdracht heeft het aantal testen te verdubbelen, kan hij de bestaande testen splitsen in tweeën. Als iemand de opdracht heeft het aantal gemelde bugs te verminderen, kunnen bugs plotseling "Change requests" worden. Tenslotte is het een wijziging op de huidige werking, waarmee ze akkoord zijn gegaan. Toch?

Maar de SMART doelen kunnen ook in het nadeel van de uitvoerende werken. Iemand kan oprecht het aantal testen willen verdubbelen, maar vervolgens te horen krijgen, dat hij te weinig tijd besteed aan concreet testen. Of werkelijk de bugs willen verminderen, maar niet de tijd krijgen om de bestaande bugs te analyseren.

In beide gevallen kan de situatie ontstaan, dat een persoon bestraft wordt voor het doen wat het beste is voor het bedrijf of het gehoorzaam uitvoeren van een opdracht. En het is zelfs mogelijk dat een persoon beloond wordt voor het leveren van slecht werk. Dit kan "verstandige" testers dan ook nog eens stimuleren om bij de "onverstandige" testers te gaan horen. Die worden tenminste wel beloond.

SMART doelen werken alleen als de opdrachtgever en de uitvoerder(s) elkaar vertrouwen. Het vertrouwen dat beide partijen het beste willen halen uit het testen en de doelen kunnen behalen, maar tegelijkertijd beseffen dat doelen kunnen wijzigen. Beiden moeten bereid zijn om de doelen aan te passen, als dit noodzakelijk is. En, misschien een klein extra detail, ook zelf het recht hebben om tot deze aanpassing over te gaan.

Moet je SMART ontwijken?

Als je dit alles leest, zou je bijna de SMART doelen gaan ontwijken. Maar SMART doelen hebben ook hele grote voordelen, zoals in de inleiding al genoemd. Het grootste probleem is, dat juist een SMART geformuleerd doel stimuleert om niet verder te kijken dan je neus lang is. Want het doel is al zo ontzettend duidelijk, dat meer niet nodig lijkt. Toch moet je blijven kijken naar het grotere geheel en met elkaar blijven praten, om op 1 lijn te blijven. Als je dat niet vergeet en je weet ook nog eens als team, maar met leider, de situatie SMART aan te pakken, is er absoluut niets mis met SMART.

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.