Ketentest is de gouden schakel bij het testen

Bij het ontwikkelen van nieuwe systemen is er vrijwel altijd sprake van interfaces met andere systemen. Vaak betreft dit ook organisatorisch verschillende afdelingen. Het integreren van een systeem met andere systemen en werkprocessen is een complexe en foutgevoelige taak. Ketentesten, ook bekend als end-to-end testing, doorlooptest en systeemintegratietest, is de testsoort die hiervoor wordt gebruikt.

Een ketentest wordt gedefinieerd als een test waarbij een of meer bedrijfsprocessen worden doorlopen over een aangesloten reeks van systemen en platforms. Dit om te controleren of de processen en systemen op de juiste manier geïntegreerd zijn en een werkend geheel vormen. Ketentests kunnen vaak pas op het eind van het traject worden uitgevoerd. Hierdoor leidt vertraging in tests vrijwel zeker ook tot vertraging van het totale project.

Gekoppelde systemen

De integratie van een systeem met andere systemen kan verschillende redenen hebben. Het is een gegeven dat veel organisaties, voor de uitvoering van hun bedrijfsprocessen, afhankelijk zijn van gegevensaanlevering door andere organisaties of systemen. Ketenintegratie kan hierbij helpen door de aanlevering en verwerking van gegevens efficiënter te laten verlopen. Ook de doorbraak van internet heeft nieuwe mogelijkheden gecreëerd om systemen aan elkaar te koppelen. Naar een winkel toe gaan om iets te kopen behoort tot het verleden. Je kunt nu met de komst van internet vanaf je bureau winkelen en vervolgens afrekenen. Het afrekenen kan bijvoorbeeld via iDeal plaatsvinden. Je rekent dan snel en gemakkelijk af in de vertrouwde internetbetaalomgeving van je eigen bank.

Als we het testen van ‘gekoppelde systemen’ bedoelen, hebben we het hier over een ketentest. Een ketentest voer je dus uit, wanneer er twee of meer informatiesystemen zijn die aan elkaar gekoppeld zijn. Deze gekoppelde systemen zullen behalve afzonderlijk getest, ook in samenhang met elkaar getest worden. Het testen hoeft niet altijd om functionaliteit te gaan, maar kan ook andere aspecten raken. Zo gelden voor het ene bedrijfsproces misschien andere acceptatiecriteria dan voor het andere. In dit geval zal het uitvoeren van een ketentest een duidelijk inzicht geven van de kwaliteit van vooral de afstemming van gezamenlijk gebruikte specificaties en de ingerichte infrastructuur.

Noodzaak van een ‘ketentest’

De ketentest is noodzakelijk om te beoordelen of de gehele keten juist werkt. Zoals ik hiervoor al beschreven heb is het een bekend gegeven dat steeds meer organisaties afhankelijk zijn van gegevensaanlevering door andere organisaties of systemen. Hierbij zien we dat deze organisaties de ketentest als hertest uitvoeren. Bij bestaande ketens is een hertest noodzakelijk indien er aanpassingen in afzonderlijke onderdelen van de keten, zoals de interfaces, zijn. Bij ketenintegratie is het dus noodzakelijk dat er een heldere, overkoepelende opdracht wordt gegeven, waarin de uitgangspunten duidelijk beschreven staan. Een uitgangspunt bij de ketentest is bijvoorbeeld dat de betrokkenen moeten kunnen aantonen dat hun eigen deelsysteem functioneel is getest. Dan pas 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. 

De opdracht voor de ketentest zal duidelijk omschreven moeten zijn. Het moet voor de opdrachtgever en tester duidelijk zijn wat wel en wat niet wordt meegenomen tijdens het testen. Zo komt het in de praktijk regelmatig voor dat allerlei zaken die feitelijk niets met de ketentest te maken hebben erbij betrokken worden. Dit zijn dan vaak 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.

Vastleggen van afspraken

Door een goede afsprakenset tussen ketenpartners wordt de onafhankelijkheid van de eigen processen zoveel mogelijk geborgd. De invloed van andere ketenpartners op de eigen organisatie wordt hiermee sterk beperkt. In de praktijk blijkt dat, met name in ketenprojecten waarbij een aantal organisaties betrokken zijn, de ene organisatie veel eerder ‘klaar’ is dan de ander. Dit heeft veelal te maken met verschillende gebruikte ontwikkelmethoden van ketenpartners, verschillende projectgroottes en/of verschillende infrastructuren. Gegevensuitwisseling op basis van communicatiestandaarden en gebruik makend van ketenvoorzieningen, belooft in principe een reductie van de onderlinge afhankelijkheid tussen ketenpartners. Maar voordat deze belofte kan worden ingelost zien we dat in ketentesten de afhankelijkheid juist enorm toeneemt, met alle kosten en fricties die daarmee gepaard gaan. Tevens geldt dat naarmate er meer ketenpartners deelnemen, de kans van daadwerkelijk optreden van de risico´s groter wordt met een eveneens groter wordende impact op de uiteindelijke doorlooptijd van het ontwikkelproces. 

Het is cruciaal  om in ketentesttrajecten gebruik te maken van een voorziening waarmee ketenpartners, onafhankelijk van elkaar, kunnen bepalen of aan gemaakte afspraken is voldaan en de gegevensuitwisseling naar behoren gaat werken.

Gebruik van hulpmiddelen

Om de beschreven problematiek omtrent afspraken het hoofd te bieden, moet gezocht worden in de richting van het terugbrengen van de afhankelijkheden. Dit is bijvoorbeeld mogelijk door in de ontwikkelingsfase en de testfase van de projecten gebruik te maken van een simulator voor berichtenuitwisseling, waarmee de verschillende systeemontwikkelingtrajecten zoveel mogelijk ontkoppeld worden. Deze simulator oftewel test-stub vervangt een nog ontbrekende (sub)module en reageert net als het ontbrekende gedeelte. Hierdoor is de communicatie met het nog ontbrekende stuk toch te testen. De afhankelijkheid van de ketenpartners onderling wordt door de inzet van stubs sterk verkleind, waardoor alle aandacht gericht kan worden op de ontwikkeling en het testen van de eigen organisatie en bijbehorende ict-ondersteuning.

Conclusie

Het uitvoeren van een ketentest voorkomt dat er achteraf grote kosten ontstaan door herstelacties.  Test-stubs kunnen een belangrijke rol vervullen in het reduceren van afhankelijkheden bij het organiseren en uitvoeren van ketentesten. Dit wordt met name bereikt door het ontkoppelen van de verschillende systeemontwikkelingtrajecten en het bieden van eenzelfde ontwikkel en testbasis met deze testsimulator. Gebruik van een dergelijke simulator voor het ontwikkel- en testproces neemt niet weg dat er uiteindelijk toch een ‘echte’ ketentest met de betrokken ketenpartners moet worden uitgevoerd. Echter, naast de voordelen in het voortraject – eerder ontdekken van fouten, afstemmingsproblemen en het oplossen daarvan – zal de echte ketentest een substantieel kortere doorlooptijd kennen en minder fouten bevatten. Dit resulteert in substantieel lagere kosten voor betrokken ketenpartners.