Zie het volgende voor je: je hebt een nieuwe auto gekocht. Je gaat vol verwachting naar de autodealer om hem op te halen. Je ziet dat er allemaal krassen op de motorkap zitten en denkt: ‘dat zullen ze zo nog wel even fixen toch? Of: dat zal wel niet mijn auto zijn?’. De verkoper komt naar je toe en feliciteert je met je aankoop en loopt recht af op de auto met de krassen waarbij hij de opmerking maakt: ‘ik weet dat er krassen op zitten, de kat was erop gesprongen, maar we moesten ook nog even een bosje bloemen kopen als felicitatie en er was geen tijd meer om die krassen weg te poetsen, maar bij de volgende onderhoudsbeurt zullen we dat meteen oplossen.’
We zullen allemaal begrijpen dat er maar weinig mensen zullen zijn die een nieuwe auto accepteren die vol krassen zit (met de belofte om dat op een later moment op te lossen). De reden hiervoor is simpel: je verwacht niet dat een leverancier van een product dat je koopt, dit product uitlevert met problemen waarvan hij het bestaan kent en die op te lossen zijn.
Dan rijst ook de vraag:
Waarom accepteren we wel software met bugs waarvan het bestaan bekend is?
We lijken het allemaal volstrekt normaal te vinden om een software product uit te leveren dat vol bekende fouten zit.
Dit is iets dat voortkomt uit de jaren 80 en 90. In de oude waterval tijd werden veel problemen pas gevonden als het product na maanden van ontwerpen en ontwikkelen door was gezet naar de fase ‘testen’. Als een gevonden probleem moest worden opgelost dan ging het opnieuw het hele ontwikkelmodel door en dat betekende meestal dat we zomaar weer één of meer maanden verder waren. Daar is de basis gelegd om bugs te gaan registreren en prioriteren om te kijken welke nog wel binnen acceptabele grenzen konden worden opgelost zonder dat de beloofde opleverdatum in gevaar zou komen.
Verder was het aantal gevonden bugs een graadmeter voor de kwaliteit van het product en een belangrijke bewijslast voor het nut, de noodzaak, de effectiviteit en productiviteit van de testers.
Inmiddels is het 2022 en werken we niet meer waterval en is onze manier van ontwikkelen en testen drastisch gewijzigd. Ook weten we dat het aantal bugs slechts zelden een afspiegeling is van de kwaliteit van de software, laat staan van de effectiviteit en productiviteit van testers.
En toch zijn we vaak niet afgestapt van het registereren van bugs! Waarom toch?
Als mens hebben we een ongrijpbare drang om te zoeken naar zekerheden en tot het afschuiven van accountability en aan de andere kant worden we liever ook niet geconfronteerd met onze eigen fouten. Dat is jammer, want als je echt beter wilt worden en snel wilt leren, moet je juist je fouten direct aanpakken en niet proberen ze af te schuiven of terzijde te leggen.
Is er dan een manier om van die bekende bugs af te komen?
Zeker! En de oplossing is nog heel simpel ook: zero bug policy
Voor details kijk op: https://medium.xolv.io/the-zero-bug-policy-b0bd987be684
Waarom doen we dit niet allang met z’n allen?
Er zijn talloze redenen om dit niet te doen:
Echter, de voordelen wegen ruim op tegen de ‘nadelen’:
In short: we kunnen doorgaan met wat we deden, maar daar worden we niet beter van, en we weten dat die instelling haaks staat op de agile way of working. Introduceer daarom de zero bug policy vandaag nog: je doet jezelf, je team en de klant er echt een plezier mee.
‘Bug strategy’ is onderdeel van de training Agile-United Certified Practitioner in Agile Testing. Wil je hier als software tester meer over weten of beter in worden, kijk dan op onze site.
Alain Bultink | Managing Director
[email protected]
06-15361077
Benno Kuipers | Directeur
[email protected]
06-52600438
Emilie Lamers | Directeur
[email protected]
06-15653500