Agile

Bestaat er zoiets als Agile testmanagement?

Deze vraag was aanleiding voor een aantal testspecialisten van Alten om eens de koppen bij elkaar te steken. We zijn tenslotte als testers veelal terecht gekomen in scrumteams. We zien dat ook deze scrumteams moeite hebben om werkende software over een complex landschap van applicaties en processen, op te leveren. Komt dit doordat er zoiets ontbreekt als agile testmanagement? Wat is agile testmanagement? Kortom interessante vragen om eens nader te kijken naar testmanagement in een agile context. Hieronder kun je de resultaten van onze zoektocht lezen.

Blog Agile TestmanagementDe avond begon met de simpele vraag wat we überhaupt onder testmanagement verstaan (voor zover daar een eenduidige contextvrije definitie voor is). We kwamen in ieder geval tot categorieën, zoals:

  • Operationeel testen: organiseren van acceptatietesten, testdata over systemen organiseren, teams met elkaar verbinden m.b.t. ketentesten, bevindingen overleggen voeren, (master)testplannen voor projecten, productrisico analyses begeleiden.
  • Strategisch niveau: visie op testen en testautomatisering uitwerken, testtool selecties voor de hele organisatie, de positie van testen in software ontwikkelingen proces bepalen en bewaken, beheer afspraken maken m.b.t. testomgevingen, nieuwe ontwikkelingen onderzoeken en eventueel vertalen naar de werkvloer.
  • Maar ook managementtaken zoals budgettering, (test)planningen maken, voortgangsrapportages (voor stakeholders) schrijven, verantwoordelijkheid voor de testers in termen van opleiding en coaching en ook beoordeling.

Samenvattend gaat testmanagement over het coördineren en faciliteren van testen en testers van operationeel via tactisch tot op strategisch niveau.

De volgende stap was de discussie over de transitie naar Agile/scrum in grote organisaties. Hierbij maken organisaties gebruik van bijvoorbeeld het Agile Framework SAFe. Wat betekent zo’n transitie voor testmanagement taken?

Hierbij bekeken we testmanagement vanuit drie invalshoeken:

  1. Taken die uitstekend door een scrumteam uitgevoerd kunnen worden,
  2. Testmanagement taken die niet meer van toepassing zijn,
  3. Testmanagement taken die buiten het team georganiseerd moeten worden.

Het uitgangspunt in de discussie was een organisatie waar meerdere scrumteams actief zijn en waar een grote complexiteit en diversiteit van systemen aanwezig is.

Met deze aanname in het achterhoofd zie je natuurlijk dat alle operationele taken van testen in scrumteams zijn belegd: een team is verantwoordelijk voor het opleveren van werkende, dus geteste, software.  Om te komen tot geteste software is het ook de verantwoordelijkheid van het team om de randvoorwaarden voor goed testen zelf te regelen. Van representatieve testdata en testomgevingen tot de inzet van testtooling. Alles rond de uitvoering van testen is ook in het team belegd: productrisico inschatting (veelal met product owner en stakeholders), een testaanpak voor de user stories en de kwaliteitsbewaking van het testen.

Hierdoor vervallen de management taken die onder de paraplu van testmanagement werden uitgevoerd: testplanningen, bevindingen overleggen en testrapportages. Deze testmanagement taken zijn dus niet meer van toepassing.

Een scrumteam opereert echter niet in een vacuüm en dit betekent dat ook vanuit organisatieperspectief ‘zaken geregeld moeten worden’. Daarbij kun je denken aan:

  • Testomgevingen regelen voor applicaties in de keten, evenals testdata over die applicaties.
  • Het combineren van nieuwe, van elkaar afhankelijke software in één release.
  • Het delen van testkennis en -kunde tussen teams of discussies over de mate en gewenste testvolwassenheid per team.

Binnen scrum is dit al deels afgedekt door de guilds waarin testers bij elkaar komen. Het zijn echter ook taken die uitstekend gefaciliteerd kunnen worden vanuit een testmanagementrol die buiten het team is belegd.

We kwamen ook tot de conclusie dat met name de afhankelijkheden tussen scrumteams m.b.t. applicaties en processen lastig te regelen is vanuit een scrumteam. Dit heeft veelal te maken met de gevolgen van de aanpassingen die door scrumteams worden uitgevoerd in relatie tot de focus van een scrumteam. We zagen daarbij twee soorten focus van scrumteams: de product- of systeemfocus versus een procesfocus van een scrumteam:

Als een scrumteam gefocust is op de aanpassing van een bedrijfsproces over verschillende applicaties, wie neemt dan de verantwoordelijkheid voor de werking van de onderliggende applicaties die ook nog voor andere bedrijfsprocessen (die weer door andere scrumteams worden aangepast)?

Als de focus van een scrumteam ligt op de aanpassing van een systeem (één of enkele applicaties), wie houdt dan de werking van de bedrijfsprocessen die over meerdere applicaties (aangepast door meerdere scrumteams) in de gaten?

Hier is bij uitstek dus een rol voor testmanagement weggelegd. Ten eerste is er behoefte aan overzicht over applicaties en bedrijfsprocessen heen. Wat is de mogelijke impact van de aanpassing van een schakel in het grote geheel? En als de impact is bepaald, hoe kan dan worden vastgesteld of de aanpassing geen onverwachte gevolgen heeft? Het testmanagement moet dan dus de verantwoordelijkheid nemen om ervoor te zorgen dat er geen negatieve waarde ontstaat bij de vele wijzigingen die door de verschillende teams worden doorgevoerd. Hierbij kan natuurlijk ook test tooling worden ingezet als hulpmiddel bij het testen van ketens of bij het uitvoeren van checks op regressierisico’s.

De verantwoordelijkheid om te komen tot werkende software in een complex applicatielandschap kan nooit door scrumteams worden gedragen. Hier kan agile testmanagement een bijdrage leveren en medeverantwoordelijkheid dragen.

Met dank aan: David Berens, Mark Burghout, Edo van der Post, Marten Janssen, Judith Penders, Jochem Schenk en Wiksash Madarie.

Ard Kramer, TestconsultantArd Kramer