Leer van fouten

Naam Jan van Moll
Functie Senior Manager Quality& Regulatory
Bedrijf Philips Healthcare, MRI

Natuurlijk, je doet je best om defects te pakken, voordat je het product vrijgeeft. Toch zie je na de release vaak nare fouten. “Hoe kunnen we die nou gemist hebben?”, hoor je dan op verwijtende toon. Het is zaak de fouten snel te herstellen, maar belangrijker nog is te weten wat er écht mis ging. En dan bedoel ik ook écht! Dus niet alleen focussen op het technisch falen, want dat is zelden de oorzaak. Ik houd me regelmatig bezig met de analyse van post-release defects. Meestal worden die uitsluitend door ontwikkelaars geanalyseerd en als de technische oorzaak eenmaal is gevonden, stopt ook meteen de oorzaakanalyse. Als tester is het dan zinvol (en leerzaam) om door te pakken. Denk breed. Waarom was het bewuste requirement fout? Komt dit omdat besloten is twee van de vier testcycles te skippen? Hebben we die uitbesteedde software wel getest vóór de integratie? Was onze testomgeving wel representatief? Zit de fout in een softwarecomponent, die we hergebruikt hebben met oneigenlijke aannames?

Mijn ervaring is dat mensen het waarderen als de tester zich breed oriënteert bij het analyseren van de oorzaak. Maatregelen ter verbetering zijn ook veel effectiever als je de échte root cause vindt. Kortom: stort je als tester in de foutenanalyse. De stress krijg je er gratis bij, maar de ervaringen die je opdoet, kun je prima gebruiken voor het verscherpen van de testaanpak. En voor het verbeteren van de aanpalende processen, zoals configuratiemanagement en requirementsmanagement. Wees niet bang voor ‘politieke spanningen’, geef vrijuit je mening. Ook het (project)management neemt soms beslissingen, die leiden tot fouten na de release. Onthoud: testen is mensenwerk, fouten zullen er altijd zijn. Oorzaakanalyse verbreedt je testhorizon en vergroot je toegevoegde waarde.