Testmanagement in SAFe®

In eerdere artikelen is Jan Santegoets ingegaan op Regie op Ketenkwaliteit met daarbinnen de Ketentest in SAFe®. Maar hoe zit het eigenlijk met de rol van Testmanager (TM) binnen (Scaled) Agile? Het eenvoudige antwoord zou zijn: die wordt niet genoemd, dus is er niet meer. En als we het over de individuele teams en de Release Treinen hebben dan klopt dat ook. Maar er knaagt iets. In dit artikel proberen we dat te verduidelijken.

Taken en verantwoordelijkheden

Wanneer we ons richten op de taken en verantwoordelijkheden van de “voormalig” TM dan zien we dat binnen de Agile wereld een verschuiving heeft plaats gevonden. Een deel van de taken verschuift naar de Product Owners en een deel verschuift naar de individuele teams.
•    Product Owner (PO)
Zo is de PO verantwoordelijk voor de kwaliteit van wat aan de teams wordt gevraagd te leveren en dient erop toe te zien dat dit ook gebeurt. De PO zal daarom de acceptatie criteria moeten benoemen voor de User Stories (US) die worden gepland. Daarvoor is het belangrijk om de behoefte van de klant te kennen. Daarbij is stakeholdermanagement van groot belang. Ken je stakeholders binnen zowel de business als beheer, het belang en het mandaat van deze stakeholders en manage deze belangen richting de resultaten van de teams en communiceer/deel deze resultaten via bijvoorbeeld reviews/demo’s.
•    Teams
De teams en de teamleden daarbinnen zijn verantwoordelijk voor het leveren van de gevraagde kwaliteit en het inzichtelijk maken daarvan. Ook zijn zij verantwoordelijk voor het uitvoeren van risico analyses en het benoemen van een testaanpak per US, het uitwerken en uitvoeren van scenario’s en het vastleggen van de resultaten. Ook het opzetten en onderhouden van een regressietestset en de toepassing van test automatisering valt onder de verantwoordelijkheid van de teams.
Een en ander lijkt versnipperd, maar door de samenwerking tussen beide partijen zou de kwaliteit voldoende moeten worden geborgd. Belangrijk hierbinnen is om elkaar aan te spreken op mogelijke risico’s en potentiële verbeteringen en daarop bij te sturen, zodat je groeit en verbetert als individu en als groep. Kortom, dit zou gewoon goed moeten werken. Hierbij kun je ook de rol van Agile Quality Coach inzetten om de betrokkenen te begeleiden en te coachen.
Maar juist door dat woordje “versnipperd” begint er wel iets te knagen. Dat komt doordat de TM voorheen meer deed dan wat nu bij deze partijen is belegd. En dan gaat het om het creëren van visie, beleid en richtlijnen op het gebied van kwaliteit en testen: De kapstok waar alles onder valt. Dat deel heeft onvoldoende een plek gekregen in “de nieuwe wereld”. 
Het gevaar dat dan ontstaat is dat er wildgroei in een organisatie plaats kan vinden en er mogelijk zelfs beveiligingsrisico’s worden gelopen (denk aan gratis, minder veilige tools die worden ingezet) en er onvoldoende synergie tussen de teams en treinen ontstaat. Een ander deel betreft de begeleiding en coaching van de specialisten. Deels gebeurt dat door het team zelf, de Scrum Master en eventueel de Agile Quality Coach. Deels zou dat echter op hoger niveau een plek dienen te krijgen: Een Community of Practise.

Organisatie

Naar mijn mening zou het goed zijn wanneer iemand zich in beginsel, minimaal op Solution niveau, bezighoudt met de genoemde visie, beleid en richtlijnen. Dit zou wanneer je klein en simpel begint ook op ART niveau kunnen zijn. “In beginsel”, omdat ik me kan voorstellen dat er op termijn, wanneer de organisatie naar een hoger volwassenheidsniveau is gegroeid, minder behoefte is aan een dergelijke rol op een lager niveau. Als daar sprake van is kun je kiezen om deze aspecten naar een hoger niveau in de organisatie te tillen. Welke naam je aan die rol koppelt is wat mij betreft vrij invulbaar voor een organisatie. Je kunt hiervoor de termen “Kwaliteitsmanager” of “Testmanager”, of soortgelijke termen gebruiken. De naam maakt niet uit. Het gaat om wat die persoon doet!

Vrijheid in gedrang?

Dit betekent niet dat de teams en individuen hun vrijheid verliezen in de keuze hoe dat ze zaken aan willen pakken. Dit betekent wel dat deze vrijheid op hoofdlijnen wordt gestuurd, met als doel:

• Meer synergie in de organisatie te creëren.
• De veiligheid van de organisatie te borgen. 
• Een regiefunctie te ondersteunen op het gebied van kwaliteit richting leveranciers en externe partijen met wie je een samenwerkingsverband aangaat.
• Op termijn eventuele uitwisseling tussen teams mogelijk te maken waardoor individuen verder kunnen groeien en teams positief geprikkeld worden met zogenaamd “nieuw bloed”.
• Specialistische samenwerking te organiseren, waardoor de mate van volwassenheid van het vakgebied verder groeit en wordt uitgedragen

Visie, beleid en richtlijnen

Waar moet je dan zoal aan denken? De visie, het beleid en de richtlijnen richten zich op kwaliteit en testen en kunnen worden opgenomen in een document als Generieke Test Afspraken (GTA). Concreet zouden de volgende onderdelen hierbinnen een plek dienen te krijgen, waarbij ik benadruk dat dit op hoofdlijnen gebeurt. 

• Scope: welke onderdeel van de organisatie dient zich hieraan te houden?
• Doelgroep: niet alleen interne individuen en onderdelen, maar ook leveranciers.
• Randvoorwaarden en uitgangspunten: bijvoorbeeld een verwijzing naar een Agile aanpak, het opvolgen van traceerbaarheid tussen behoefte, kwaliteit mitigerende maatregelen als testscenario’s, resultaten en releases, het gebruik van DoR en DoD, enz.
• Risico’s: teamoverstijgende risico’s met mitigerende maatregelen.
• Acceptatiecriteria: generieke criteria vanuit de business en beheer.
• Acceptanten: hoog-over zicht op de afdelingen met een accepterende rol.
• Decharge: hoog-over beschrijving van het decharge proces (voldoen aan de DoD, rol van de PO, de mate van bewijsvoering en rondom releasemomenten de oplevering van bijvoorbeeld een Business Readiness Rapportage – zie eerdere blog hierover).
• Teststrategie en -aanpak: generieke beschrijving van de aanpak waaronder het gebruik van risicoanalyse, mate van vastlegging scenario’s en resultaten, waaronder defects.  Specifiek voorbeeld: in geval van datamigraties kun je verwijzen naar een generieke aanpak rondom migraties dat men dient op te volgen.
• Testware: beheer en de specifieke plek die regressie daarin heeft.
• Testautomatisering: generieke beschrijving aanpak.
• Omgevingen: verwijzing naar landschap en de specifieke omgevingen daarbinnen.
• Testdata: generieke afspraken rondom het gebruik en het onderhoud van data. Denk ook aan Wet- en regelgeving!
• Testtools: richtlijnen over de inzet van tooling en hoe te handelen wanneer je daar vanaf wilt wijken.
• Mijlpalen en planning: eventuele verwijzen naar Program Increment en wellicht generieke release kalenders.
• DoR en DoD: generieke bepalingen die voor iedereen gelden.
• Community of Practise: verwijzing naar een virtueel team van specialisten die periodiek bij elkaar komen om van elkaar te leren en over kaders te praten.

De teams en de individuen worden vervolgens periodiek, door de verantwoordelijke voor bovenstaande, getoetst op naleving van deze onderdelen en waar nodig bijgestuurd of gecoacht. Ook kan deze bijvoorbeeld onderdelen onder de aandacht brengen tijdens een Community of Practise.

Meer over Testmanagement in SAFe®?

Heb je vragen of wil je hierover van gedachten wisselen neem dan contact op met Tinus. Wil je je eerst nog verder orienteren? Bekijk dan onze test services of onze expertise in testengineering!