Ketenintegratie speelt momenteel binnen bedrijven en overheden. Organisaties koppelen informatiesystemen meer en meer aan elkaar. Als meerdere systemen met elkaar worden verbonden, groeit het belang van testen. Niet alleen het testen van de afzonderlijke systemen is van belang; vooral de ketentest, ook wel de integratie- of ‘end-to-end’ test genoemd, is onontbeerlijk.
Er bestaan verschillende redenen voor het aaneenschakelen van informatiesystemen. Allereerst zijn veel organisaties voor de uitvoering van hun bedrijfsprocessen afhankelijk van gegevensaanlevering door andere organisaties. Ketenintegratie kan aanlevering en verwerking van gegevens efficiënter laten verlopen. Ten tweede bieden technologische ontwikkelingen op het gebied van internet nieuwe mogelijkheden om systemen aan elkaar te koppelen, zoals bij internetbankieren het geval is.
Kostenbesparing is een derde reden om ketenintegratie toe te passen. Een voorbeeld hiervan is het Ictal-programma (ict en administratieve lastenverlichting) van het ministerie van Economische Zaken. Dit programma moet de administratieve lasten van bedrijven verlagen door de inzet van ict. Bedrijven leveren hun gegevens eenmalig aan, waarna deze op een centrale plaats worden geregistreerd en bijgehouden. Deelnemers aan het programma kunnen dan meervoudig gebruik maken van deze gegevens en het is niet langer nodig om op diverse plaatsen grotendeels overlappende registraties bij te houden. Dit programma moet de regering in totaal zeventien miljard euro opleveren. Ten vierde is ook de tendens van uitbesteding en het oprichten van ‘shared service centers’ meer en meer aanleiding tot systeemintegratie.
Bij systeemintegratie is het van belang dat er, naast het testen van de afzonderlijke informatiesystemen, ook een ketentest plaatsvindt. Deze heeft als doel inzicht te geven in de kwaliteit van vooral de afstemming van gezamenlijk gebruikte specificaties en de ingerichte infrastructuur. Dit artikel geeft de ketentestmanager, de opdrachtgever en de programmamanager een aantal handreikingen voor het succesvol uitvoeren van een ketentest. Zowel de inhoudelijke als de zakelijke kant komen aan bod. Deze handreikingen helpen de valkuilen die vaak met een ketentest gepaard gaan voorkomen en zorgen ervoor dat die test effectief en efficiënt kan worden uitgevoerd.
Kostbare risico’s
Wanneer twee of meerdere informatiesystemen aan elkaar gekoppeld worden, moet er een ketentest plaatsvinden. Het testen van de afzonderlijke informatiesystemen is ook belangrijk, maar het uitvoeren van een ketentest is noodzakelijk om te bepalen of de gehele keten juist werkt. De ketentest beperkt zich niet tot één applicatie of platform maar overschrijdt meerdere applicaties en platformen. Deze kunnen zich binnen één organisatie bevinden of over meerdere organisaties en fysieke locaties verspreid zijn.
Geïntegreerde systemen zorgen ervoor dat steeds meer gebruikers hun dagelijks werk afhandelen met hetzelfde systeem. Als er bij invoering of aanpassing van zo’n systeem zaken misgaan, brengt dit een steeds groter en potentieel kostbaar risico met zich mee. De ketentest biedt een organisatie zekerheid over de werking van het systeem en een goede kwaliteitsbeoordeling van de nieuwe of aangepaste systeemintegratie. Het uitvoeren van een ketentest voorkomt dus dat er achteraf grote kosten ontstaan door herstelacties. Als de ketentest wordt overgeslagen, is het onmogelijk te bepalen of de gehele keten goed werkt.
Omdat organisaties steeds meer systemen aan elkaar koppelen zal een ketentest steeds vaker als hertest worden uitgevoerd. Bij bestaande ketens is een hertest noodzakelijk indien er aanpassingen in afzonderlijke onderdelen van de keten, zoals de interfaces zijn.
Stappenplan
Bij de ketentest volgen we een stappenplan. De eerste stap betreft de strategie. Bij het koppelen van informatiesystemen is samenwerking noodzakelijk. Dit begint al bij het uitzetten van de opdracht. Vaak krijgen de betrokken deelsystemen opdracht tot het realiseren van een (deel)applicatie. ‘Iedereen’ weet dan dat het uiteindelijk de bedoeling is een samenwerkend systeem te realiseren, maar men vergeet de opdracht te geven tot de feitelijke aaneenschakeling. Bovendien zijn er vaak verschillende opdrachtgevers bij de systemen betrokken en is het onduidelijk wie de verantwoordelijkheid heeft voor de koppelingen tussen de systemen. In die situatie bestaat de kans dat er op zich prima functionerende systemen gerealiseerd worden die niet kunnen samenwerken met de aanpalende systemen.
Bij ketenintegratie is het dus noodzakelijk dat er een heldere, overkoepelende opdracht wordt gegeven, waarin de uitgangspunten duidelijk beschreven staan. Alle partijen moeten weten wat er van hen verwacht wordt. Een uitgangspunt bij de ketentest is bijvoorbeeld dat de betrokkenen moeten kunnen aantonen dat hun eigen deelsysteem functioneel is getest. Dan kan de ketentest zich bezighouden met het testen van de afstemming van de specificaties en het testen van de infrastructuur. Als aan deze voorwaarde niet voldaan wordt, ontaardt de ketentest veelal in een functionele test.
Verder moet de opdracht voor de ketentest duidelijk afgebakend zijn. Het moet voor de opdrachtgever duidelijk zijn wat wel en wat niet wordt meegenomen. Het komt in de praktijk voor dat allerlei zaken die feitelijk niets met de ketentest te maken hebben erbij betrokken worden. Vaak gaat het dan om zaken die de opdrachtgever belegd wil hebben, maar waarvan hij niet goed weet waar dit te doen. Voorbeelden hiervan zijn het schrijven van het implementatieplan en de afstemming van de specificaties: de ketentester toetst of de afstemming en implementatie van de specificaties correct is, hij stemt deze niet zelf af. De afstemming moet al in een veel eerder stadium gebeurd zijn.
Miscommunicatie
De ketentest verdient de volledige aandacht van een onafhankelijke ketentestmanager, die bij voorkeur een eigen mandaat heeft. Dit mandaat geeft de mogelijkheid om te sturen op mijlpalen en afspraken waaraan de deelnemende partijen zich hebben gecommitteerd. Zonder mandaat kan de ketentestmanager alleen kennis nemen van eventuele verschuivingen in planningen. Let wel: het mandaat betreft hier enkel de sturing op afspraken voor de ketentest. De ketentestmanager is niet verantwoordelijk voor de afzonderlijke ontwikkelopdrachten van de betrokken projecten.
Sturingsproblemen zijn ook te voorkomen door de ketentestmanager direct te laten rapporteren aan de algemeen projectmanager of de programmamanager. Zo houdt deze het overzicht op de gehele keten, en kan hij in geval van uitloop van de ketenintegratietest delen van het project dechargeren. De geschikte persoon voor het uitvoeren van een ketentest is dus niet alleen tester. Een ketentestmanager heeft bij voorkeur ook ervaring met projectmanagement en goede procesvaardigheden. Hij werkt namelijk veelal in een spanningsveld van diverse organisaties en afdelingen met verschillende belangen.
Communicatie is een ander punt dat aandacht vereist. Betrokkenen kennen elkaar vaak niet of nauwelijks doordat ze op verschillende locaties werkzaam zijn of de mensen wisselen of ingehuurd worden. Van miscommunicatie is dan al snel sprake. Gezamenlijke bijeenkomsten met alle partijen in de vorm van stuurgroepen of task forces zijn goede middelen om het gemeenschappelijke belang voorop te stellen. De stuurgroepen kunnen op reguliere basis bijeenkomen om de voortgang van de ketentest te bespreken. Daarnaast is het belangrijk dat de ketentestmanager ook op andere momenten blijft communiceren. Bij langlopende opdrachten kan het enthousiasme en het inzicht in het belang van de opdracht vervagen. De ketentestmanager kan dit voorkomen door dat belang te blijven benadrukken en waar nodig als intermediair te functioneren tussen betrokken partijen.
Ten slotte is ook de testomgeving een punt van aandacht. In een ideale situatie wordt voor de ketentest een omgeving ingericht die identiek is aan de productieomgeving. De ketentestmanager hoeft er dan alleen voor te zorgen dat de omgeving op tijd is ingericht en dat de betrokken projecten tijdig hun programmatuur ernaar overzetten. Het komt echter regelmatig voor dat de verschillende acceptatie- en exploitatietestomgevingen aan elkaar geknoopt worden. In dat geval moet je oppassen met de uitspraken die je aan de hand van de ketentest doet.
Sneeuwbaleffect
Stap twee betreft de planning en fasering. De ketentestmanager moet zich ervan verzekeren dat alle betrokken projecten en organisaties een afgestemde opdracht hebben. De betrokken projecten moeten daarnaast een planning voeren voor het ontwikkelen van hun deelsysteem. De ketentestmanager moet deze planningen kennen, zodat hij de integrale planning voor de ketentest kan opzetten. Deze integrale planning is een vereiste. Hij moet vroegtijdig worden gemaakt om knelpunten in de verschillende ontwikkeltrajecten voor te zijn.
Wanneer meerdere in- of externe projecten bij de ketentest zijn betrokken, is de kans op uitloop groot. Onderzoek wijst uit dat slechts 12 procent van projecten succesvol (onder andere ‘op tijd’) afgerond wordt. 31 procent is gedeeltelijk succesvol en 51 procent faalt (onderzoek Standish Group). Wanneer één project uitloopt, krijgen andere opdrachten en prioriteiten invloed op de planning van de ketentest en ontstaat een sneeuwbaleffect. Vooral bij de ketentest is dat het geval omdat alle schakels aan elkaar gekoppeld zijn en een keten zo sterk is als zijn zwakste schakel. De planning voor de ketentest moet dus ruim worden opgezet.
Indien meerdere partijen bij de ketentest zijn betrokken of de te testen keten complex is, is het verstandig om een fasering aan te brengen in de planning. Je kunt bijvoorbeeld besluiten om de systemen na elkaar te laten aansluiten. Let er hierbij wel op dat een bepaalde onafhankelijkheid wordt ingebouwd. Idealiter ondervinden aan te sluiten systemen geen hinder van de vertraging van een ander systeem bij de ketenintegratie. Ook is het verstandig de begrotingen van de betrokken projecten voor de ketentest in de planning mee te nemen. Op deze manier wordt voor de opdrachtgever inzichtelijk wat de ketentest uiteindelijk in totaal heeft gekost.
Overzicht
De derde stap betreft de testvoorbereiding. De gecreëerde samenwerking gaat door in de ontwikkelstraat. Afstemming tussen de betrokken projectorganisaties op de disciplines ontwerp, bouw en test is continu noodzakelijk. Hiervan is niet altijd sprake. Vaak beperkt men zich tot de interfaces, de direct zichtbare raakvlakken. Er wordt niet altijd gedacht aan de afspraken op het niveau van de gegevenshuishouding: het ene systeem ‘begrijpt’ misschien prima wat het andere ‘zegt’, maar wat als de inhoud niet correct is? Verder verdienen ook de zaken die niet geautomatiseerd zijn aandacht. Een voorbeeld is de verzending van een brief aan een klant. Ook dit moet in de ketentest worden meegenomen; het is immers onderdeel van de keten.
Tijdens de testvoorbereiding moet ook het bevindingenbeheer ingericht worden. Vaak worden bevindingen in de ketentest geregistreerd in de bevindingentool van het onderdeel waar de fout is geconstateerd. Dit bemoeilijkt het overzicht over het totale aantal bevindingen in de ketentest. Om snel een oplossing aangereikt te krijgen voor bevindingen die van invloed zijn op het bedrijfsproces van één van de deelnemers kan je een forum oprichten waarin van alle betrokken deelnemers een opdrachtgever of afgevaardigde is vertegenwoordigd. Zo’n forum zorgt er ook voor dat iedereen op de hoogte is van de status van de ketentest en van de eventuele knelpunten.
Stap vier betreft de testuitvoer. Voor de ketentester is dit het moment suprème. De voorbereiding voor de uitvoering van de test is (arbeids)intensief geweest. Dan breekt het moment aan waarop alle deelnemende partijen klaarstaan om de ketenintegratie in de praktijk te brengen. Mocht er iets mis gaan, dan kan de ketentestmanager door de gedegen voorbereiding en de gecreëerde samenwerking de betreffende specialisten aan het werk zetten.
Het is verstandig om de keten eerst in zijn simpelste vorm te testen: denk aan pingen of het uitwisselen van één bericht (heen en terug). Kortom, test of de keten technisch conform verwachting functioneert. Vervolgens kan je beginnen met het afwerken van de met de betrokken partijen afgestemde testset.
.
Visualisatie
Als vijfde volgt de testrapportage. Ook rapportage is een onderdeel binnen het ketentesttraject dat speciale aandacht verdient. De ketentestmanager heeft, samen met de betrokken projecten, een integrale planning opgesteld die aanstuurt op de datum dat de gehele keten getest wordt. Hij heeft op deze manier te maken met de voortgang van alle betrokken projecten en is vaak als eerste op de hoogte van de actuele stand van zaken en onverhoopte vertragingen bij één van de betrokken partijen. Tenzij anders is afgesproken, is de ketentestmanager echter niet verantwoordelijk voor de voortgang van de verschillende projecten uit de keten. Daarom moeten goede afspraken gemaakt worden over rapportage van de ketentestmanager aan de programmamanager of algemeen projectmanager. Er bestaan diverse rapportagevormen waarbij een visualisatie van de keten wordt gebruikt. In de rapportage wordt dan bijvoorbeeld met behulp van verschillende kleuren aangegeven wat de status is van een deeltraject binnen de totale keten.
Iedereen heeft vroeger wel eens het spelletje gespeeld waarbij je in een kring zit, een persoon een woord verzint, dat in het oor van de buurman of -vrouw fluistert enzovoort. Wanneer de kring rond was, was het uiteindelijke woord meestal niet gelijk aan het origineel. Bij complexe ontwikkeltrajecten gaat dat vaak nog steeds zo. Bij dergelijke trajecten is het uitvoeren van een ketentest de enige manier om te waarborgen dat een eindproduct wordt opgeleverd waarvan de opgeleverde componenten uit de keten op elkaar zijn afgestemd.< BR>
Jacolien Vukkink, Thomas Som, testconsultants Capgemini Nederland
