Testen doe je bij.... de foutenloterij

Testen, zeker handmatig testen, kost soms veel tijd. Je komt vervolgens 25 keer langs hetzelfde scherm. Een scherm, dat je steeds opnieuw weer moet invoeren. Heeft niet bijna iedere tester in zijn of haar hoofd een standaard adres voor adresformulieren? Een standaard bestelling voor een webshop? Of andere standaard gegevens, die je keer op keer opnieuw invoert? Hoe logisch! Maar besef je het gevaar ook?

Testen is regelmatig als een soort van loterij. Je voert gegevens in, voert handelingen uit en je hoopt zoveel mogelijk prijzen te winnen. Oftewel om zoveel mogelijk fouten te vinden. Hoe groter de fout, hoe trotser je bent. Maar grote fouten hebben vaak iets gemeen met grote prijzen in een loterij: hoe groter de prijs, hoe groter vaak de geluksfactor. Je moet bepaalde gegevens invoeren, bepaalde handelingen uitvoeren of nog erger: een combinatie van die twee. Als je dat niet doet, kom je die betreffende fout niet tegen.

De geluksfactor is echter te vergroten. Je standaard gegevens zijn al zo vaak ingevoerd. De kans dat je hiermee nog een fout vindt, is erg klein. Ja, de kans is aanwezig. Elke oplevering is tenslotte weer een nieuwe loterij. Toch zal het snel zeer verstandig zijn om je gegevens meer te variëren. Ondanks de extra tijd die dat kost.

Om dit duidelijk te maken, ga ik testen even nog meer benaderen als een loterij. Stel je hebt de cijfers 0 t/m 10 en een van deze tien cijfers gaat fout.

 

Stel nu dat je in al je testen steeds hetzelfde cijfer kiest. Je hebt dan 10% kans om de fout te vinden. Als je twee cijfers gebruikt tijdens je testen, is je kans echter al 20%. En als je 10 testcases hebt (iets wat zeker geen onrealistische situatie is) en je kiest elke keer een ander cijfer, is je kans om de fout te vinden gewoon 100%.

Varieer daarom je gegevens tijdens het testen. Dit vergroot echt al heel snel je kans op het vinden van fouten. Want hoewel de software bij cijfer 1 misschien hetzelfde zou moeten werken als bij cijfer 6, heeft niet iedere tester meegemaakt dat dit te vaak toch niet het geval is?

Ook de klant wil kwaliteit....

Misschien ken je het proces. Er komen veel fouten binnen, die aangegeven worden door klanten. De klant is belangrijk, dus deze fouten moeten zo snel mogelijk opgelost worden. In de backlog wordt weer van alles naar beneden geschoven om ruimte vrij te maken voor de fouten. Ook zaken, die voor een applicatie met een hogere kwaliteit zouden moeten zorgen. Ondanks het feit dat juist de lagere kwaliteit zorgt voor deze situatie. Het lijkt er sterk op, dat je steeds moet kiezen tussen de klant en kwaliteit. En de klant wint meestal. De rest komt later.

Daarnaast gebeurt er regelmatig het volgende: het uitstellen wordt goedgepraat. We doen namelijk wat de klant het liefste wil: de fouten die hij tegenkomt oplossen. Andere fouten: fouten gevonden door testers, door ontwikkelaars; ze zijn daarom minder belangrijk. Want de klant geeft het niet aan. Verbetertrajecten, het mag, maar eerst doen wat de klant wil. Met als toppunt: als de klant wil dat deze fout opgelost wordt, dan laat deze het ons toch wel weten?

Er is geen klant, die alles meldt
Het werken aan een fout kost tijd, dat snappen we. Maar staan we er ook bij stil dat het de klant ook tijd kost? Hoe hard het ook klinkt: hoe meer fouten je applicatie bevat; hoe kleiner percentage fouten dat je te horen krijgt. Klanten besteden zeker op zo'n moment hun tijd liever aan de fouten, die ze in hun werk belemmeren. Maar het is wel het totale zicht op de fouten, die bepalen hoe een klant over een product denkt.

Als een scherm twee knoppen heeft om op te slaan en een ervan geeft een grote foutmelding, dan zal dit niet altijd worden doorgegeven. Er werkt nog een knop. Als iemand al heel veel fouten hebt doorgegeven, laat hij het daarbij. Hij is tenslotte niet de tester. En hij kan doorwerken. Dat zegt niet dat hij de fout niet ernstig vindt. Het zegt alleen, dat het hem niet in zijn werk belemmerd.

Eeuwige cyclus
Daarnaast is er nog het volgende probleem: als je alleen je tijd besteed aan datgene wat je klant meldt, kan je in een eeuwige cyclus terechtkomen. Je bent zoveel tijd kwijt aan het oplossen van klantproblemen, dat je geen tijd vrij kan maken voor andere verbeterzaken. Hierdoor kom je steeds niet toe aan het verbeteren van je testproces, juist nodig om deze cyclus te doorbreken. Bugs zijn vaak ook nog eens moeilijker in te plannen, zodat je sprint eerder niet gehaald wordt. En doordat er steeds nieuwe fouten hoog op de backlog geplaatst worden, lijkt het wel of je nooit een stap verder komt in de backlog. De klant is vervolgens ontevreden over planning en over de kwaliteit. Waardoor het nog belangrijker wordt om de klant tevreden te stellen. Dus fouten die de klant meldt, moeten zeker dan zo snel mogelijk opgepakt worden. Waarna het weer overnieuw begint.....

Maar wat dan?
Het klinkt eenvoudig: verbeter je testproces en begin vandaag! Maar ik weet al wat de reactie is: dat wil ik wel, maar daar heb ik de tijd niet voor. Ja, ik weet dat ik regressietesten moet hebben en uitvoeren. Maar een complete regressietestset kost veel tijd. Die heb ik niet. Ja, ik weet dat ik eigenlijk de hele applicatie een keer goed zou moeten testen. Maar dat kost tijd, die ik niet heb. En zelfs al zou ik de tijd hebben. De bevindingen die uit het testen komen, die kunnen niet opgepakt worden. Fouten van de klant gaan voor, voor andere fouten is geen tijd.

Prioriteer alsof de klant ze meldt
Het belangrijkste is om de prioritering aan te passen. Het feit dat een klant ze meldt, mag niet de belangrijkste rol spelen in de prioritering. Natuurlijk, hoe belangrijk het voor een klant is, bepaalt sterk hoe snel een bug opgelost moet worden. Maar ga er niet automatisch van uit, dat alleen datgene wat gemeld wordt voor de klant belangrijk is. Ik heb al eerder geschreven, dat klanten best wel eens ernstige fouten, die ze tegenkomen, zullen verzwijgen. Maar daarnaast: wil je afwachten tot de klant ze wel vindt? Daarom is voor de prioritering het volgende van belang: prioriteer elke bug alsof deze door de klant gemeld is. Hoe zou je de bug prioriteren als deze van de klant afkwam? Dat is dan ook de prioriteit die de bug moet krijgen.

Test ruimer
Mijn ervaring is, dat waar een bug wordt gevonden, vaak soortgelijke bugs in de buurt zitten. Stel je je hebt een scherm met 100 velden. En veld 81 wordt niet opgeslagen. Regelmatig worden dan meerdere velden niet opgeslagen. En zeer regelmatig liggen ze bij veld 81 in de buurt. Als je een bug krijgt, test daarom ruimer dan de fout zelf. Test minimaal alle velden in de groep gegevens, waar het veld bijhoort. Test bij voorkeur alle velden in het hele scherm, als dit niet veel extra tijd kost.

Als in een deel van de business logica 1 fout gevonden is, test dan bij voorkeur alle regels. Dus als bijvoorbeeld de korting niet goed berekend wordt, test dan ook of de totaalprijs, het subtotaal, de BTW, de bezorgkosten, enz. wel goed berekend worden. En als de korting voor 65+  te weinig is, kijk dan of de korting voor andere mogelijke kortingen wel goed gaan.

Wat je reden is: waar iets fout gaat, gaat vaak meer fout. En als deze fout belangrijk genoeg is om op te lossen, zijn soortgelijke fouten belangrijk genoeg om te vinden. Om het niet teveel tijd te laten kosten, kan je het langzaamaan uitbreiden. Test bijvoorbeeld eerst de groep gegevens. Breidt dit uit tot het hele scherm, zodra de vorige testen geaccepteerd zijn of minder tijd kosten. En daarna tot meerdere soortgelijke schermen.

In een deel van de business logica kan je eerst de regels testen, die dezelfde gegevens gebruiken als je bug. Dat is uit te breiden naar de regels, die een van beide gegevens gebruikt. Tot alle regels over hetzelfde onderwerp. Dus bijvoorbeeld eerst alleen alle mogelijke vervoerskortingen voor 65+. Daarna alle mogelijke vervoerskortingen voor alle leeftijdscategorieën. Dan alle mogelijke kortingen voor alle leeftijdscategorieën.

Begin met regressietesten
Voor de zekerheid: regressietesten is belangrijker dan automatisch testen. Dus als automatisering niet kan, begin handmatig. Maar als iets bekend staat om de vele tijd die het kost, is het wel handmatig regressietesten. Enkel al het opstellen van deze testen kost heel veel tijd. Hoe kan je hier ooit aan beginnen?

Ook hiervoor geldt: dit kan stapje voor stapje. Als er een blokkerende fout gevonden wordt, schrijf dan een regressietest die deze blokkerende fout voorkomt. En bij voorkeur soortgelijke fouten, maar in ieder geval deze fout. Voer deze test ook elke sprint uit. Belangrijkste argument: als deze fout belangrijk genoeg is om zo hoog ingepland te worden, is het belangrijk genoeg om deze fout voor de klant te voorkomen.

Begin met regressietesten om de blokkerende fouten te voorkomen. Breidt deze daarna uit om de kritieke fouten (criticals) te voorkomen. En, als men enthousiast wordt, breidt hem uit naar de grote fouten (major). Als je handmatige regressietesten uitvoert, stop hier dan. Verder uitbreiden van je regressietesten kost vaak meer tijd, dan het oplevert. Bij testautomatisering kan je daarna nog verder gaan.

Maak de klant blij: verbeter je kwaliteit
Onthoudt dus dat de klant meer kwaliteit verwacht, dan de fouten die hij meldt. Werk daarom niet alleen aan de fouten, die de klant meldt. Werk ook aan fouten, die door andere gemeld worden. En behandel deze fouten allemaal gelijk. Test ruimer, om soortgelijke fouten te voorkomen. Zodat de klant ze niet zal vinden. En begin met regressietesten, om de grootste fouten te voorkomen. Zodat ze niet opnieuw bij de klant terecht komen. Hoewel dit in het begin misschien meer tijd kost, doorbreek je zo stap voor stap wel de negatieve kwaliteitscyclus. En daar worden uiteindelijk zowel jij als de klant blij van!