Development

Software-ontwikkeling
Ketting stukgetrokken

Ketentesten voor agile teams een uitdaging

Mix van organisatorische en technische maatregelen nodig

© Shutterstock
20 december 2016

Mix van organisatorische en technische maatregelen nodig

Agile werken heeft voor veel bedrijven geen geheimen meer. Hoewel. Ketentesten is een behoorlijke puzzel geworden, schrijven Bob van de Burgt en Rik Teuben. Teams moeten onderling nauw willen en kunnen samenwerken. Servicevirtualisatie en (test)datamanagement zijn in dat verband essentieel.

De meeste organisaties zijn inmiddels overgestapt – of zitten midden in de transitie – naar agile werken. Kenmerkend voor deze aanpak is dat ook grote zaken, kleinschalig worden aangepakt. Kleine slagvaardige teams werken iteratief en leveren hun ‘Minimum Viable Product’ (MVP) zo snel mogelijk op. Maar de ketting breekt altijd bij de zwakste schakel, dus het belang van een goede ketentest is zeker niet minder groot geworden. Integendeel. Ketentesten is een behoorlijke puzzel geworden, waarbij het vinden van de juiste mix van organisatorische en technische middelen de belangrijkste uitdaging zijn.

Producten teams moeten naadloos op elkaar aansluiten

Agile werken is een beweging die veelal onder in de organisatie is begonnen. Succesclaims van de agile community zijn nagenoeg allemaal afkomstig van bedrijven die vanaf aanvang gekozen hebben voor een agile werkwijze. Agile teams richtten zich aanvankelijk op autonome en geïsoleerde applicaties. En met succes, de productiviteit ging met sprongen vooruit. De successen bleven niet onopgemerkt bij het hoger management en menig IT-manager gaf enthousiast de opdracht aan de gehele afdeling om agile te gaan werken. Veel van deze organisaties waren er onvoldoende op voorbereid dat een dergelijke transitie niet zonder meer tot succes leidt, maar gepaard moet gaan met een georkestreerde technische, organisatorische en culturele veranderpolitiek. Teams moeten onderling nauw willen en kunnen samenwerken en de producten van ieder team afzonderlijk moeten naadloos op elkaar aansluiten om tot succes te leiden.

Afspraken

De roep om Scaled Agility wordt steeds groter, maar Scaled Agile Frameworks (zie kader) geven maar ten dele een oplossing voor het tijdig ontvlechten van de ketens en voor het minimaliseren van de afstemmings- en planningsproblemen gedurende de testfase. Vooralsnog blijkt een organisatorische oplossing niet de silver bullet, mede omdat het uitrollen van Scaled Frameworks, zoals LeSS, SAFe of Nexus, bepaald geen sinecure is.

Frameworks

Er bestaan verschillende frameworks om agile op een hoger niveau in de organisatie te implementeren. De drie bekendste zijn:

• SAFe

SAFe staat voor Scaled Agile Framework en is ontwikkeld door Dean Leffingwell (http://www.scaledagileframework.com). SAFE is opgebouwd rond Agile Release Trains (ART). Een ART bestaat uit een virtuele organisatie van vijf tot twaalf agile teams. Deze teams werken samen naar een PI (Program Increment).

• Nexus

Nexus is ontwikkeld door Ken Swaber en Scrum.org (http:/www.scrum.org). Nexus coördineert de activiteiten tussen drie tot negen Scrum-teams om te komen tot een gecombineerde increment.

• LeSS

LeSS staat voor Large Scale Scrum en is ontwikkeld door Craig Larman en Bas Vodde (http://less.works). LeSS gebruikt de principes van Scrum om agile op te schalen zonder extra rollen en processen. Er zijn twee varianten. Basic LeSS kan worden ingezet tot acht Scrum-teams. Voor meer dan acht teams kan Less Huge gebruikt worden.

Deze organisatorische frameworks nodigen onvoldoende uit tot het maken van onderlinge afspraken tussen de teams over de ketentest omdat ze ervan uitgaan dat dit al door Continuous Integration is geregeld. Veel organisaties zijn echter nog lang niet zo ver. Hierdoor weet op belangrijke momenten niemand waaruit de eind- en deelverantwoordelijkheden hieromtrent bestaan en komt er geen effectieve samenwerking en communicatie tussen de teams op gang, op momenten dat dit wel nodig is.

De gangbare opvatting is dat dit eerst op orde moet zijn, voordat men over de implementatie van technische hulpmiddelen nadenkt. Oneliners als ‘a fool with a tool is still a fool’ blijven makkelijk hangen, maar nauwelijks iemand staat erbij stil dat het omgekeerde even waar is: ‘a tool with a fool, is still a tool.’ Werkt de organisatorische maatregel niet, dan hebben we altijd de tools nog. Er is een aannemelijk pleidooi dat de gelijktijdige invoer van organisatorische (zelf)sturingsmodellen en technische hulpmiddelen leidt tot een beter resultaat, omdat beide elkaar versterken. Implementatie van een Scaled Agile Framework samen met technische hulpmiddelen, zoals servicevirtualisatie (dus niet servervirtualisatie) en testdatamanagement, reduceert het aantal ketengerelateerde bevindingen aanzienlijk, en zorgt er in ieder geval voor dat deze niet vlak voor ‘het uur u’ of daarna worden opgemerkt.

Valsspelen

Ketenaspecten horen vroeg op de agenda (backlog) van de afzonderlijke teams te staan. De grondhouding van ieder team moet zijn om de juiste werking van zijn product (in ketenverband) aan te tonen. Virtualisatie en (test)datamanagement zijn in dat verband essentieel.

Mocking is de techniek die door developers gebruikt wordt als nog niet alle delen van services beschikbaar zijn. Het idee is natuurlijk even bruikbaar in de ketentest. Delen die nog niet beschikbaar zijn worden tijdelijk gesimuleerd. Dat klinkt als valsspelen, en dat is het natuurlijk ook als dat de enige manier is waarop de ketenintegratie wordt getoetst. Maar deze werkwijze heeft enkele grote voordelen.

Het belangrijkste voordeel is dat de onderlinge schakels van de keten al in een vroeg stadium en binnen het team (lees: zonder afhankelijkheid van een ander team) getest kunnen worden. Hierdoor wordt de kans op fouten later in het proces (als alle delen worden geïntegreerd) natuurlijk veel kleiner. Het lijkt een open deur, en dat is het ook. Het is daarom verbazingwekkend dat de creatie van Mock’s niet standaard op de backlog wordt geplaatst en/of deel uitmaakt van de ‘definition of done’.

Scaled Agile Frameworks geven maar ten dele een oplossing voor het tijdig ontvlechten van de ketens

Een ander voordeel is dat een ‘Mocktest’ eenvoudig opgenomen kan worden in de delivery pipeline waar het team gebruik van maakt, waardoor ook regressie in de ketenwerking tijdig wordt gesignaleerd. Iets waarbij in de traditionele ketentestbenadering nog wel eens een oogje wordt toegeknepen, omdat het (tijd)technisch onhaalbaar is.

Tools

Het aanbod van commerciële en opensource-servicevirtualisatietools is inmiddels zodanig dat er altijd wel een tool beschikbaar is dat past binnen het wensenlijstje en de randvoorwaarden.

Om de kwaliteit van de verschillende processen op een hoog niveau te houden is het van belang dat er controle is over de integratie van nieuwe systeemversies in de verschillende ketens. Om de werking over de keten blijvend te garanderen blijft het nodig om regelmatig de validiteit van de servicevirtualisatie vast te stellen.

Ketentesten kunnen alleen plaatsvinden als daarvoor tijdig voldoende, bruikbare data beschikbaar zijn. Vanuit het perspectief van een Scrum-team lijkt men te kunnen volstaan met het gebruik van synthetische data. Zodra de ‘mocks’ vervangen worden door échte systemen, is het gebruik van centraal beheerde productiedata verstandiger.

Stappenplan

De beheersing van procesketens kan middels de volgende stappen tot stand komen:

1. Breng het applicatielandschap, de afhankelijkheden (interfaces) en procesketens in kaart.

2. Bepaal de prioriteit van de verschillende procesketens en afhankelijkheden door middel van een risicoanalyse.

3. Ontwikkel een teststrategie, testplan en testscenario’s om de belangrijkste ketens te kunnen regressietesten bij nieuwe projecten en/of releases.

4. Bepaal de eisen aan de acceptatie-omgeving en de testdata en beheer die.

5. Neem ketenborging op in de definition of done van de verschillende agile teams.

6. Voer een Proof of Concept (POC) uit voor geautomatiseerde testen van de opgestelde testscenario’s om de doorlooptijd van het ketentesten te verkorten.

Het gebruik van productiedata voor testdoeleinden is begrensd door wettelijke kaders en vereist dat gegevens geanonimiseerd zijn. Maar dat anonimiseren brengt nogal eens het verlies van integriteit in de dataset teweeg. Dat kan leiden tot onverwacht ketengedrag en onterecht gerapporteerde fouten. Stel je maar eens voor hoe een ketentest bij een autoverzekeringsmaatschappij verloopt als blijkt dat er in de database personen zitten die jonger zijn dan 16, maar wel beschikken over een geldig rijbewijs. Dat leidt onherroepelijk tot onverwacht systeemgedrag tijdens de ketentest.

Een ander belangrijk aspect is de mate waarin de initiële dataset wordt gebruikt voor de opbouw van dynamische data. Denk bijvoorbeeld aan de betalingshistorie, logfiles et cetera. De gebruikte dataset moet zodanig van kwaliteit zijn dat ook de dynamische data integer – betrouwbaar – worden opgebouwd.

In een optimale situatie wordt een centraal dataportaal beheerd en ter beschikking gesteld. Daaruit kunnen dan de anonieme statische testdata worden geselecteerd die voldoen aan het profiel dat nodig is voor de ketentest, en zo vaak als gewenst worden gedupliceerd.

Samenvattend leveren Scaled Agile Frameworks een belangrijke bijdrage aan de verbetering van ketentesten in agile werkomgevingen. De voordelen ervan komen echter pas tot hun recht als gelijktijdig ook andere roadblocks, zoals planningsafhankelijkheden en de beschikbaarheid van integere testdata, teamoverstijgend worden aangepakt.

Zie ook Development op AG Connect Intelligence
1
Reacties
Anoniem 24 december 2016 07:59

Interessant verhaal!

Reactie toevoegen