Waarom integratietesten bepalen wat er misgaat na livegang
Een integratie is een verbinding die records verplaatst tussen twee systemen die nooit ontworpen zijn om met elkaar te communiceren. Een bestelling in een Adobe Commerce-webshop moet in SAP aankomen als iets wat de financiële afdeling kan factureren. Een voorraadcijfer in SAP moet de webshop bereiken voordat een klant iets koopt dat niet meer op voorraad is.
Integratietesten controleren of deze uitwisseling standhoudt voordat er echte bestellingen worden verwerkt. Het lijkt op gewoon softwaretesten met meer bewegende delen, maar de meeste van die delen zijn van iemand anders.
Wanneer een team dit overslaat, is de IT-afdeling niet de eerste die het merkt. Het magazijn merkt het, de servicedesk merkt het en de financiële afdeling merkt het aan het eind van de maand:
- Een bestelling die de flow nog nooit heeft gezien: een creditnota of een deellevering bereikt SAP in een vorm die de mapping niet verwacht. De flow stopt en die klant wordt niet gefactureerd totdat iemand het opmerkt
- Een voorraadfeed die stilletjes faalt: de webshop toont de beschikbaarheid van gisteren gedurende twintig minuten, en orderpickers zoeken naar artikelen die al verkocht zijn
- Een marktplaats die een veld heeft gewijzigd: Amazon begint een attribuut te vereisen dat de productdata nooit meestuurde, wijst de aanbiedingen af en de producten verdwijnen uit het kanaal
- Een piek waar niemand rekening mee hield: een flow die getest is op tien bestellingen per uur krijgt er vierduizend te verwerken op de eerste grote verkoopdag en loopt vast, waarbij de bestellingen in een wachtrij staan waar niemand toezicht op houdt
Niets hiervan is exotisch. Elk van deze scenario's had vooraf getest kunnen worden. De meeste teams proberen dit niet, omdat de helft van de betrokken systemen niet van hen is om mee te experimenteren.
Waarom integraties niet getest kunnen worden zoals gewone software
De sandbox van de leverancier bestaat misschien niet. Als die er wel is, bevat deze mogelijk data van drie jaar oud die in niets lijkt op wat er nu draait. Sandbox-testen tegen een omgeving die afwijkt van de live-omgeving bewijst minder dan het lijkt.
Integraties veranderen ook de situatie wanneer ze worden uitgevoerd. De eerste test maakt de order aan, gebruikt een nummer uit een reeks of verplaatst de voorraad, waardoor dezelfde test niet zomaar opnieuw kan worden uitgevoerd. Herhaling betekent dat de systemen moeten worden gereset, wat meestal onmogelijk is, of dat er telkens nieuwe gegevens moeten worden gegenereerd. De condities die het meest de moeite waard zijn om te testen, zijn ook de condities die niemand toestaat. Een leverancier haalt zijn systeem niet offline zodat het team de foutafhandeling kan testen. Een vervoerder zal op verzoek geen API vertragen. Die paden worden gesimuleerd of overgeslagen.
Eén conditie kan nooit worden getest. Een leverancier kan een veld wijzigen zonder iemand in te lichten, en die wijziging heeft nog niet plaatsgevonden wanneer het testplan wordt geschreven. Om dit op te vangen, heeft het team monitoring en loggingnodig. Testen bewijst een proces vóór de livegang. Monitoring vertelt het team daarna wat het live verkeer ermee doet. Alles daartussen hangt af van één ding: of de testomgeving dicht genoeg bij de productieomgeving lag om betrouwbaar te zijn.
Waarom de testomgeving het struikelblok is voor integratietesten
Het meeste werk bij systeemintegratietesten gaat zitten in de omgeving, niet in de tests zelf. Waar elke verbinding uit maatwerkcode bestaat, betekent een testomgeving het draaien van een tweede kopie van die code, gekoppeld aan de beschikbare sandbox-omgevingen van leveranciers, en synchroon gehouden met de productieomgeving terwijl beide kanten veranderen.
Dat onderhoud is de reden waarom testomgevingen gaan afwijken. De versie die wordt getest komt niet meer overeen met de versie die draait, en de tests bewijzen niets meer.
Het configureren van de stromen op één gedeelde integratielaag lost dat probleem op. Dezelfde stroomdefinitie draait in beide omgevingen. Het wijst naar test-endpoints in de ene en live-endpoints in de andere, en alleen de configuratie verschilt. De sandbox-omgevingen van de leverancier worden er niet beter op, maar het team stopt met het implementeren van iets anders dan wat het heeft getest.
Teams gaan hier tegenwoordig op drie manieren mee om. Ze bouwen een volledige parallelle omgeving, wat grondig is maar duur om actueel te houden. Ze testen in productie met zorgvuldig gekozen records, wat werkt totdat het gekozen record cruciaal blijkt te zijn. Of ze simuleren elk extern systeem, wat snel is maar alleen test wat het team aanneemt dat de leverancier zal sturen. Een Integration Platform-as-a-Service (iPaaS) is de vierde optie, en de enige die het omgevingsprobleem wegneemt in plaats van eromheen te werken.
Hoe een integratieplatform integratietesten ondersteunt
Een iPaaS is één platform waar elk systeem één keer verbinding mee maakt, in plaats van dat ze direct met elkaar verbonden zijn. Het bevat de stromen die gegevens tussen systemen verplaatsen en transformeren. Omdat elke stroom op één plek staat, kan een team deze naar test-endpoints of live-endpoints laten wijzen zonder iets opnieuw te hoeven bouwen.
Dat maakt vier dingen mogelijk op het Alumio integratieplatform:
- Eén stroom, twee omgevingen: dezelfde geconfigureerde stroom draait tegen test-endpoints in een testomgeving en tegen live-endpoints in productie, waardoor het team precies implementeert wat het heeft gecontroleerd
- Detail op berichtniveau: het Alumio iPaaS legt vast wat elk bericht bevatte en waar het vastliep, zodat het team de werkelijke fout herstelt in plaats van te gissen
- Opnieuw afspelen: Opslag binnen het Alumio iPaaS bewaart die berichten, zodat een gecorrigeerde stroom opnieuw kan worden uitgevoerd tegen de order die de fout veroorzaakte
- Gecontroleerde promotie: versiebeheer en gefaseerde uitrol zorgen ervoor dat wijzigingen bewust naar productie worden gebracht, in plaats van door aanpassingen te doen in de live omgeving
Het Alumio iPaaS biedt ook een Inspectietool. Deze toont de input en output van elke transformatiestap naast elkaar, zodat een team een specifiek onderdeel van een flow kan testen zonder de volledige integratie uit te voeren. Deze functionaliteiten werken voor elke flow op dezelfde manier, waardoor de testmethode van de eerste integratie direct herbruikbaar is voor de volgende.
Wat eerlijk integratietesten een bedrijf oplevert
Volledige dekking is onhaalbaar; een testplan dat uitgaat van het tegendeel is ofwel oneerlijk, of wordt nooit voltooid. Het nuttige doel is een heldere lijst: welke paden het team grondig heeft getest, welke slechts zijn gesimuleerd en welke helemaal niet konden worden bereikt. Een team dat weet welke paden ongetest zijn, kan deze specifiek in de gaten houden en snel handelen. Dat is beter dan in de waan verkeren dat alles getest is.
Een integratieplatform maakt het mogelijk om die lijst bij te houden. Het plaatst de flow die wordt getest en de flow die wordt uitgerold op dezelfde plek, houdt een logboek bij van wat elk bericht heeft gedaan en stelt je in staat om een correctie te controleren aan de hand van de specifieke order die voor problemen zorgde.
Het bedrijf profiteert van livegangs met minder verrassingen, fouten die verklaard kunnen worden op basis van een logboek in plaats van achteraf reconstructie, en het vertrouwen om een gekoppeld systeem te wijzigen zonder dat dit als een projectrisico wordt gezien.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
