We werken steeds meer in organisaties met agile teams waarbinnen alle benodigde expertises voor productontwikkeling voorhanden zijn. Testers maken onderdeel uit van de teams en brengen hun testexpertise in. Werkzaamheden die buiten de teams plaatsvinden, hebben die expertise echter ook nodig. Zo staan systeemintegratie en ketenacceptatie vaak niet op de teamsprintbacklogs. Organisaties hebben nog maar zelden een centrale testorganisatie, dus hoe vindt testexpertise dan zijn weg naar teamoverstijgende werkzaamheden? Ruim baan voor de Test Architect!
Het testen van de code tot en met het testen van een systeem gebeurt meestal binnen een agile ontwikkelteam. Een oplossing voor een probleem van de organisatie wordt echter zelden door een enkel systeem geleverd, dus zijn er ook tests nodig van samenstellingen van meerdere systemen. De verschillende systemen moeten met elkaar integreren tot een groter geheel. Het valt voor ontwikkelteams echter niet mee om het gezamenlijk testen met andere systemen te organiseren. Zo lukt het lang niet altijd om de ontwikkeling van beide kanten van een integratie in dezelfde sprint te plannen vanwege tegenstrijdige belangen of door technische beperkingen. Het team dat eerder klaar is, verliest de focus na de afronding van de sprint en moet op een later moment herstarten wanneer inmiddels aan andere dingen wordt gewerkt. De sterke focus op het eigen systeem werkt eilandjeskennis in de hand. Een team weet veel van het eigen systeem, maar weinig van de systemen waarmee moet worden geïntegreerd. Die kennis is echter wel nodig voor een integratietest, waardoor het organiseren van een gezamenlijke test vanuit een van de teams niet makkelijk van de grond komt. De realisatie van een testomgeving met alle betrokken systemen is ook een team-overstijgende taak, welke nog wat verder af staat van de dagelijkse werkzaamheden van een ontwikkelteam. Voor het aanvullen van de teamcentrale testtaken met teamoverstijgende testtaken hebben organisaties testexpertise nodig. Dat vraagt om ervaren testspecialisten met een breed profiel!
Dit leest als het takenpakket van de centrale testafdelingen van organisaties in het pre-agile tijdperk. Er is wel een groot verschil, want veel testwerk dat destijds in de centrale testafdeling plaatsvond, zoals de functionele systeemtest, vindt in de teams zelf plaats. Wat overblijft zijn centraal te organiseren testwerkzaamheden die het toneel vormen voor een veelzijdige tester: de Test Architect.
De Test Architect is een zelfstandig opererende testspecialist die verschillende registers moet kunnen opentrekken. Het vraagt om een multidisciplinaire, cross-functionele testspecialist met testmanagementvaardigheden, die zelf ook (geautomatiseerde) tests uitvoert. Het bepalen van de aanvullende teststrategie en het organiseren van de teamoverstijgende testwerkzaamheden zijn typische testmanagementtaken. De Test Architect beschikt niet zoals de testmanager in het pre-agile tijdperk over een vast eigen team van testers. Voor het testen van de integratie van systemen stelt de betrokken Test Architect steeds een gelegenheidsteam samen van testers of ontwikkelaars uit de teams die de systemen ontwikkelen. Voor een E2E acceptatietest bevat zo’n gelegenheidsteam ook mensen die de rol van acceptatietester vervullen.
Naast het regelwerk, over welke vaardigheden moet de Test Architect nog meer beschikken? We pikken er een paar uit, om te beginnen met de uitvoering van de testanalyse voor de systeemintegratie. Hiervoor duikt de Test Architect in de koppelingen tussen de systemen die met elkaar integreren: wat is de techniek van de koppeling, hoe ziet de syntax er uit en voor welke functionele werking zijn de systemen van elkaar afhankelijk? Op die drie niveaus moeten tests worden gedefinieerd in samenwerking met leden van de betrokken teams.
Moderne koppelingen tussen systemen zijn geïmplementeerd als API’s, die je dus makkelijk kunt benaderen met testtools. Dat brengt me bij het volgende register: testen en wel enigszins technisch via API’s. De Test Architect wil ook zelf kunnen beoordelen of de betrokken systemen goed reageren op de eigen API. Vooral erg nuttig als de ontwikkeling van het ene systeem voorloopt op die van het andere system: dan kan de Test Architect toch alvast integratierisico’s verkleinen. Hierbij worden bijvoorbeeld de bekende tools Postman of soapUI gebruikt. Beschikt de Test Architect over voldoende testautomatiseringvaardigheden, dan kan het testen op de API ter voorbereiding op de systeemintegratie geautomatiseerd worden, bijvoorbeeld in een java framework met restAssured. Die automatisering kan ook erg nuttig zijn om de systemen snel in een startsituatie te krijgen voor specifieke integratie- of acceptatietests.
Het regelen van de testactiviteiten in de gelegenheids-testteams rond de systeemintegratie en acceptatie is een vorm van testcoördinatie die we nog kennen van de pre-agile testafdelingen. De kennis van zaken en structuur die de Test Architect inbrengt, zorgt voor gezag bij de betrokkenen. Het opbouwen van goede contacten is van groot belang, want de Test Architect heeft geen hiërarchische functie ten opzichte van de leden van de ontwikkelteams die moeten bijdragen aan de teamoverstijgende testactiviteiten en de acceptatietesters.
Een laatste voorbeeld van benodigde vaardigheden die we eruit lichten is rapportage. De staat van de teamoverstijgende testwerkzaamheden is een belangrijke graadmeter voor vrijgave. De Test Architect wijst de organisatie op openstaande risico’s, ontbrekende testdekking en nog aanwezige problemen. Hardcore testmanagement.
Binnen het merendeel van de organisaties is een essentiële rol weggelegd voor een Test Architect met een breed pallet aan vaardigheden en ervaring die zorg draagt voor het dichten van gaten in de testdekking die overblijven als de agile teams hun eigen tests hebben uitgevoerd. Om deze teamoverstijgende testtaken, zoals de systeemintegratietest en de end-to-end acceptatietest, tot een goed einde te brengen, is een capabele Test Architect hard nodig!
Kees Blokland, test architect.
