Menu

Aantal leden:
781
Aantal jaren testervaring:
9905
Aantal leden:
781
Aantal jaren testervaring:
9905
Word nu lid

Feedback loop mét risicoanalyse

Naam Rob de Jong
Functie Senior Testengineer
Bedrijf Anderis Software Testing

Als tester wordt je regelmatig geconfronteerd met bevindingen uit de testfase. Maar jouw werk eindigt niet bij het ‘bevinden’. De vraag ‘waar hoort deze bevinding thuis’ mag graag door de tester gesteld worden. Hiervoor gebruiken wij een feedback loop. Een omschrijving van de bevinding met de door de tester gevonden relevante informatie, wordt overgedragen aan de verantwoordelijke die betrokken was bij de ontwikkeling van het geteste product.

Wat vaak voorkomt: op basis van de bevindingen van de tester wordt een opdracht geformuleerd door de projectleider: ‘Pas de code aan om deze bug op te lossen’. Of: ‘Zorg ervoor dat deze foutmelding niet meer voorkomt’. Of nog charmanter: ‘Zorg dat het werkt.’ Vaak wordt vanuit het perspectief van het projectmanagement gestuurd op een tijdoptimale oplossing van een gevonden onvolledigheid. De feedbackloop wordt dan nog wel eens ‘te kort’ ingezet. Denk aan een blinde terugkoppeling naar een softwareontwikkelaar die de laatste aanpassing heeft doorgevoerd. Hoe kun jij helpen? Bijvoorbeeld door bij bevindingen de vraag te stellen: ‘waar kan dit het beste worden opgelost?’ 

Ik raad aan te beginnen bij het design en van daaruit via het gebruikte ontwikkelproces naar het eindproduct te werken. Zo kan bij elk stap de vraag gesteld worden: ‘Voldoet het product van deze processtap?’ De eerste plek waar hier ‘neen’ op geantwoord kan worden, is waar de feedback loop naar zou moeten wijzen. Dat stuit vaak op weerstand. Mensen zullen geneigd zijn te denken dat een quick-and-dirty reparatie in de code goedkoper is dan een designaanpassing. Maar als er iets mis is in het design, is het repareren in de code behoorlijk risicovol en kunnen de kosten flink oplopen. Een tester die dan adviseert op basis van een degelijke risicoanalyse, maakt de feedback loop vele male waardevoller.

Soms zitten de requirements niet in het design, maar zijn ze daarvoor al opgesteld, bijvoorbeeld bij het definiëren van het productidee of bij de feasibility. Wellicht kun je een feedback loop naar deze eerdere fases leggen. Dat zou nog beter zijn. Het design is echter een veilige startplek voor de meeste omgevingen