De verbindende factor
De definitie van een integratietest op Wikipedia lijkt heel duidelijk: de integratietest is een softwaretest waarbij individuele softwaremodules verbonden worden en als een geheel getest worden. Maar wie wat beter naar deze zin kijkt en met het bijltje gehakt heeft, ziet direct dat het zo simpel niet is. Wat wordt bijvoorbeeld precies bedoeld met modules? Zijn dat modules binnen hetzelfde testobject of bedoelt men verschillende systemen binnen een netwerk? Of allebei? Moeten we in dat kader SAP S/4HANA zien als een applicatie of meer in de oude module opbouw, die het ERP pakket van oorsprong kent? De vragen die deze definitie oproept, zijn kenmerkend voor het integratietesten zelf. En dan vooral het testen tussen verschillende applicaties. Wat ons betreft zitten juist daar de uitdagingen. In de huidige migratiegolf naar SAP S/4HANA houden integratietesten de testmanagers regelmatig uit hun slaap.
In een waterval situatie is integratietesten lastiger dan in een agile setting. Het repeterende karakter van de sprints en de behapbare brokken die worden opgeleverd, maken dat integratietesten overzichtelijker wordt en daardoor beter beheersbaar. Maar zelfs daar zijn er nog de nodige uitdagingen. In deze blog richten wij ons op de agile context.
Verantwoordelijkheid
Het kenmerk van een integratie is, dat er een zender en ontvanger is. Wie is wanneer nou verantwoordelijk voor het gezamenlijk testen van de integratie? Je hebt immers twee of meerdere teams, waar een wijziging van de interface (zonder deze is er geen integratie) impact op heeft. In onze visie neemt de zender het heft in handen. Dit houdt meestal in, dat er in de applicatie van de zender een wijziging plaatsvindt, die voor de ontvangende partij ook tot een aanpassing in hun omgeving leidt. Of in ieder geval tot regressietesten. In de definition of ready kan een ontwikkelteam een geheugensteuntje opnemen of er voor een user story afstemming met een ander team nodig is.
In de situatie dat er meerdere agile teams actief zijn, die een afhankelijkheid met elkaar hebben door integraties, biedt het Scaled Agile Framework (SAFe) uitkomst. Tijdens planning events kijken alle betrokken teams ruim van tevoren naar op te leveren features/epics en de onderlinge afhankelijkheden. Zo komt het verzoek van een zender om een wijziging te testen voor de ontvanger veel minder vaak als een verrassing.
Testomgevingen
Integratietesten is een belangrijk aspect van ketentesten. Dan blijkt immers pas of een schakel van integraties voor een bepaald bedrijfsproces werkt zoals het de bedoeling is. Ketentesten vinden doorgaans plaats op de acceptatie-omgeving. Daarom, en om heel veel andere redenen, is het goed de “A” zoveel mogelijk production-like te laten zijn.
Maar integraties wil je natuurlijk eerder testen. Dan moeten wel de integraties op de verschillende omgevingen te testen zijn. Maar voor je het weet, steken teams veel energie in het geschikt maken van de “T” voor de integratietesten, zonder dat het wat toevoegt. Een van de belangrijkste oorzaken daarvoor, is dat ontwikkelstraten van verschillende teams zelden gelijk aan elkaar zijn. Bij de een ontbreekt de “T” of bij de ander is de “T” juist wel weer als een productieomgeving ingericht. Een oplossing voor dergelijke issues, is om te werken met virtual end points. De beste oplossing is echter de ontwikkelstraten van de teams uit een keten op dezelfde manier in te richten. Zo simpel kan het soms zijn.
Leveranciers
Worden de wijzingen aan een van de applicaties door een externe leverancier gedaan, dan komt er een behoorlijk complicerende factor bij. Wijzigingen aan interfaces kunnen dan zomaar onaangekondigd op productie verschijnen. Standaard software-oplossingen zijn in het gunstigste geval door-en-door getest. Maar in een keten waarin verschillende pakketten aan elkaar zijn geknoopt, vergeet men de integraties toch te snel. Een leverancier die daarvoor de verantwoordelijkheid voelt, is helaas de positieve uitzondering op de regel. Een gebrekkige en moeizame communicatie, een niet goed doordachte SLA en bevindingen maken het allemaal nog complexer.
Elk van de drie issues kan een stuk dieper worden uitgewerkt. Daar is in deze blog helaas geen ruimte voor. Hopelijk biedt het wel voldoende stof tot nadenken. En mocht u vervolgens willen sparren over het integratietesten, zoek dan gerust verbinding met PTWEE. Een van onze testconsultants kan in het diverse en soms onoverzichtelijke landschap de partijen bij elkaar brengen en zorgen dat ook de integraties goed getest worden.
