Navigeer naar: #BLOG 1 #BLOG 2 #BLOG 4 #BLOG 5 #BLOG 6
Blog 3: Agile testen in een end-to-end omgeving: plakken is lastiger dan knippen
De kracht van Agile werkvormen zit hem in het opknippen van functionaliteit in kleine, hapklare brokken die in een iteratie door een team gerealiseerd worden. Dit resulteert in snel beschikbaar komende functionaliteit voor de eindgebruiker en het maakt teams wendbaar.
Aan de andere kant vereist het opknippen in behapbare brokken specifieke vormen van afstemmen. Binnen het team is dit eenvoudig te realiseren, maar vaak is er een omgeving die bestaat uit meerdere teams die samen een totaaloplossing realiseren. Veel problemen in de werking van producten zijn terug te leiden tot het missen van het team- en iteratie-overstijgend inzicht. Dat wil zeggen: inzicht in de totaaloplossing. Denk dan vooral aan het brede perspectief, zoals de non-functionals, ketens (het end-to-end systeem) en bedrijfsprocessen. Wat we vaak zien is dat ondanks grondig testen door elk team, het systeem toch omvalt bij de livegang van een aanpassing in een applicatie.
Een belangrijke vraag, die hierbij naar boven komt is, of de organisatie voldoende oog heeft gehad voor de ketens (end-to-end) en non-functionals, voordat de epic of feature werd opgeknipt in kleine, overzichtelijke brokken. Ketens en non-functionals zijn team-overstijgende zaken. De vraag is dan wie verantwoordelijk is voor het testen van team-overstijgende zaken. Gedeelde verantwoordelijkheid betekent vaak dat niemand echt verantwoordelijk is. Ketens zijn ‘het geheel van aan elkaar gelinkte systemen, die al dan niet via API’s informatie met elkaar uitwisselen.’ Interfaces zijn binnen het team te realiseren eenheden maar een integratie heeft betrekking op twee gekoppelde componenten die binnen Agile vaak over twee teams verdeeld zijn. Daar is een team-overstijgende helikopterview voor nodig. Er ontstaat dan een afstemmingsuitdaging en een kennisdelingsuitdaging. Als die niet goed gebeurt, heeft dat al snel een negatieve impact op het testen. Hier is met slimme keuzes al de eerste winst te behalen.
Als we dan bedenken dat het enkel en alleen testen van integraties en interfaces slechts technisch inzicht geeft in de uitwisseling van informatie (maar niet de vraag beantwoord of het systeem als geheel de juiste ondersteuning biedt aan de eindgebruiker, ofwel ‘Fit for purpose’ is, dan zien we daar een volgende uitdaging voor de realisatie van deze keten in een agile omgeving. Voeg hieraan toe, dat behalve de vaststelling van de functionele werking ook de non-functionals (zoals Usability, Performance en Security) steeds belangrijker worden in het huidige IT tijdperk, dan is de omvang en het belang van deze problematiek duidelijk.
Vanwege de hiervoor genoemde redenen is van belang om de totale omvang van de keten, zowel functioneel als non-functioneel, inclusief de processen, de omstandigheden en de (kritische) belemmerings- en succesfactoren binnen deze keten te beheersen. Er moet goed nagedacht worden over hoe, waar en wanneer binnen de agile context al deze zaken worden gebouwd en getest.
In de komende blogs in deze reeks gaan we in op andere, veel voorkomende problemen rond testen in agile teams.
Lees hier blog 4: Testautomatisering: een zegen of last?
Op donderdag 21 september behandelden we tijdens het Polteq webinar het toenemende belang van kwaliteit als onderscheidende factor bij softwareontwikkeling. Tijdens deze online lunch-presentatie gingen we in op het concept testprocesverbetering, methodieken om mogelijke verbeteringen te vinden en te adresseren en hoe je testprocesverbetering integraal kunt inbedden voor continue verbetering.
