Aandachtspunten bij testen SOA-systeem

Op veel plaatsen wordt gesproken en geschreven over het gebruik van service oriented architecture (SOA). Helaas hebben wij gemerkt dat specifieke aandachtspunten voor het testen van SOA in de meeste artikelen onderbelicht blijft. In dit artikel willen we een overzicht geven van onze inzichten in belangrijke aspecten die tijdens het testtraject aandacht moeten krijgen. Want op SOA gebaseerde systemen vergen wel degelijk een andere testaanpak.

Koppelingen

Vanwege de modulaire opzet van een SOA is het testen van de koppelingen extreem belangrijk. Er zijn twee soorten koppelingen, namelijk de koppelingen die binnen hetzelfde project of programma worden gerealiseerd en de koppelingen die door verschillende partijen buiten het project of programma worden gerealiseerd. Het is essentieel dat de koppelingen zowel technisch als functioneel met een hoge testdekking worden getest. Problemen ontstaan vaak in de afstemming van de datacontracten. In de communicatie tussen verschillende partijen wordt dit niet goed afgestemd waardoor koppelingen niet functioneren. Als de koppelingen niet correct werken, kunnen de losse componenten nog zo goed zijn maar werkt het volledige systeem zeker niet. Extra aandacht verdienen daarbij de effecten van wijzigingen, eigendomsverhoudingen, storingsgevoeligheid, netwerkprotocollen en de diverse communicatielagen, omdat deze allemaal invloed hebben op de koppelingen met mogelijke verstoringen van de business tot gevolg.

In de praktijk blijkt dat het testen van de koppelingen binnen hetzelfde project vrijwel altijd te laat de juiste aandacht krijgt. Het is essentieel dat de samenhang tussen de losse modules vanuit zowel ontwikkel- als testperspectief altijd binnen scope blijft en dat er over de koppelingen altijd afstemming blijft tussen aanleverende en afnemende systemen. Het tijdig uitvoeren van reviews op de betreffende ontwerp- en bouwproducten (ook door testers) is dan ook essentieel. Krijg je te maken met partijen buiten het eigen project of programma, start dan vroegtijdig een structurele afstemming waarbij zaken als planning, datacontracten, security en data issues zeker behandeld moeten worden. Er dient rekening te worden gehouden dat lang niet altijd een benodigd systeem beschikbaar is. In een SOA-omgeving is het gebruik en daardoor ook de aanwezigheid van stubs van enorm belang. Zonder de aanwezigheid van dergelijke stubs valt er haast niet te testen.

Een laatste punt rond koppelingen dat we extra willen benadrukken is de aansluiting van een SOA-systeem op systemen die geen SOA-gebaseerde architectuur hebben. Houdt er bij de testen rekening mee dat ook de systeemtechnische en procedurele aspecten ten aanzien van de overgang van SOA naar bijvoorbeeld batchgestuurde systemen vroegtijdig meegenomen worden. Een voorbeeld hiervan is het omvormen van berichten van een SOA-systeem naar een systeem met een batchgebaseerde architectuur. Hoe dit op een goede manier te doen is, is nog relatief onontgonnen gebied.

Non functional requirements

Non functional requirements spelen al vroeg in het traject (ontwikkel- en systeemtesten) een belangrijke rol. In artikelen worden non functional requirements zoals beveiligbaarheid, performance, continuïteit, herbruikbaarheid, schaalbaarheid, onderhoudbaarheid en testbaarheid expliciet aangehaald als requirements die extra aandacht behoeven. Deze requirements moeten al tijdens de eerste testen aan bod komen. Het is daarbij niet zonder meer zo dat het vroegtijdig testen inhoudt dat ze niet in latere testsoorten meegenomen moeten worden. Sterker nog, er zijn meestal veel non functional requirements gespecificeerd die over meerdere componenten heen lopen. Het is dus zaak deze requirements voor zover mogelijk al op componentniveau mee te nemen en vervolgens ook bij de integratie-, keten- of acceptatietesten mee te nemen.

Het gaat te ver om hier alle aspecten ten aanzien van non functional requirements te belichten. Als voorbeeld zoomen we in op beveiligbaarheid. Door de opzet van SOA middels services en bussen is de data in feite door het hele systeem beschikbaar/bereikbaar. Met name op serviceniveau moet al gekeken worden waar en hoe de data voldoet aan de gestelde beveiligingseisen. Denk daarbij bijvoorbeeld aan de beveiliging van de abonnementsstructuur: hoe wordt gewaarborgd dat beveiligde gegevens ook daadwerkelijk alleen gebruikt worden waar het is toegestaan. Dit vraagt ook vanuit test extra aandacht en mogelijk een hogere dekkingsgraad dan meestal wordt gegeven aan beveiliging van data.

In het verlengde van dit punt moet ook voldoende zijn afgedekt, dat data die door het systeem (verkeerd) gemanipuleerd is in zijn oorspronkelijke vorm te achterhalen is zodat herstel mogelijk is. Daarom moeten ook back-up, recovery en rollback in een zo vroeg mogelijk stadium op serviceniveau getest worden. Uiteraard moet de data-integriteit over de losse services heen na een restore of rollback ook getest worden.

Steeds vaker zie je dedicated security frameworks (met security services) verschijnen. Interessant is dat dit soort non-functionals op de markt worden gebracht als een standaard framework en services en dus als geheel al weer een black box zijn. Uiteraard kan een standaard framework het testen op het gebied van beveiligbaarheid vereenvoudigen, omdat de functionaliteit in de black box reeds functioneel is aangetoond. Wel betekent het toevoegen van het framework weer een extra integratie met de bijbehorende koppelingen, die extra aandacht verdienen in het testtraject.

Businessprocessen

Een basisprincipe van een SOA-systeem is dat je de businessprocessen flexibel kunt inrichten op basis van de services. Derhalve is er een directe samenhang tussen services en business processen. Het is daarom noodzakelijk om in een vroeg stadium de betreffende services te testen in combinatie met de business processen die daar bij horen. Gevolg hiervan is dat testers die in een traditionele systeemtest zich vooral moesten bekommeren om de in het systeem(deel) gerealiseerde functionaliteit, nu ook business kennis  moeten  inbrengen. Dit vergt meer afstemming met medewerkers uit de business en daarmee een andere vorm van communicatie dan testers in een systeemtest gewend zijn. Het is goed hierop alert te zijn en bij het selecteren van testers dus nog meer aandacht aan communicatieve vaardigheden en kennis van businessprocessen te besteden.

Testdekking

De testdekking van het volledige systeem is zeer afhankelijk van de gerealiseerde testdekking in de samenstellende services. In tegenstelling tot de meer traditionele architectuurprincipes kun je de testdekking niet bij elkaar op tellen, waarbij de laagste dekking ook ongeveer de dekking van het volledige systeem bepaald. Immers, bij traditionele architectuurprincipes worden gegevens lineair door de opeenvolgende componenten gebruikt. Daardoor wordt de kwaliteit van het geheel bepaald door de zwakste schakel, zeker als de testdekking op de andere componenten beduidend hoger is.

In een SOA-systeem moeten de dekkingen met elkaar worden vermenigvuldigd, omdat iedere service in principe geen directe afhankelijkheid heeft met de andere services. Dus bij een systeem met drie samenstellende services die elk met een dekking van 80 procent worden getest, is de dekking van het volledige systeem ongeveer 50 procent (80 x 80 x 80 procent). Met andere woorden, de testdekking  van de systeemtest voor iedere afzonderlijke service zal waarschijnlijk dicht tegen de 100 procent aan moeten zitten om voor het volledige systeem nog een aanvaardbare dekking te kunnen garanderen. Om de testdekking voor de business functionaliteit in een SOA-systeem met vijf afzonderlijk services op circa 90 procent te krijgen, zal de testdekking voor de afzonderlijke services al 98 procent moeten zijn.

Soap opera testen

Vanwege het feit dat het lastig is alle mogelijke situaties, combinaties en uitzonderingen in het volledige systeem te testen, is het verstandig daarvoor een specifieke aanpak te bedenken. Een goede aanpak is wat ons betreft het testen van gevallen die lijken op een soap opera. Bedenk daarbij een paar real-life scenario's die nog wel door het systeem gehanteerd moeten kunnen worden, maar eigenlijk vooral in een soap opera te zien zijn.

Gebruik van reële data

Bij nieuwe systemen die voor aanvang worden gevuld met geconverteerde data is het zeer belangrijk dat de werking van het systeem ook wordt aangetoond bij het vullen en verwerken van de geconverteerde data. Dit is in ieder systeem belangrijk, maar vanwege de complexiteit in de meeste SOA-systemen is het onze ervaring dat het testen met geconverteerde data in een SOA-systeem niet vroeg genoeg kan starten. Wij raden zeker aan om bij de testen zoveel mogelijk met geconverteerde data te gebruiken of de testdata te fabriceren vanuit geconverteerde data. Daarbij moet ook aandacht worden gegeven aan het al dan niet in de juiste volgorde aanbieden van gegevens en (net als bij alle conversietrajecten) het massaal aanbieden van geconverteerde data leidt tot de correcte berekeningen en databasevulling. Het in een verkeerde volgorde aanbieden van data zal leiden tot het niet correct verwerken van de data met als gevolg dat er extra handmatig werk moet worden verricht.

Regressietesten

Het opzetten en uitvoeren van uitgebreide regressietesten is een absolute must; zodra een service aantoonbaar werkt moeten aanpassingen aan de service zelf en aan andere services die gebruik maken van de betreffende service ook voorzien worden van een regressietest. Daarvoor is het toepassen van geautomatiseerd testen een pre.

Onze ervaring leert, dat het al bij het uitvoeren van de testen goed is na te denken over de regressietesten. Omdat, zoals hierboven gesteld, de testdekking van de afzonderlijke delen zo hoog mogelijk moet zijn, wordt veelal gekozen voor het gebruik van testtechnieken die een hoge dekkingsgraad garanderen. Dit levert voor complexe systemen zeer veel testgevallen op. Het zomaar toevoegen van al deze testgevallen aan de regressietestset maakt deze testset nauwelijks onderhoudbaar en zeker niet snel uitvoerbaar. Daarom kan het een idee zijn om bij het specificeren van testgevallen voor de normale testen ook al te kijken welke testgevallen aan de regressieset toegevoegd zullen worden.

Bij het wijzigen van een businessproces moeten ook regressietesten worden uitgevoerd, vanwege het directe verband tussen de business processen en de services (zie paragraaf Businessprocessen).

Losse punten

In dit artikel hebben we niet geprobeerd volledig te zijn. Naast bovengenoemde punten willen we toch nog kort een aantal ander punten noemen:

– Vanwege de SOA-principes kan het aantal mogelijke combinaties in een samenstel van meerdere services enorm groot worden. Zonder aanvullende maatregelen kan hierdoor de testinspanning buiten proportioneel groot worden. Door de toepassing van risk based testing kunnen daarbij de juiste keuzes worden gemaakt.

– Hoe breder (dus in veel verschillende businessprocessen) een service worden gebruikt, hoe uitputtender deze service getest moet worden. Daarbij zal ook rekening gehouden moeten worden met verwacht gebruik van services in de toekomst. Als een service bij de initiële opzet slechts in één businessproces gebruikt wordt, maar het de verwachting is dat in de toekomst meer processen de service zullen gebruiken, is het verstandig al bij het ontwikkelen van de service met een hoge dekking te testen.

– Het kan voorkomen dat er meerdere versies van services nodig zijn in productie, omdat de diverse afnemende of aanleverende services niet allemaal gelijktijdig de benodigde aanpassingen aan de eigen service in productie kunnen nemen. Ook hier moet in het testtraject aandacht aan worden geschonken.

– De opgebouwde testware moet flexibel kunnen omgaan met wijzigingen in een webservice. Deze zijn vaak nogal onderhevig aan 'changes'. Dit kunnen wijzigingen in berichten betekenen. Door middel van een spreekwoordelijke 'druk op de knop' zou de testware geupdate moeten kunnen worden naar de nieuwe situatie.

Conclusie

Onze conclusie is dat er nog veel te ontdekken is over het testen van SOA-systemen. Naast de in dit artikel genoemde punten zijn er nog veel meer punten die in het testtraject aandacht verdienen. Het is belangrijk dat alle testers in het traject zich bewust zijn van de aanpak en specifieke kenmerken van het ontwikkelen van een SOA-systeem en de mogelijke gevolgen die dit heeft voor het testtraject. We dagen onze collega's daarom uit om ervaringen te blijven verzamelen, deze zoveel mogelijk te delen en gezamenlijk het testen van SOA-systemen snel naar een hoog niveau te brengen met de specifieke aandachtspunten die zo'n systeem vereist.

Dit artikel is geschreven samen met Camiel Wieme en Freddy de Weerd van Capgemini. Met dank aan Theo Punter (Bartosz ICT) en Maurice Siteur (Capgemini) voor het lezen en becommentariëren van dit artikel.