Afgelopen week was er weer een testnet thema avond, o.a. met een presentatie van Suzanne Kraaij met als titel: Wie terugkijkt naar bugs, test slimmer vooruit.
Luisteren naar bugs
Lang niet altijd doen testers een root cause analyse op de bugs die ze vinden. Als dat wel gebeurd dan is het maar de vraag of de inzichten daarvan ook uitgebreid worden gedeeld. Terwijl o.a. van die inzichten juist zoveel te leren valt.
We kennen als testers allemaal wel het onderbuikgevoel. Je hebt een applicatie getest, je hebt (nog) geen (blocking) bugs gevonden, maar je onderbuikgevoel zegt dat het niet goed zit. Alleen kun je hiermee de testmanager en/of projectleider niet overtuigen om de livegang nog even uit te stellen.
Door met duidelijke cijfers te komen van bijvoorbeeld eerdere testrondes, en die te combineren met wat je nu ziet, krijg je beter inzicht en kun je de testmanager en/of de projectleider beter overtuigen dat er meer testtijd nodig is omdat er hoogstwaarschijnlijk toch meer issues in zitten.
Waar doet het pijn?
Om te bepalen hoe snel een bug opgelost moet worden, wordt er vaak een classificatie aangegeven zoals Blocking, High, Medium, Low (of anders Critical, Major, Minor). Dat wordt vaak bepaald op basis van hoeveel "pijn" de bug doet. Volgens Suzanne moeten we verder kijken dan dat.
Als voorbeeld haalde ze aan dat ze bij een opdracht in één van de software onderdelen amper bugs vond en degene die ze wel boven water wist te halen kregen de classificatie high of lager, niet blocking. Dit betreffende onderdeel werd in de praktijk maar door ~1% van de gebruikers gebruikt. Terwijl het onderdeel dat door 90% van de gebruikers werd gebruikt, veel meer bugs bevatte, waaronder ook blocking bugs. En dat terwijl er aan beide onderdelen net zo veel testtijd werd besteed.
Toen was de conclusie natuurlijk simpel. Test waar het pijn doet. Dit kennen we deels al als error guessing: waar je veel bugs vindt moet je meer testen. En op basis van risk based testing weet je al dat je de onderdelen die veel gebruikt worden, uitgebreider moet testen. Door je bugs inzichtelijk te maken, kun je hier betrouwbare conclusies aan verbinden, Bijvoorbeeld dat je mogelijk dus nog meer aan moet passen in je teststrategie..
Met hoeveel zijn jullie en hoe lang blijven jullie?
Het princiepe van error guessing hebben we allemaal bewust of onbewust al eens toegepast. En dat werkt goed als je zelf als enige test. Als je met meerdere mensen test aan dezelfde onderdelen, dan wel over meerdere dagen/ weken verspreid test, is het vaak niet zo duidelijk waar veel bugs zitten. Door bugs grondig te analyseren kun je goed achterhalen waar de bugs zich concreet bevinden en waar je dus mogelijk meer moet testen. Dit kun je bijvoorbeeld achterhalen door te onderzoeken in welk subsysteem of door welk stuk common code ze worden veroorzaakt.
Ook het proces van het verhelpen of oplossen van een bug mag je niet vergeten. Hoe lang duurt het voordat een bug wordt opgepakt en is verholpen? De verwachting is dat blockers sneller worden opgepakt dan medium of high bugs. Zo niet dan moet je het fix-proces een goed onder de loep nemen.
Ook als de tijd tussen het oppakken en het daadwerkelijk opleveren van een fix voor blocking bugs langer is dan die van bijvoorbeeld high- of medium bugs is het zaak dat je onderzoekt of er procesmatig iets fout gaat. Je hoeft dan je testproces niet aan te passen, maar mogelijk wel je fix proces. Want met testen krijg je niet meer kwaliteit, alleen inzicht in kwaliteit. Zonder dit inzicht kan je natuurlijk ook niet je doel bereiken als tester: de kwaliteitsverbetering. Het testproces en het fixproces zijn dus sterk aan elkaar verbonden.
Luisteren, luisteren, luisteren
Ik vond het een interessant onderwerp om naar te luisteren en over na te denken. Het was goed om weer bij een testnet meeting te zijn en ik kijk uit naar het volgende evenement.
Zoals het testnet voorjaarsevent op 6 mei.
Luister je met mij mee? Of ben je dan te druk met naar je bugs luisteren?
