Column: To bug or not to bug

Door de jaren heen heb ik een hoop met testen te maken gehad. Zowel direct door zelf te testen als indirect doordat bijvoorbeeld mijn software getest werd. Vragen als “waarom testen”, “hoeveel moet ik testen” of “wat moet ik testen” kwamen best vaak weer terug.

Een van de redenaties die ik tegen ben gekomen is lang blijven hangen, namelijk de vergelijking met fysieke producten. Neem bijvoorbeeld een brug; Gaan we eerst die brug bouwen en daarna kijken of die werkt? Kan ik er met een auto overheen rijden, of stort dan die brug in? Nee, mooi… laat ik dan eens met een vrachtwagen rijden. Daarna met een hele hoop auto’s en met een file, enzovoort. En als ik dan een jaar later lantaarnpalen ga plaatsen op die brug ga ik dan die brug weer helemaal opnieuw testen?

Dacht het niet! De brug wordt gebouwd met een hoop bestaande, bewezen technieken en borging van kwaliteit vooraf. De pilaren kunnen een gewicht aan dat naar berekening makkelijk een file van vrachtwagens aan kan. Het beton is bestendig tegen alle weersomstandigheden, legio aan beschadigingen, enzovoort. De kwaliteit wordt zo goed geborgd dat testen eigenlijk (bijna?) niet meer nodig is.

Grappig hoe bij het bouwen van software dit concept bij veel bedrijven amper te merken is. Het bouwen van software wordt zo makkelijk gemaakt en het testen ervan is zo normaal, dat we zelfs zaken als test driven development hebben. We gaan er vanaf het begin al van uit dat het getest moet worden en ons doel is om dat testje slagend te maken. Wat is er gebeurd met vooraf goed nadenken over de kwaliteit die je maakt? Lijkt soms wel of we de intentie om bugvrije software te maken hebben opgegeven. Ja, we zeggen wel dat we het willen, maar wat we dan meestal bedoelen is: We gaan er een heleboel testcapaciteit tegenaan gooien om de bugs die we gemaakt hebben er uit te halen en dan noemen we het bugvrij.

Wat zijn dan de zaken waar we uiteindelijk op testen?

  • Voldoet het aan de security eisen?
  • Is er voldoende rekening gehouden met compliance?
  • Is alles gebouwd naar specificatie?
  • Is de software bruikbaar voor de eindgebruiker?
  • Enzovoort

Allemaal zaken die de kwaliteit van de software bepalen, maar ben je dan aan het testen op bugs? Dat zijn toch uiteindelijke zaken die niet volgens specificatie gebouwd zijn, slecht design, niet volgens geldende standaarden of regels, enzovoort. Maar wat is dan wél een bug? Volgens wikipedia: “Een bug is een fout in een computerprogramma of een website, waardoor het zijn functie niet (geheel) volgens specificaties vervult.”

Met andere woorden, we hebben geconstateerd dat de specificaties van het programma kloppen, maar onder bepaalde omstandigheden of in een bepaalde situatie gebeurt er iets waarom het programma niet in staat is een correct resultaat te geven.

Ben ik daarmee voor of tegen testen? Helemaal niet, ik ben meer gaan nadenken over wat we nou eigenlijk aan het doen zijn of zouden moeten doen. Dat is de kwaliteit van de software die we leveren. Testen is daar een manier voor, maar niet de enige. Ik zie bij steeds meer bedrijven verschillende initiatieven ontstaan, zoals bijvoorbeeld 100% testdekking met featurefiles of risk-based testing. Heel tof om allemaal te zien! Laten we vooral naar elkaar kijken en ervoor zorgen dat we degelijke, maar ook software afleveren waar we trots op kunnen zijn.

“Testing shows the presence, not the absence of bugs” – Edsger W. Dijkstra

=====================

Marcel Joemmanbaks is Scrummaster bij PGGM in Zeist