shiftDown approach voor de Software Delivery Pipeline

Redactie: Gerben de la Rambelje

Auteur: Werkgroep Testautomatisering TestNet
TestautomatiseringDinsdag 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:

shiftDown approach

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.

5 comments on “shiftDown approach voor de Software Delivery Pipeline
  1. Egbert Bouman schreef:

    Hoi vakbroeders, leuk verslagje. Ik had even de hoop dat jullie gingen vertellen waar integratietesten en CI in de testpiramide passen. Ik zie CI steeds meer verweven met UT en CT als 1 geheel van ontwikkelaarstesten. Waarmee onderkant en middenlaag van de piramide 1 laag zijn geworden.

    Hoe zien jullie dat?

  2. Maarten beks schreef:

    Ik denk niet dat we als entiteit hier één antwoord op hebben, maar ik wil jullie mijn persoonlijke mening niet onthouden.

    Wat betreft CI
    Vanuit een testautomatiserings perspectief zie ik CI enkel en alleen als een middel om een geautomatiseerde test aan te roepen.
    Of terwijl: CI is afhankelijk van testautomatisering, maar testautomatisering niet van CI. In die zin is het maar de vraag of een verwevenheid op zijn plaats is

    Wat betreft Integratietesten
    Welke definitie wordt hier met Integratietesten bedoeld? Ik kan op verschillende niveaus integratie testen uitvoeren. Zo kan ik op technisch gebied integreren (unit integratietesten), maar zal ik ook de integratie tussen bijvoorbeeld microservices, of nog breder tussen applicaties kunnen testen.
    Alle deze vormen van integratietesten kunnen we automatiseren, maar vallen wel binnen een ander punt in de piramide.

    • Egbert schreef:

      Hoi Maarten, Bedankt, dat is wel helder inderdaad. Ik zie de onderkant van de piramide als unit testen plus unit integratietesten. Liefst op een CI server. CI zit minimaal op dat niveau, maar kan ook hoger in de piramide zitten inderdaad.

  3. Maurice Siteur schreef:

    Continuous integration is something the agile teams do. You could go even a level higher.
    For me the test automation pyramid tells something about test automation and less on where to do integration testing.
    The ultimate goal is to automate most/all of our tests. The pyramid tells me to do tests as low as possible (even like TMap).
    And there is not one answer on where to do what. Listen to your project and try to test as low as possible and to automate as much as possible. Those two principles are the basis for every choice we make.

  4. Maurice Siteur schreef:

    Sorry voor het Engels, maar na jaren heel veel in het Engels gedaan te hebben, lees ik Nederlands zelfs als Engels.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *