De Kijk van Kees: warme overdracht

Auteur: Kees Blokland ●  Kees.Blokland@Polteq.com
Redactie: Paul Beving

Je hoort me wel, maar versta je me ook? Je verstaat me wel, maar begrijp je me ook? Systemen lijken misschien kille machines, maar ook zij werken pas goed samen nadat er warme overdracht van informatie plaatsvindt.

Twee systemen die informatie uitwisselen moeten elkaar om te beginnen kunnen horen. De ietsje ouderen onder ons herinneren nog het gepiep van de internetmodems: de data werd daadwerkelijk omgezet in hoorbaar geluid en via de telefoonlijn binnen de bandbreedte van 300Hz en 3400Hz overgedragen. Het testen dat systemen elkaars gegevens ontvangen, is natuurlijk een eerste vereiste bij een systeemintegratietest. Een eerste 200 OK als respons op het eenvoudigste verzoek dat je kunt bedenken geeft opluchting dat de eerste horde is genomen: er is verbinding! Vooraf kunnen de nodige hobbels zijn overwonnen, zoals nukkige kabels, systeemconfiguraties en firewalls. Problemen die meestal door technici kunnen worden opgelost. Als de verbinding er is, dan kunnen we verder.

Als de bits overgestuurd zijn, dan komen we bij de volgende testhindernis die moet worden genomen: spreken de systemen dezelfde taal waardoor de uitgewisselde gegevens herkenbare informatie wordt? Voor de tester wordt het nu een stuk interessanter. Wat zijn veelgebruikte ‘zinnen’ die de systemen met elkaar moeten uitwisselen? Die vormen een eerste set van interessante validatietests. Dan gaan we de grenzen opzoeken van wat systemen als geldig beschouwen. Met andere woorden, tot waar begrijpt een systeem nog wat het andere systeem zegt? Voor de Nederlandse taal hebben we het Groene Boekje waarin alle geldige woorden op een rij staan. Met een beetje geluk hebben we iets vergelijkbaars als basis voor onze systeemintegratie, zoals Open API specificaties (swagger.io), xml-schemas, json-schemas of iets in tekstvorm. Met hulp van bekende technieken, zoals grenswaardenbepaling en indeling in equivalentieklassen, ontwerpen we tests waarmee we de taalgrenzen van de betrokken systemen gaan verkennen. We richten ons vooral op de syntax van de gegevensuitwisseling. Tools die we voeden met de specs kunnen als arbiter fungeren: voldoen ontvangen berichten aan de specificaties en accepteert het ontvangende systeem berichten die zijn afgeleid uit de specificaties? Voorbeelden van typische problemen zijn: type mismatches, veldlengteproblemen, missende velden, niet verwachte null-waarden, versieproblemen van specificaties, allemaal op te lossen door de systeemontwikkelteams. Als deze tests met een OK eindigen, dan weet je dat de systemen elkaar verstaan. Maar we zijn er dan nog niet.

Ik ben namelijk pas tevreden als de systemen elkaar ook begrijpen. Dus hoe wordt de taal geïnterpreteerd? Zie je dat het ontvangende systeem de juiste conclusies trekt en de juiste acties uitvoert op basis van de ontvangen informatie? Raakt het ontvangende systeem niet functioneel in de stress? Testgevallen die je hiervoor maakt, rieken al naar ketentesten, maar je kijkt nog even niet verder dan het deel van de keten dat deze twee systemen invullen. Welke afhankelijkheid hebben de systemen van elkaar en voor welke business logica hebben ze elkaar nodig? Het soort problemen dat je hiermee detecteert, is velerlei. Niet zelden moeten ontwerpen opnieuw tegen het licht worden gehouden omdat niet meteen duidelijk is hoe en waar de oplossing moet worden gezocht. Door voldoende ver de systemen in te kijken, test je de warme overdracht van informatie: het sluitstuk van de systeemintegratietest.

Als je begrijpt wat ik bedoel.