Testers zijn van nature eigenzinnige ict'ers en je komt ze in alle soorten en maten tegen binnen de projecten. Toch kun je niet alle testers een SOA laten testen of onderdelen van een laten testen. In dit artikel wordt uitgelegd welke soorten testers er zijn en of (en zo ja hoe) ze kunnen worden ingezet bij het testen van een SOA-constellatie
De indeling die in dit artikel wordt gemaakt naar de soorten testers is niet zo zeer naar de rol die zij kunnen vervullen als wel naar waar nu de expertise van de diverse testers ligt. In dit artikel wordt een onderscheid gemaakt naar de volgende testers:
– De traditionele tester.
– De sturende tester.
– De technische tester.
– De procestester.
Dit is een onderverdeling die niet standaard gebruikt wordt in de markt, maar specifiek voor dit artikel wordt gemaakt. Daarom worden ook de rollen eerst toegelicht.
De traditionele tester
De traditionele tester is een tester die grote waarde hecht aan user interfaces en het informatiesysteem stuurt via de gebruikersinterface en zo ook de levenscyclus van de testdata afloopt. Dit soort testers is hierdoor minder geschikt om de afzonderlijke services binnen een SOA-constellatie te testen. Dit soort testers ziet het informatiesysteem als een zwarte doos.
De (aan)sturende tester
De kracht van de aansturende tester ligt in de aansturing en motivatie van mensen. Deze tester voelt zich op zijn gemak in het politieke speelveld van projecten. Het zou aanbevelingswaardig zijn als hij het concept van service oriented architectures snapt en een achtergrond heeft als de technische tester of de procestester.
De technische tester
De technische tester is een tester die een sterke affiniteit heeft met programmeren en testtooling. Dit soort tester bouwt het liefst zijn eigen gereedschappen (stubs, drivers of Mock) en interfaces om stukken programmatuur die 'user interface loos' getest moeten worden, te testen. De technische tester is ook in staat om de programmeur te ondersteunen bij het maken van geautomatiseerde unittesten. Het liefst moet dit soort testers ook verstand hebben van de componenten die in een constellatie een rol spelen: of het nu gaat om de middleware, de database of de ESB.
De procestester
De procestester heeft een sterke affiniteit met de AO/IC en de inbedding van het informatiesysteem in de gebruikersorganisatie. Deze testers hebben de focus op het stroomlijnen van bedrijfsprocessen en kijken waar er optimalisaties te vinden zijn binnen die processen. De procestester heeft daarnaast het liefst ook ervaring met het omvormen van de beschreven processen naar een bedrijfsprocessenmodel of modelleertaal als BPEL.
Testen begint het liefst zo vroeg mogelijk, maar als we kijken naar de testuitvoeringsfase dan onderkennen we vier hoofdtestsoorten:
Unittest (UT) – Hier wordt de kleinst uitvoerbare eenheid van code getest; dit is eigenlijk niets anders dan wat ook gebeurt bij een traditioneel systeem.
Intergratietest (IT) – Hier worden de units geïntegreerd tot een service en getest met behulp van stubs en drivers; bij de integratietest wordt ook voor het eerst het 'formeel geformuleerde' proces met behulp van stubs en drivers uitgevoerd.
Systeemtest (ST) – Hier wordt de constellatie voor het eerst in zijn geheel zonder stubs en drivers getest.
Acceptatietest (AT) – Hier wordt de constellatie in een 'productiesituatie' getest met de focus op 'fit to proces'.
Als je kijkt naar de eerder genoemde testsoorten die worden onderkend en de afzonderlijk geformuleerde testers, dan zie je een overlap ontstaan welke is weergegeven in de onderstaande tabel:
|
|
– |
UT |
IT |
ST |
AT |
|
De aansturende tester |
|
+ |
+ |
+ |
+ |
|
De traditionele tester |
|
– |
– |
+ |
+ |
|
De technische tester |
|
+ |
+ |
+- |
– |
|
De procestester |
|
– |
+ |
+ |
+ |
De aansturende tester heb je nodig gedurende het gehele testtraject, het zou een pre zijn als de aansturende tester affiniteit heeft met het concept SOA.
De traditionele tester gedijt binnen de realisatie van een SOA het beste als de constellatie gerealiseerd/geïntegreerd is, zodat er geen gebruik hoeft gemaakt te worden van stubs of drivers en hij de constellatie als geheel kan beschouwen als een systeem, zodat hij de applicatie kan vullen en 'sturen' via de gebruikersinterface.
De technische tester is een tester die zich thuis voelt binnen het concept van een SOA. Hij heeft echter één valkuil, hij zou zich wel eens kunnen verliezen in het (mooier) maken van zijn tools, waardoor hij eigenlijk nooit aan het testen toe zou kunnen komen. De technische tester gedijt het beste tijdens de UT- en IT-fase van de testuitvoering. In sommige gevallen wanneer er binnen de ST-fase noch gewerkt wordt met stubs of drivers, omdat aanpalende externe systemen nog niet zijn aangesloten, dan kan hij hier ook ingezet worden.
De procestester is een tester die je bijna gedurende het hele testtraject kan inzetten. Zijn focus ligt juist op het verbeteren en optimaliseren van het proces en dit zou je al voor het eerst kunnen testen tijdens de integratietest met behulp van stubs en drivers, in combinatie met BPEL-services of welke andere bedrijfsproces modelleer-service-taal je ook zou gebruiken.
Conclusie
Je kan niet zomaar zeggen dat een tester die een constellatie van services moet gaan testen een soort specifieke tester is. Een tester in een dergelijk traject is eigenlijk een schaap met vijf poten: hij moet verstand hebben van testtooling en het liefst ook zijn eigen scripts/frameworks kunnen bouwen, inzicht hebben in de diverse gebruikte componenten binnen de constellatie en ook nog weten hoe je op papier beschreven processen kan omvormen naar een werkend procesmodel binnen de constellatie. Eigenlijk heb je dus binnen een SOA-traject vooral behoefte aan de technische tester en de procestester in de verschillende testsoorten (zie de verschuiving in de tabel) en minder behoefte aan een traditionele tester.
De toegevoegde waarde van de aansturende tester zit hem vooral in de afstemming met de ketenpartners. De aansturende tester zorgt er voor dat de zijn interfaces aansluiten op die van de ketenpartners en dat het testwerk van de interfaces belegd wordt bij die partijen die verantwoordelijk zijn voor de interface.
De technische tester en de procestester vullen elkaar dus min of meer aan in de manier van testen en de volgorde van testen. Wellicht is dat dan de voorzichtige conclussie die getrokken kan worden als het gaat om wie een SOA-test.
Het zou aanbevelingswaardig zijn als de schrijver van dit artikel de concepten van Service Oriented Architecture en testen snapt.
Dit artikel gaat niet over het testen van SOA, maar over een opsomming van testprofielen. Als de beschreven archetypes in de praktijk zo strict zouden voorkomen, dan is dat wellicht een verklaring voor de hoge kosten van test(deel)projecten.
Een tester die het proces en de context van het systeem kent zal voor zijn te testen deelsysteem toegevoegde waarde hebben. In de praktijk zie je maar al te vaak dat ieder scherm als afzonderlijke eenheid wordt getest.
De link naar SOA wordt niet gemaakt. Het artikel had in dat geval eerst moeten beginnen met wat is SOA en welke testeisen worden daaraan gesteld. Waarom is SOA anders dan andere architecturen? Voor een functionele test niet lijkt mij. Onder de motorkap zijn er verschillen, maar dat maakt voor black box testen niet uit. Ook kan de ontwikkelstrategie (waterval of iteratief) en de manier van documenteren afwijken.
Naar mijn mening kan een SOA alleen maar goed werken als de afzonderlijke componenten goed getest zijn op het moment dat ze aan de SOA toegevoegd zijn. Vanaf dat moment moet men er in een SOA op kunnen vertrouwen dat die componenten getest zijn en werken. Is dit niet het geval, dan is je hele SOA onbetrouwbaar.
Een “SOA testen als ware het een systeem” zie ik echt niet zitten… Dat leidt steeds tot dubbel werk als je een nieuw proces bouwt op je SOA. Voeg je een proces toe, dan test je of het proces goed loopt, wat dan te danken is aan de componenten die dat proces gebruikt. Volgens mij is dat juist het voordeel van hergebruik van services.
Het kan natuurlijk zijn dat de schrijver dit wel bedoelde, maar dan is dit bij mij in elk geval niet helemaal overgekomen.
Tot sluit: Services fungeren in principe juist als een blackbox en dus lijkt een traditionele tester mij uitermate geschikt om losse services te laten testen. Je laat hem weten wat er in moet gaan en wat er uit moet komen en die persoon kan zich uitleven.
Vind dit geen slecht artikel. Bij SOA zijn meer componenten en kleinere teams, maar ook meer teams die zonder UI (headless) werken. Een ander type tester is daarbij gevraagd (voor de uiteindelijke end-to-end test). Tom heeft vermoedelijk verondersteld dat we inmiddels wel een globaal idee hebben wat SOA inhoudt. Toch nog te optimistisch 😉
Vanuit de praktijk kan ik het onderscheid dat hier geschetst wordt voor een groot deel onderschrijven.
Een technische tester zal vooral ook goed moeten kunnen “sparren” met ontwikkelaars en technisch specialisten om inzage te kunnen hebben in de benodigde loggings en inhoud van berichten en database(s).
Een procestester moet in staat zijn op een agile manier met voortschrijdend inzicht, wijzigingen in het procesontwerp en weinig gedocumenteerde specificaties om te gaan.
De traditionele tester kan vooral een rol spelen bij het voorbereiden van testdata in gekoppelde systemen en het uitvoeren van testen vanuit de user interface van bestaande systemen. De ervaring leert dat er tegelijkertijd meer technisch georienteerde testers nodig zijn om de loggings en problemen te analyseren.
Het aansturende aspect zou naar mijn idee – afhankelijk van de grootte van het project en de aanwezige testers -bij iedere tester voor een deel aanwezig moeten zijn en vooral tot uiting moeten komen bij de activiteiten van de testcoordinator en testmanager.