Een informatiesysteem dat is samengesteld op basis van service oriented architecture (SOA) is anders van opbouw dan dat van een monolitisch systeem. Of dit ook implicaties heeft op het beheer van de testinfrastructuur en de uitvoering van testen is nog maar de vraag. In dit artikel probeer ik een antwoord te geven op de vraag of het functioneel testen van een SOA ook echt anders is dan dat van een monoliet.
Architectuur
Een groot misverstand dat heerst onder ict'ers is dat, zodra er gebruik wordt gemaakt van een of meerdere webservices, er dan gelijk sprake is van een service oriented architecture. SOA is een architectuurprincipe dat gekenmerkt wordt doordat de wensen van de business op een minder complexe wijze worden ingepast in de bestaande ict-infrastructuur. Door gebruik te maken van zelfstandige brokken programmatuur (services genoemd) die verwerkingen uitvoeren en andere gelijksoortige of andersoortige services aansturen of er gebruik maken. Dit alles om de doelstellingen van de business te helpen realiseren.
Hierbij dienen de volgende opmerkingen gemaakt te worden:
A) Niet alle services hoeven het eigendom te zijn van de systeemeigenaar.
B) Niet alle services hoeven op één geografische locatie/positie aanwezig te zijn.
C) Een service hoeft niet altijd aangeroepen te worden door een (user)interface. Het kan ook door een andere service gebeuren.
D) Een service heeft altijd één eigenaar. Dit kan een persoon, een afdeling of een systeem zijn. Het hoeft niet altijd het systeem ‘under test' te zijn.
Gestructureerd testen
Voor we verder gaan moeten we het eerst eens zijn over de definitie van testen. In dit artikel hanteren we de volgende definitie:
|
Testen is een proces van plannen, voorbereiden en meten, dat tot doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen de actuele en de vereiste status aan te tonen. |
Testvoorbereiding
De testvoorbereiding bestaat globaal gezien uit twee fasen:
1. Het inrichten van de testomgeving.
2. De analyse van het testobject.
Het inrichten van de testomgeving
In veel organisaties wordt de testinfrastructuur ondergebracht in de OTAP-straat. Hierdoor heeft elke discipline (ontwikkel, test, acceptatie en productie) zijn eigen omgeving en zitten ze elkaar niet in de weg. Bij een SOA is dit niet een eenvoudige zaak. Je zit immers niet alleen met de constellatie van services zelf, maar ook met andere constellatie van services die gebruik maken van dezelfde service en wellicht ook nog de simulaties van services van externe partijen.
Dit kun je doen door gebruik te maken van stubs, drivers of een mock. Als je de mogelijkheid hebt, kun je wellicht ook proberen te ‘praten' tegen de testomgeving van de externe partij. In dat geval is het wel van belang dat er goede afstemming plaatsvindt over het tijdstip. Dit moet worden vastgelegd in een soort service level agreement.
Analyse van het testobject
Risk and requirements based testen (RRBT) is een manier die nu ook al wordt toegepast. Binnen RRBT heeft de productrisico-analyse een prominente plaats gedurende het gehele testtraject. Voor een monoliet is deze analyse alleen gebaseerd op faalkans x schade. Bij een SOA zijn er extra aspecten die moeten worden meegenomen in een productrisico-analyse. Bij een SOA zijn de niet-functionele eisen wellicht nog wel belangrijker dan de functionele eisen. Hierbij kun je denken aan performance, beveiliging en toegankelijkheid. Veel van de aspecten van dergelijke niet-functionele eisen worden vastgelegd in contracten en in specificaties.
In de contracten staat of er beveiliging van toepassing is, welke belasting er toegestaan is en wanneer de service beschikbaar is. In de specificaties is opgenomen uit welke velden de interface bestaat, welke beveiliging wordt toegepast, etc. Je zit dus in de analyse van het testobject al met veel meer afhankelijkheden dan alleen de functionaliteit, ook al ben je functioneel aan het testen.
De risicoanalyse moet dus worden uitgebreid, omdat, bij het bepalen van het risico bij het testen van een constellatie van services, er meer afhankelijkheden zijn dan alleen de faalkans en de schade. Je hebt ook te maken met locatie, complexiteit, hergebruik en beheer.
Afhankelijkheden
Bij de analyse van het testobject heb je niet alleen te maken met de service ‘under test', maar ook met alle aanpalende services of systemen. Een wijziging in een service heeft zelden alleen maar impact op die ene service. Vaak heeft de wijziging op een service impact niet alleen op systeem x maar waarschijnlijk ook op service 2 en systeem y en z. Dit alles is afhankelijk of de service solitair is of niet, met andere woorden wordt een service zowel gebruikt door de systemen x, y en z of hebben deze systemen ieder een eigen versie van service 1? Als een systeem een eigen versie van een service heeft, spreken we over een solitaire service. Als de service niet solitair is, wat in de meeste gevallen zo is, ontkom je er niet aan om naast de testuitvoering van systeem x ook de systemen y en z te testen. Maar wat nu als de systemen y en z niet zitten te wachten op de aanpassing in service 1 door systeem x? Je zit dan met verschillende versies van services die naast elkaar draaien en waarschijnlijk ook terugwaards compatibel met elkaar moeten zijn. De geldigheidsduur van de oude service en de beschikbaarheid van die service voor welke doeleinden dan ook moet worden vastgelegd in service level agreement-achtige documentatie.
Naast een goede analyse van het testobject moet je ook het configuration management van alle configuratie-items op orde hebben.
Testuitvoering
In de testuitvoering heb je niet alleen te maken met de service of het system ‘under test', je hebt ook te maken met de aanpalende systemen. Je moet immers controleren of de wijziging die jij door je systeem laat doorvoeren in een service ook consequenties heeft voor andere systemen in de organisatie of buiten je organisatie.Daarnaast maakt de constellatie van services wellicht gebruik van services die buiten de organisatie zijn ontwikkeld, dan wel buiten de organisatie worden gehost. Voor de dagelijkse gang van zaken moet je controleren of de service aanwezig is. Dit leidt tot ‘continuous testing' tijdens het beheer van de constellatie van services, het doorlopend testen van de software en interfaces in de productiesituatie. Immers, een wijziging in de aanwezigheid/beschikbaarheid van een externe service kan (onbedoelde) consequenties hebben in productie.
Conclusie
Het gestructureerd testen van een SOA verloopt niet heel veel anders dan het testen van een monoliet. Je hebt in beide gevallen te maken met een gefaseerd testproces en in veel gevallen wordt het testen van een monolitische applicatie ook op basis van een risicoanalyse uitgevoerd.
Waar het anders wordt ingevuld is met name in de analysekant van de testwerkzaamheden. Je hebt bij een SOA afhankelijkheden met aanpalende constellatie van services/systemen die je gebruikt of die jou gebruiken om gegevens op te vragen, te verwerken of anderszins. Het testen van een SOA stelt dus niet alleen eisen aan de tester, de testomgeving en het testproces, door invoering van ‘continuous testing' wordt ook aan de beheerkant van het proces de nodige testwerkzaamheden uitgevoerd en verwordt het tot een continu testproject in beheer.
Het stelt ook eisen aan de omgeving waarin de constellatie draait. De testomgeving is uitermate volatiel en oncontroleerbaar. Door afstemming met externe partijen kan een beheerbare situatie worden bereikt. Het is aan de tester om aan te geven welke configuratie conform de specificaties is voor een bepaald systeem, verlies daarbij niet de aanpalende services en systemen uit het oog. De productie-SLA moet wellicht uitgebreid worden tot de testomgevingen.Tot slot: het gestructureerd testen van een SOA is net als een grote puzzel, alleen weet je niet wat je moet maken. Dat biedt een uitdaging voor de tester.
Prima artikel. Duidelijk verhaal.
De conclusies uit dit artikel zijn ons inziens niet helemaal correct:
? De productie-SLA moet wellicht uitgebreid worden tot de testomgevingen ? Het woord ?wellicht? zorgt hier voor verwarring. Door gebruik te maken van de GTA (generieke testafspraken) denkt men na over hoe er getest wordt, wanneer, op welke omgeving, door wie, wie de verantwoordelijke is, etc. Onze mening is dat deze productie-SLA (of: GTA) aanwezig moet zijn om te kunnen spreken van een meer volwassen SOA-testorganisatie.
? Het gestructureerd testen van een SOA is net als een grote puzzel, alleen weet je niet wat je moet maken ? Met de acceptatiematrix en service register, mits correct opgezet en goed onderhouden, moet er voor iedereen inzicht worden gecre?erd in ?de brei van services?. In de acceptatiematrix staat wie er voor de service (of deelobject) verantwoordelijk is. In het service register staat exact welke versie van de service er actueel is. Op een meer volwassen level wordt dit uitgebreid naar afhankelijkheden met andere services, teststrategie?n op diverse levels, testdata en testgevallen.
Het artikel heeft daarnaast wel grote raakvlakken met de SOA testaanpak zoals door Sogeti beschreven. Die aanpak geeft mogelijk meer handvatten voor het invullen van het testen binnen SOA:
Eind 2008 heeft Sogeti een toepassingsvariant op TMap? geschreven voor het testen in een service-oriented architecture (SOA), het TMap? SOA Model.
De belangrijkste uitgangspunten van SOA zijn het realiseren van toenemende kwaliteit van IT, snellere time-to-market en kostenverlaging van IT. Deze uitgangspunten gelden ook voor testen en zijn verwerkt in het TMap? SOA Model. Het TMap? SOA Model bestaat uit drie lagen met daaromheen een cirkel. De cirkel verwijst naar het concept van herbruikbaarheid. Door op alle mogelijke manieren herbruikbaarheid te bewerkstelligen binnen testen, levert testen een bijdrage aan het realiseren van de uitgangspunten van SOA. De belangrijkste gebieden van herbruikbaarheid zijn:
1. herbruikbaarheid van het testproces;
2. herbruikbaarheid van testware;
3. herbruikbaarheid van reeds aangetoonde kwaliteit. Wat je al getest hebt hoef je niet nogmaals te testen.
Deze gebieden van herbruikbaarheid komen terug in de drie lagen. De drie lagen staan voor drie groepen van testoplossingen voor het testen van SOA. De bovenste laag staat voor het maken van Generieke Test Afpraken. Zonder Generieke Test Afspraken begint elk testproject weer opnieuw met het inrichten van het testproces en het maken van testware.
De middelste laag gaat over het toepassen van business driven testmanagement. De business driven testmanagement aanpak van Sogeti heeft een viertal kenmerken. Ten eerste stelt BDTM de opdrachtgever centraal. De testmanager geeft de opdrachtgever invloed op de vier stuuraspecten: resultaat, risico, tijd en kosten. Ten tweede communiceert de testmanager in de taal van de opdrachtgever in de vorm van testdoelen. Het derde kenmerk is dat de testen worden gebaseerd op productrisico?s. Ten vierde maakt BDTM de resultaten van testen zichtbaar voor de opdrachtgever. Twee belangrijke onderdelen die aangepast zijn voor het testen van SOA zijn:
1. het uitvoeren van de productrisicoanalyse;
2. het opstellen van de teststrategie.
Business driven testmanagement voor SOA maakt het mogelijk om risicoverlaging te realiseren afgezet tegen de juiste hoeveelheid geld, tijd en resultaten. Het TMap? SOA Model definieert twee nieuwe testsoorten, de Servicetest en de Service Integratietest.
De onderste laag is de gereedschapskist voor SOA. De drie belangrijkste onderdelen van de gereedschapskist zijn:
1. De acceptatiematrix. De acceptatiematrix geeft inzicht in welke acceptanten verantwoordelijk zijn voor het accepteren van de deelobjecten. Op deze manier heeft de testmanager een krachtig instrument in handen om het acceptatieproces zo vroeg mogelijk te laten beginnen, namelijk bij initi?ren van het project;
2. Het service register. Het service register is het centrale register waar alle beschikbare services worden geadministreerd. Het service register is uitermate geschikt om per service de resultaten van de productrisicoanalyse, teststrategie, en andere testware op te slaan. Alle informatie over het hergebruik van services centraal beschikbaar. Het service register maakt het hergebruik van teststrategie en testresultaten mogelijk;
3. Het SOA testharnas. Het SOA testharnas is een testtool die het mogelijk maakt om een service ge?soleerd te testen op alle mogelijke functionele en niet-functionele eisen. Op deze manier kan in een vroeg stadium van het project een voorlopig kwaliteitsoordeel gegeven worden voor individuele services. Met de oplossingen, zoals beschreven in de drie lagen, wordt herbruikbaarheid van kwaliteit mogelijk.
Meer informatie over deze aanpak is te vinden http://www.tmap.net. Hier staat het whitepaper van Sogeti over het testen in een service-oriented architecture. Het whitepaper over de TPI-variant van SOA staat op http://www.sogeti.nl/Home/Expertise/Testen/tpi_downloads_nl.jsp.
Een heel leuk theoretisch verhaal, maar iemand moet het uiteindelijk ook gaan uitvoeren. Ik hoor weinig over de eisen aan de tester zelf.
Ik ben meer een man van de praktijk. Om SOA lagen, webservices, te testen moet je technisch ingesteld zijn. Bekend zijn met xml’s, wsdl’s en natuurlijk minimaal 3 jaar ervaring met testen en je moet de juiste tools kennen. Wat mij betreft zijn dit Jmeter en soapUI.
Je kan zeker gestructureerd testen, alleen omdat het zeer technisch en onderhevig aan veranderingen is, zijn er vaak aanpassingen aan het script noodzakelijk, waardoor “on the flow” in het beginsel de beste aanpak is. De testcases zelf zou ik alleen in de testtool vastleggen.
Wat betreft de testen zelf. Je moet heldere afspraken maken over de scope (laag/lagen zelf testen of met een deel integratie testen) en de beschikbaarheid van de testomgevingen zijn zeer belangrijk. Integratie is hetgeen waar het allemaal mis kan gaan. Ik zou zeggen succes!
@Rody: je zegt het goed “De conclusies uit dit artikel zijn ons inziens niet helemaal correct” het is wat jullie inziens niet correct is, en vervolgens geef je een goede samenvatting vanuit TMap.
Maar dit wil niet inhouden dat het verhaal incorrect is. Alleen dat jullie een andere visie er op hebben. Het kan misschien werken. Maar met methodieken redt je geen projecten en richt je geen projecten in.
Je wekt de veronderstelling dat BDTM en het roepen dat de klant centraal staat dit ook werkelijk is. Maar een methode wordt niet bruikbaar door te zeggen zo moet het. Je moet kijken wat de klant wilt en dan pas kijken of de aanpak die jij prefereerd een juiste is op dat moment.
Het is belangrijker om te kijken of je de juiste skills aanwezig hebt en of een methode ook de juiste waarde kan leveren voor het project. dit kan nooit een vaststaand gegeven zijn.
Het is goed om verschillende visies naast elkaar te zetten en sfatemmen op de benodigde skills.