In de meeste ontwikkelteams maakt testen onderdeel uit van de werkzaamheden van ontwikkelaars. Vaak is er een teamlid aanwezig die testen als kernexpertise heeft. Deze persoon neemt de verantwoordelijkheid op zich om een testaanpak te definiëren en deze waar nodig af te stemmen met die van andere teams. Verder heeft deze expert de taak om de andere teamleden te begeleiden bij het voorbereiden en, al dan niet geautomatiseerd, uitvoeren van testen.
Het is voor de testexpert een flinke uitdaging om testcoördinerende taken uit te voeren, testanalyses te doen, teamleden te begeleiden en ook nog toe te komen aan niet test gerelateerde taken. Laat staan er op toe te zien dat er verbeteringen in het testproces worden gerealiseerd.
Tijd voor hulp. Tijd voor een assessment!
Tijdens de retrospective kan het onderwerp testen op de agenda komen te staan. Mijn ervaring is dat dan de organisatie van het testen ter sprake komt, maar vaak niet de kwaliteit van de aanpak. Want wie is in staat om de testexpert op de aanpak te challengen? Op initiatief van de SCRUM Master of op verzoek van het ontwikkelteam zelf is het effectief om met hulp van buiten het team een hoger niveau van testen te bereiken.
Door het laten uitvoeren van een assessment wordt inzichtelijk op welke punten op korte en langere termijn een verbetering van het testen gerealiseerd kan worden.
Het middel om het testproces te optimaliseren is “van oudsher” Test Process Improvement (TPI). TPI geeft een organisatie inzicht in de volwassenheid van het gehele testproces en definieert aanbevelingen om op gecontroleerde wijze tot een hoger volwassenheidniveau te komen. Maar binnen een Dev-Ops of SCRUM team is vaak geen sprake van een testproces dat we kennen vanuit de watervalmethodiek. TPI is dus niet altijd goed bruikbaar. Daarom hebben een aantal organisaties het model aangepast om het toepasbaar te maken in Agile ontwikkelomgevingen. Het model bevat verschillende aspecten van het testen, zoals Test strategie en Testware management, en definieert volwassenheidsniveaus voor het individu, het team en de organisatie. Zo geven de uitkomsten van het assessment concreet aan op welk gebied verbeteringen te realiseren zijn.
De moeilijkheid van het verbeterproces zit in dit aspect: het definiëren van verbeteringen die daadwerkelijk gerealiseerd kunnen worden door een Agile ontwikkelteam.
In mijn optiek is de follow up van het assessment wezenlijk anders dan die van de oorspronkelijke TPI. Een Agile team is geen team van testers die zich puur willen ontwikkelen op hun vakgebied. Een organisatie die bestaat uit testers, testcoördinatoren en een testmanager die puur verantwoordelijk is voor het opzetten en uitvoeren van het testproces heeft in mijn optiek meer de intrinsieke motivatie om zich tot een hoger volwassenheidsniveau te ontwikkelen. In een Agile team wil niet ieder teamlid zich in hoge mate ontwikkelen buiten zijn eigen expertisegebied.
De verbeteringen voor een Agile team moeten daarom praktisch en direct toepasbaar zijn zodat ieder teamlid die kan toepassen en de voordelen ervan kan ervaren. Aandachtsgebieden zijn bijvoorbeeld het opzetten en onderhouden van test data, het specificeren van testgevallen zodat iedereen die begrijpt en uit kan voeren en het toegankelijk maken van geautomatiseerd testen. Dat alles moet ondersteund worden door een steeds verdere uitwerking van een concrete teststrategie die bestaat uit een korte beschrijving van het testproces en, met name, de definiëring van de doelstelling waarmee elke test uitgevoerd moet worden. Als elk teamlid begrijpt waarom hij een test uitvoert, is hij ook in staat om te bepalen wat er voor nodig is om dat doel te bereiken. Op die manier spreek je de kennis en creativiteit van elk teamlid aan en biedt dat de mogelijkheid om tot een hoger niveau van testen te komen.
In mijn optiek is het ook in een Agile omgeving raadzaam met externe hulp verbeteringen door te voeren. Je mag van het team niet verwachten dat ze zich op elk vlak zelfstandig in het gewenste tempo tot een hoger niveau kunnen ontwikkelen. Belangrijk daarbij is dat het initiatief vanuit het team zelf komt, mogelijk door een signaal van de Scrum Master. Op basis van de uitkomsten van een assessment kunnen in samenwerking met het ontwikkelteam activiteiten worden gedefinieerd welke het resultaat van het testen daadwerkelijk op een hoger niveau brengt.
