Een Scrum-team kan niet zonder tester: vier redenen

De businessunitmanager bracht het stellig: "De ontwikkelaars in jouw team maken uitstekende unittests. Volledig geautomatiseerd. Het aantal bugs dat ze daarmee vinden is indrukwekkend. In mijn volgende project is een tester dus niet meer nodig. Wat denk jij?" Daar sta je dan, en met een mond vol tanden prevel je: "Maar testen… en kwaliteit…". Je komt er niet uit. Daarom in deze blog vier ultieme redenen waarom geen Scrum-team zonder tester kan.

De kwaliteitskatalysator
Een Scrum-team is multidisciplinair. Als het goed is, is geen enkel lid uitsluitend gericht op zijn of haar discipline. Van elk lid mag verwacht worden dat hij/zij zich verantwoordelijk voelt voor de kwaliteit. Maar als iedereen verantwoordelijk is voor de kwaliteit, is uiteindelijk niemand verantwoordelijk. Door te testen wil een tester een gefundeerde uitspraak kunnen doen over de mate waarin het product voldoet aan impliciete en expliciete verwachtingen. Met andere woorden: de tester wil iets zeggen over de kwaliteit van het product. Deze gefundeerde uitspraak over de kwaliteit is voor het hele team belangrijk. Door het team continu en op verschillende manieren te attenderen op de huidige en de gewenste kwaliteit van de software fungeert de tester als een kwaliteitskatalysator. Dit kan bijvoorbeeld concreet vorm krijgen door, zoals de Scrum Guide zegt, de definitions of done uit te breiden met strengere criteria om een hogere kwaliteit te borgen.

De testexpert
Testen is een vak. Dat klinkt voor een tester erg vanzelfsprekend, maar het kan geen kwaad dit te blijven benadrukken. Van een tester in een Scrum-team mag gedegen kennis van testactiviteiten, -producten en -technieken verwacht worden. Juist als de ontwikkelaars ook testen, is testexpertise van belang. Niet alles kan getest worden, maar wat is de dekkingsgraad? Welke risico’s moeten als eerste afgedekt worden? Welke kwaliteitsattributen zijn het belangrijkst? Door zijn of haar opleiding en ervaring is de tester de juiste persoon om hier gedegen antwoord op te geven.

De vragensteller
Een tester stelt vragen. Veel vragen. Hoeveel aannames worden er niet gedaan bij het opstellen van de user stories? Wat wordt precies bedoeld met deze user story? In welke gevallen moet dat zo werken? Wat zijn de acceptatiecriteria voor de nieuwe user story? Ze moeten en mogen gesteld worden: de vragen die voor de hand liggen en de vragen waar nog niemand een antwoord op heeft. Uit onszelf geven we op zoveel vragen reeds een antwoord dat we ze überhaupt vergeten te stellen. Geldt dat niet ook in softwareontwikkeling? Door het stellen van vragen maakt de tester aannames en vooronderstellingen expliciet. Dat is nodig om tot een consistente en complete testbasis te komen.

De eindgebruiker
De tester is de schakel tussen de business en het softwareontwikkelteam. Wat kwalitatieve goede software is staat niet vast. Kwaliteit is de mate waarin software voldoet aan impliciete en expliciete verwachtingen en eisen. Een tester moet de eindgebruiker dus zo goed mogelijk kennen. Wat verwacht de eindgebruiker? Maar ook: wat vindt de eindgebruiker belangrijk zonder dat het ooit benoemd is? Een uitstekende gelegenheid om je als tester in de gebruiker te verdiepen, is meekijken met zijn of haar werk. Mogelijk is er dan ook de gelegenheid om vragen te stellen, maar onderbreek de gebruiker niet te vaak. Een gebruikersacceptatietest is ook een mooie gelegenheid om zicht te krijgen op hoe de applicatie wordt gebruikt. Vaak blijkt dat bepaalde functionaliteit lang niet zo vanzelfsprekend is als je denkt en dat elke gebruiker weer anders werkt. Wordt er software ontwikkeld voor de consument, dan is dit meekijken lastiger. Een pilot onder klanten of enkele klanten uitnodigen voor het testen van een nieuwe versie kan veel bruikbare informatie opleveren.

In een Scrum-team maken we onderscheid tussen roles en capabilities. De redenen in deze blog zou je ook capabilities kunnen noemen. En misschien zijn ze, verdeeld over verschillende personen, wel aanwezig in het team. Maar zou één role met al deze capabilities niet veel meer waarde toevoegen? Hij of zij bestaat: de tester!

Deze blog verscheen eerder op www.centric.eu/craft.