Agile/Scrum: iedere organisatie doet het, denkt er over na of heeft het gedaan. Gevolg is dat testverbetering toe is aan de volgende stap: optimaliseren van testen binnen Agile. Gerenommeerde modellen als TPI (Next) en TMMi passen niet echt, leiden zelfs tot verbetervoorstellen die strijdig zijn met Agile/Scrum. Dit artikel gaat in op ervaringen met een afwijkende aanpak voor testverbetering, toegespitst op een Agile context.
Een van de grotere it-organisaties binnen de Nederlandse overheid heeft gekozen voor Agile/Scrum als aanpak voor het vrijwel volledig vernieuwen van de bestaande kernsystemen. Doel van het programma is ervoor te zorgen dat de werkprocessen binnen de organisatie efficiënter verlopen. Onderdeel is het volledig digitaliseren van de communicatie met de burgers. Tevens wordt het overgrote deel van de verouderde systemen vervangen om sneller te kunnen inspelen op – last-minute – wijzigingen in de wet- en regelgeving. Het programma legt de basis voor het toekomstige it-landschap.
De vraag
Na circa 1,5 jaar leeft bij het management de vraag of ‘men op de goede weg is’ met testen binnen Agile/Scrum. De vertrouwde testafdeling is slechts zijdelings betrokken bij het programma, het programma maakt slechts beperkt gebruik van de bestaande standaarden, processen en tools voor testen. En dus begint men zich zorgen te maken… Dit leidt tot de binnen de overheid vaker verstrekte opdracht: voer een onafhankelijk onderzoek uit naar de efficiëntie en effectiviteit van het testen en stel, indien van toepassing, een verbeterplan op.
De aanpak
In overleg met de opdrachtgever wordt gekozen voor een kort maar krachtig onderzoek door een assessment-team, bestaande uit een senior tester met gedegen kennis van Agile (Edze Knol) en een ervaren consultant met gedegen kennis van testprocesverbetering (ondergetekende).
Kort maar krachtig betekent dit concreet dat, naast een uitgebreid gesprek met de eindverantwoordelijke en de testmanager, een aantal groepsinterviews worden afgenomen met :
- het requirements- en ontwerpteam,
- een aantal Scrum-teams,
- het beheer- en implementatieteam.
Daar waar je bij reguliere assessments relatief veel tijd spendeert aan analyse en studie van documentatie, ligt in dit geval de nadruk op de gesprekken en het bijwonen van diverse Agile/Scrum-meetings.
Als referentiemodel wordt gekozen voor TI4Agile waarover Jeroen Mengerink in maart 2013 in het artikel ‘Het verbeteren van testen in een Agile context‘ heeft geschreven.
Het onderzoek
Al tijdens het eerste gesprek blijkt men Agile/Scrum op zijn geheel eigen wijze, passend in de context, toepast. De aanpak wordt het best samengevat als ‘Water – Scrum – Fall’:
- De requirements worden volgens een waterval aanpak opgesteld door business analisten. Belangrijkste reden is dat het programma naast de bestaande systemen wordt ontwikkeld en de business gewend is op die manier requirements met it af te spreken;
- Het detailleren, (technisch) ontwerpen, ontwikkelen en testen van de requirements vindt plaats binnen een van de Agile-teams. Hierbij wordt in multidisciplinaire teams gezamenlijk gewerkt;
- Na oplevering door een van de teams wordt gewerkt aan de implementatie van de opgeleverde producten. Denk hierbij naast het implementeren en in beheer nemen van de software ook aan het aanpassen van business processen, ontwikkelen van handleidingen en het voorbereiden van opleidingen.
Als Agilista [A practitioner of Agile Software Development who is fanatical about hewing to the Agile Manifesto, Urban dictionary] komt dit natuurlijk ietwat vreemd over. Maar al gauw blijkt deze keuze weloverwogen en niet geheel ten onrechte te zijn. Naast de uitdagende doelstelling van het programma, is ook de materie uitermate complex. De overheid heeft namelijk de neiging om uitzondering op uitzondering te stapelen. Gevolg: het interpreteren van de wet is een vak apart geworden. Zeker gezien de bijkomende eis dat het nieuwe systeem dezelfde resultaten oplevert als de bestaande systemen, is de keuze voor ‘Water – Scrum – Fall’ begrijpelijk. Overigens is dit een vaak gekozen oplossing binnen organisaties waar er een strikte scheiding is tussen business en it.
Het resultaat
Belangrijke test voor testverbetering in een Agile context: zijn wij in staat om een gedegen advies over mogelijke verbeteringen te geven? En wel zodanig dat alle betrokkenen er mee aan de slag kunnen. En dan met name de teams op de werkvloer. Tijdens de eindpresentatie voor een groot deel van het programma en andere geïnteresseerden, waaronder de ‘oude’ testorganisatie, blijkt al snel dat de gevolgde aanpak en de resultaten van het onderzoek in goede aarde vallen. Niet omdat we beginnen met de highlights, maar omdat men – daar waar we verbeteringen voorstellen op basis van het assessment en TI4Agile – erkent dat het beter kan en herkent dat ons voorstel hen de goede kant op helpt.
Ten slotte
De testmanager heeft de uitkomsten van het assessment vrijwel een-op-een overgenomen in zijn implementatieplan. Hij is erin geslaagd in redelijk korte tijd verbeteringen daadwerkelijk te realiseren. Mijn conclusie is dan ook dat testverbetering de volgende stap in zijn eigen ontwikkeling heeft gemaakt en dat een model als TI4Agile ons in staat stelt klanten die ‘worstelen’ met de implementatie van Agile/Scrum en de rol van testen, daadwerkelijk te helpen. Let wel, ook hier geldt dat het model een hulpmiddel is en geen doel.
Overigens, net als bij de meeste TPI-assessments, heeft een (groot) deel van de te verbeteren punten vrij weinig te maken met testen in een Agile context. Zaken als ontbrekende acceptatiecriteria, ‘wij van ontwikkeling en test’ versus ‘zij van beheer en implementatie’ en het feit dat ontwikkeling reeds is gestart terwijl het globaal ontwerp nog niet is goedgekeurd, komen ons in ieder geval bekend voor. Wat dat betreft is ook in dit geval het advies: communiceer met elkaar, werk samen aan één doel en help elkaar. Ook als het soms makkelijker is om af te wachten en naar anderen te wijzen.
Met dank aan mijn collega Edze Knol voor zijn inbreng.
Weer een koekje vanuit de eigen koekjesfabriek.
Men heeft doorgaans alle elementen al in huis een goede teststraat in te kunnen richten, vaak mankeert het net aan goede IT professionals met gedegen E@E ervaring en kennis. Heb je die dan zijn hiaten doorgaans als sneeuw voor de zon verdwenen.
Datzelfde geld overigens ook voor de betrokken overige IT professionals. Als men namelijk gewoon de eenduidige uniforme taal gaat spreken, dan is er doorgaans niet zo heel veel te vrezen.
Waarom krijgen zaken zoals Scrum e.a. dan die ruimte?
Dat is een hele goede vraag. Stelt u zich eens voor dat er, om welk reden dan ook, een stuk overkoepelende kennis tussen IT disciplines is verdwenen, dan krijg je hiaten en die hiaten verlangen oog en aandacht.
Hoe langer men daarmee wacht, des te groter de kloof en kans dat je IT professionals plots iets moeten gaan leren, iets wat in dit geval scrum heet.
De basis van IT
De basis van IT is nog steeds het eenvoudige en lineaire principe welke je alleen maar op elkaar aan hoeft te passen om gesloten procedures te krijgen en goed solide functionerende systemen.
Uiteraard is een ieder volkomen vrij geld uit te geven voor iets wat niet een noodzaak blijkt.
Hi Ruud, wat waren nu de geconstateerde verbeteringen?
Ik snap dat eea vertrouwelijk is, maar kun je richting geven welke problemen jullie regelmatig tegen het lijf lopen bij het verbeteren van testprocessen in een Agile context?
Overigens is het heel herkenbaar dat veel genoemde testverbeteringen buiten het testwerkveld liggen. Precies de reden waarom ik mij richt op ontwikkel verbeterprocessen 😉
Ik ben net als Anko benieuwd naar een verbetering.
Mijn stelling is dat testen nooit het probleem is en dat de problemen doorgaans ergens anders in het proces liggen.
Daarmee zeg ik niet dat testen altijd goed verloopt.
Een TPI/TMMi assessment kan altijd uitgevoerd worden, in elk project type. Het adaptieve van TMap Next moet je dan alleen niet vergeten toe te passen. De context van de omgeving bepaalt heel veel en daar moet je mee om weten te gaan.
Hi Maurice,
je zegt “de context van de omgeving bepaalt heel veel” – maar houden de testverbeterprocessen daar dan ook rekening mee? Of focussen die zich vooral op het testproces zelf?
Als dat zo is, zijn testverbetermethodieken dus ultimo weinig effectief: het toont geen oorzaken (want veelal buiten het testen), en de oplossing ligt buiten de methodiek (want buiten het testen)…? 😉
Om dan de testverbetermethodes meteen af te schieten, vind ik ook zo wat. Die methodes kloppen echt wel. Ik denk dat die methodes je ook moeten triggeren verder te kijken. Agile adoptie of gebrek aan iets van release management zijn voorbeelden waar testen sterk door wordt beinvloed en dat zijn wel invloeden van buiten het testen.
Net als met TMap bijvoorbeeld moet je de methode niet voorop stellen. De methode leid je langs een weg, waar je allerlei keuzes moet maken en vooral ook luisteren naar je omgeving.