Interview met Ruud Teunissen: ‘Het gaat om de verbetering, niet het scoren’

Auteur: Ruud Teunissen ● ruud.teunissen@polteq.com
Ruud Teunissen, senior testconsultant, is sinds 1989 werkzaam in de testwereld. Ik was benieuwd naar zijn ideeën over Test improvement in een Agile wereld.
Lisa Gelijns: Ruud, in je blog ruudteunissen.wordpress.com komt het onderwerp Test improvement een aantal keer terug. Waarom schrijf je graag over dit onderwerp?
Ruud Teunissen: één van de leukste aspecten van het werken als testconsultant vind ik het helpen, begeleiden, ondersteunen, opleiden, trainen en coachen van testers. Overigens, tester is voor mij een containerbegrip dat tester, testautomatiseerder, testcoach, testmanager, enzovoort omvat.  Of het nu gaat om een organisatie, een afdeling, een team of een individu. Het geeft mij persoonlijk voldoening als we samen veranderingen, hoe klein ook, succesvol doorvoeren. Zeker als het gaat om testers die na die stap nog meer tot hun recht komen en de impact van de verbetering merkbaar wordt.
LG: Kun je een ervaringsvoorbeeld geven van een mooie verbetering op dit gebied?
RT: Mijn eerste kennismaking met testverbetering op een meer formele manier was eind vorige eeuw. Daarbij heb ik gebruikgemaakt van TPI, dat door Martin Pol en Tim Koomen is ontwikkeld. Omdat de opdrachtgever het verwachtte, hield ik me eerst strak aan het model. Na het eerste assessment ben ik daar vanaf gestapt. Het gaat om de verbetering, niet het ‘scoren’.
Het vervolgtraject vind ik interessanter: het realiseren van de verbetering. Eén van de verbetertrajecten waar ik nog steeds met veel plezier naar terugkijk, begon met een assessment. Het echte werk, het verbeteren zelf, heeft bijna drie jaar geduurd en heb ik samen met een aantal collega’s mogen uitvoeren en begeleiden. Tot op de dag van vandaag worden onderdelen van dat wat we toen hebben neergezet, nog steeds toegepast. En een aantal van de mensen die we hebben omgeschoold en begeleid, is nu nog actief als tester. Ik heb regelmatig contact met hen en ben ook een aantal keer teruggeweest om te ondersteunen.
LG: Merk je dat de vraag en/of de oplossingen veranderen in een wereld waar steeds meer Agile wordt gewerkt? Qua scope of proces, is het nu meer gericht op verbeteringen van automatisering?
RT: Absoluut. De impact van het kortcyclisch ontwikkelen op een Agile/Scrum manier heeft impact op zowel de vraag als de oplossingsrichting.
Tot een aantal jaar geleden begon een verbetertraject met een soort van nulmeting aan de hand van een vooraf vastgesteld referentiekader, bijvoorbeeld TPI (Next), en was de opdracht recht-toe-recht-aan: organiseer interviews met de testers, testmanagers, ontwerpers, ontwikkelaars, projectmanagers, opdrachtgever, enzovoort. Bestudeer de documentatie van testaanpak tot en met testcases, van projectaanpak tot en met bug-tracking. Analyseer en geef aan welke sterke punten je hebt waargenomen en op welke vlakken je ziet waar verbetering mogelijk en/of noodzakelijk is.
Afhankelijk van de scope van de opdracht ga je dieper in op de verbetersuggesties en het implementatieplan. De verbetersuggesties waren vaak gericht op veranderingen in het proces, het gebruik van technieken, verslaglegging, communicatie en het beter inzichtelijk, transparanter maken van testen.
Bij de laatste verbeterinitiatieven staat vaak het referentiekader nog niet gelijk vast, die bepaal je tijdens het onderzoek. Documentatiestudie wordt vervangen door observeren tijdens de verschillende meetings en het meelopen op de werkvloer. Uiteraard zijn en blijven interviews een cruciale informatiebron, het gesprek is wel breder: naast het ophalen van informatie wordt veel meer tijd besteed aan het bespreken van wat moet blijven en ideeën voor verbetering. In feite een individuele retrospective.
Een ander belangrijk verschil is dat verbetersuggesties, waar mogelijk, onmiddellijk doorgevoerd worden en niet pas na afloop van het onderzoek.
Het type verbetering focust meer op een beter afstemming tussen de verschillende testen, kijkt breder dan het testen alleen. En kijkt ook naar testautomatisering.
Kortcyclisch is prachtig maar betekent meer en vaker regressietesten. En door het werken in multidisciplinaire teams kun je gebruikmaken van de synergie tussen wat getest moet worden (testen) en hoe te automatiseren (ontwikkeling).
Net als bij testers is ook bij test improvement nadrukkelijk sprake van T-shaping: doe ook kennis op van de good practices van ontwerp, ontwikkeling, beheer. Zorg voor een stevige basis in Scrum, Agile, Lean, Kanban, … en wees niet bang ook daar iets van te vinden.