Nut en noodzaak van de ketentest
ERP software zoals SAP en Salesforce wordt gebruikt om bedrijfsprocessen te beheren en te automatiseren in ondernemingen van groot tot klein. Toch staat een ERP-systeem (vrijwel) nooit op zichzelf, maar is deze via interfaces verbonden met aan ‘de voorkant’ bijvoorbeeld een webshop en aan ‘de achterkant’ bijvoorbeeld rapportagesoftware. Soms zelfs zijn er externe partijen (andere ondernemingen of overheden) verbonden aan een ERP-systeem waarmee gecommuniceerd moet worden. Vaak testen we in de sprint deze interfaces functioneel door middel van stubs en mocks waarbij we de input simuleren en de output uit het ERP systeem valideren.
Bovenstaand schema is een sterk vereenvoudigde weergave van hoe een dergelijke keten van systemen eruit kan zien. De pijlen representeren berichtenverkeer dat het ERP-systeem in en uit gaat.
Om het aantal afhankelijkheden te minimaliseren en de voortgang van het scrumteam niet te vertragen wordt het berichtenverkeer van en naar het ERP-systeem binnen de sprint getest met gesimuleerde berichten via een tool zoals SoapUI. Zo blijft de ontwikkeling onafhankelijk van andere systemen binnen en buiten de eigen organisatie en kan bij elke sprint review een demo van het opgeleverde increment worden gegeven aan de relevante stakeholders. Als de aanleverende partijen berichten aanleveren zoals afgesproken en de ontvangende partijen hun kant van de systemen conform afspraak heeft ingericht ontstaat er een werkelijke keten die een geheel proces (vaak omschreven als klantreis) omvangt.
De praktijk lijkt echter weerbarstiger. Aansluitcontracten worden verschillend geïnterpreteerd, wijzigingen worden niet (voldoende) afgestemd, ook met de beste intenties van alle betrokkenen gaat er bovendien weleens wat mis. IT is en blijft toch uiteindelijk mensenwerk!
Alleen dit al is voldoende reden om samen met de counterparts van het ERP-systeem een testomgeving te creëren met werkende koppelingen en op zijn minst de keten ook daadwerkelijk een keer te testen vanuit het bronsysteem naar het doelsysteem of de doelsystemen.
Hoe past een ketentest binnen Agile Scrum?
Ketentesten bij Feature teams in een Agile omgeving
Wanneer er binnen de organisatie gewerkt wordt in zogenaamde Feature Teams die Agile/Scrum ontwikkelen en er geen externe partijen betrokken zijn, kan de ketentest in de Definition of Done (DoD) worden opgenomen en binnen de sprint getest. Hiernaast is schematisch weergegeven hoe featureteams zich verhouden tot het IT-landschap binnen een organisatie. Binnen het team is kennis aanwezig over alle systeemlagen en betrokken systemen. Het team is hierdoor in staat een functionaliteit of wijziging over de gehele keten te implementeren en te testen.
Het is dan ook een voor de hand liggende keuze om, als er wordt gewerkt in Feature Teams, ketentesten binnen de spint uit te voeren en deze aan de stakeholders te presenteren als onderdeel van Sprint Review. Immers is de implementatie over de gehele keten de beste representatie van de klantwaarde van het opgeleverde increment.
Ketentesten bij Layer teams in een Agile omgeving
Veel vaker dan in Feature Teams wordt binnen complexe organisaties gewerkt met Component Teams of Layer Teams, zoals schematisch is weergegeven in onderstaande afbeelding.
Doordat een team zich richt op slechts één systeem of één laag uit het systeemlandschap is het mogelijk om binnen een klein Scrumteam multidisciplinaire gespecialiseerde kennis te bundelen. Bijvoorbeeld Business Analyse, functionele consultants, Software Engineers en Testers die allen op hun eigen terrein gespecialiseerd zijn. In tegenstelling tot een organisatie die werkt in Feature Teams worden er in dit geval door verschillende teams aan delen van de functionele ketens gewerkt waarbij het niet vanzelfsprekend is dat ze op hetzelfde moment opleveren aan één en dezelfde functionaliteit. Überhaupt zal een ketentest bij het werken volgens dit model team overstijgend zijn, omdat allen een eigen stukje van de keten opleveren en hiervoor verantwoordelijk zijn. Dit betekent uiteraard niet dat een ketentest hiermee onmogelijk is. Waar ontwikkelingen in verschillende systeemlagen bij elkaar komen is het juist belangrijk om aan te tonen dat de ontwikkelingen in de verschillende lagen van het systeem op elkaar aansluiten en gezamenlijk een functionaliteit opleveren.
De ketentest; een gezamenlijke verantwoordelijkheid van alle teams!
Om de kwaliteit te borgen is het essentieel om de gehele keten constant te (blijven) testen. Elke aanpassing in een van de onderdelen van de keten kan immers impact hebben op (één of meerdere) andere onderdelen van diezelfde keten. Als er sprake is van een organisatie met teams gespecialiseerd in specifieke systeemlagen is het, hoewel organisatorisch gecompliceerder, wel aan te raden om ketentesten als onderdeel van de sprint op te pakken om zo snel mogelijk hiaten in de kwaliteit van de totale keten te onderkennen en hierop te kunnen acteren.
"De ketentest is een estafette waarbij de testers de stappen en controles uitvoeren die binnen hun aandachtsgebied (vanuit het team) liggen."
Natuurlijk helpt het als de teams die betrokken zijn bij de waardeketen regelmatig afstemmen en onderling proactief en open communiceren. De ketentest kan worden benaderd als een estafette, waarbij de testers van de verschillende scrumteams die stappen en controles van het testscript uitvoeren die binnen hun aandachtsgebied (vanuit het team) liggen.
Dit estafette principe waarbij verschillende testers een aantal stappen oppakken en de test daarna overdragen (en misschien later nog eens terugkrijgen voor andere stappen) kan ook uitstekend worden gebruikt in een organisatie met Feature Teams, waarbij ketentesten gebaseerd zijn op klantreizen. Een klantreis kan namelijk meerdere functionaliteiten (features) raken en dus ook in deze organisatiestructuur team overstijgend zijn.
Of een organisatie werkt met feature teams of layer teams is een afweging die voor elke organisatie anders kan uitvallen. Door in feature teams te werken voorkom je afhankelijkheden tussen teams bij het realiseren van bepaalde functionaliteit. Een risico hiervan is echter dat meerdere teams tegelijk aan eenzelfde systeemlaag of component aanpassingen doen die elkaar raken. Een feature team heeft een totaalverantwoordelijkheid voor een stuk functionaliteit dat moet werken binnen het bedrijfsproces. Integratie is hierin vanzelfsprekend en de ketentest zal over het algemeen soepeler verlopen, omdat de verantwoordelijkheid voor een (deel)functionaliteit in zijn geheel bij één team is belegd. Wel is er een groter risico op regressie omdat meerdere feature teams tegelijk mogelijk in dezelfde code aanpassingen doen, allemaal gericht op de eigen functionaliteit.
Bij het werken in layer teams blijven de aanpassingen binnen één systeemlaag binnen één scrum team, waardoor het afstemmen van de verschillende wijzigingen binnen één systeemlaag makkelijker af te stemmen en controleerbaar is. Er is dan ook een kleiner risico op het optreden van regressie bij layer teams.
Door het risico op regressie en de verantwoordelijkheid over een groter deel van het systeemlandschap, vraagt het werken in feature teams meer vakvolwassenheid en systeemkennis van de testers om afhankelijkheden te kunnen inschatten. Zolang er aan deze voorwaarden wordt voldaan verdient het werken in feature teams de voorkeur om binnen een complexe omgeving een functionele keten te kunnen realiseren en te testen. Dat is het leveren van waarde waar we allemaal naar streven, niet waar?
PTWEE helpt bedrijven met Enterprise Software systemen zoals SAP en Salesforce beter en slimmer te testen met een pragmatische aanpak. Deze blog is opgesteld door Sander, SAP Testconsultant bij PTWEE. Heeft u behoefte om vrijblijvend van gedachten te wisselen over uw testuitdagingen? Neem dan contact met ons op.
