shiftDown approach voor de Software Delivery Pipeline

Redactie: Gerben de la Rambelje
Auteur: Werkgroep Testautomatisering TestNet
Dinsdag 28 november hadden we als Werkgroep Testautomatisering (WTA) van TestNet onze maandelijkse sessie. Waar we het over zouden gaan hebben, was ons nog niet helemaal duidelijk. We dachten dat het zou gaan over hoe we testautomatisering in een organisatie moeten beleggen; is dat centraal of decentraal? Echter, we kwamen al snel op een ander spoor te zitten. Tijdens de opstartdiscussie vroegen de aanwezigen zich af waarom doen we eigenlijk al die inspanning voor testautomatisering? Het antwoord hierop was simpel: ‘Time to Market’. We doen het om sneller dan de concurrent nieuwe features op de markt te brengen. Waarbij sommige bedrijven zelfs een strategie hebben dat snelheid van opleveren naar productie boven de kwaliteit gaat. Maar gaat deze strategie ook op bij bedrijven waar de financiële consequenties (bijvoorbeeld banken) heel groot kunnen zijn? Ons antwoord daarop is NEE. Want één verkeerde oplevering en het kost je miljoenen en daar gaat je imago en wellicht het voortbestaan van je bedrijf.
 

Welk framework is het meest geschikt voor de Software Pipeline?

In onze vorige sessie waren we er al over uit dat de basis voor een goede testautomatiseringstrategie de ‘Test Piramide van Mike Cohn’ is. Maar als de unittest de basis voor de testautomatisering is, dan moet je daar ook je software-developmentaanpak op afstemmen; ‘Test Driven Developement (TDD)’ past daar dan het beste bij. Belangrijk onderdeel van TDD is het creëren van awareness bij developers hoe de code getest moet worden, iets dat testers prima kunnen doen.
Maar wat is nu het beste framework om je organisatie zo in te richten dat die Software Pipeline als een geoliede machine gaat lopen? Tegenwoordig zie je vaak het ‘Spotify Model’ voorbijkomen als een goede optie. Echter, de WTA vindt dat de autonomie in dit model iets te ver doorslaat. Maar wat dan wel? De WTA ging aan de slag.
 

Agile bij mijnBank

We begonnen met een denkbeeldige bank genoemd mijnBank, die vijf productgeoriënteerde teams heeft, namelijk:

• Saldo/overview;
• Rapportage;
• Overboeken;
• Aanloggen;
• Koppelingen.

Gestart met een paar velletjes om onze ideeën ‘uit te tekenen’ en zo kwamen we uit op de volgende plaat:

Ieder team heeft zijn eigen Unittest (UT), Unit Integratietest (UIT), Componenten Test (CT):

• UT/UIT – methods, classes – IDE tools;
• CT – Features/BDD – protractor / selenium;
• CT – binnen eigen onderdeel Functioneel testen en interface testen;
• Integraties tussen de teams doen de teams zelf;
• Een overall integratietest team overstijgend. Net als het testen van de keten/processen;
• Non functionals op alle niveaus testen.

Als we naar bovenstaande plaat kijken, dan zien we net als bij de ‘Test Piramide van Mike Cohn’ dat er een piramide is ontstaan. Ontegenzeggelijk zie je in deze plaat dat de basis voor een IT-organisatie de teams zijn.
 

‘shiftDown approach’ voor de Software Delivery Pipeline

Dan hebben we dus teams in de piramide. Maar hoe gaan we het zo organiseren zodat deze teams ook daadwerkelijk gaan floreren? Natuurlijk werken de teams allemaal volgens het Scrum framework. Maar om de teams echt goed te laten functioneren is volgens de WTA het beste om zo veel als mogelijk verantwoordelijkheid bij de teams te beleggen. Immers, zij beheren de producten en moeten de kwaliteit borgen om op die manier voor de continuïteit te kunnen zorgen vanaf Development tot aan productie.
De rol van de tester is om er onder andere voor te zorgen dat in elk team de testautomatisering volgens de Test Piramide van Mike Cohn wordt uitgevoerd. Daarnaast moet de tester bewaken of een wijziging geen invloed heeft op een ander onderdeel binnen het applicatie landschap.
Het zoveel mogelijk verantwoordelijkheid aan de teams te geven noemt de WTA de ‘shiftDown approach’. ‘shiftDown’ legt de focus daar waar die hoort te liggen.
 

‘shiftDown approach’, hoe gaan we het organiseren?

Hoe houden we de regie enigszins in handen. Om het spel in de piramide goed te kunnen beheersen stelt de WTA de volgende extra rollen voor:

• Integrity Master – integrator;
• Product owner voor overall acceptatie.

Om het overzicht en de kwaliteit goed te kunnen bewaken is een ‘Integrity Master’ noodzakelijk. Deze rol zorgt ervoor dat bij elke oplevering de samenhang en de kwaliteit wordt bewaakt. Om de vinger aan de pols te kunnen houden organiseert hij bijvoorbeeld tweewekelijks een Integration of Integrations’. Bij deze meetings worden alle testers uitgenodigd en worden alle ophanden zijnde opleveringen besproken vanuit een Risk Based perspectief. Daarnaast is er een Product Owner die voor de overall acceptatie verantwoordelijk is. Deze Product Owner zorgt ervoor dat de stakeholders van de business aangelijnd blijven. Om genoeg contact momenten te hebben met Product Owners, Scrum Masters, stakeholders, organiseert hij twee wekelijks de ‘Product of Products’.
Mogen de teams binnen ‘shifDown approach’ echt alles zelf bepalen; de WTA vindt van niet. Ervaring leert ons dat als je teams te veel vrijheid geeft, ze te individualistisch gaan acteren. Om de cohesie tussen de teams te vergroten zijn ‘Special Interest Groups’ nodig om vooral ervaringen met elkaar te delen over verschillende onderwerpen. Daarnaast is er een ‘IT for IT’ team nodig, die alle teams dagelijks kan ondersteunen. Het ‘IT for IT‘ team borgt de architectuur van het totale applicatie landschap.
 

Hoe gaan we testen met de ‘shiftDown approach’?

Voorstel vanuit de WTA is om de testaanpak als volgt te organiseren:

• Technische test
  – Developer
• Verificatie test – bij voorkeur op de API
  – Meer op de core functionaliteit
  – Tester
• Validatie test / Acceptatie – tools als UFT, Trendic, Ranorex, …
  – Past het binnen business processen
  – Tester namens business

 

Welke testomgevingen zijn er bij de ‘shiftDown approach’?

Keken we naar de (test)omgevingen, die nodig zijn, dan viel het ons op dat we uitkwamen bij het wel bekende OTAP model. Dezelfde basisgedachte, maar wel een andere uitwerking.
O – developer machine (tegenwoordig vaak gedockerde omgevingen)
T – gezamenlijke build omgeving van het team
A – de build omgeving van de organisatie
P – productie
 

Afsluitend

De ‘shiftDown approach’ sluit goed aan bij wat de kern van IT is. Leg de verantwoordelijkheid voor de kwaliteit zo laag mogelijk. Doe de testen op het niveau waar dat het beste of goedkoopste kan. Probeer zoveel mogelijk kwaliteit en testen te automatiseren.
Heb daarnaast aandacht voor de integrale kwaliteit van het applicatielandschap. Zorg voor (product)ownership op verschillende niveaus.
 
Schrijvers van dit artikel zijn:
Marcel Oostveen
Maarten Beks
Mustafa Canbaz
Maurice Siteur
Gerben de la Rambelje
Dank aan TrendIC voor het beschikbaar stellen van vergaderruimte voor de WTA.