Infoworld

We hebben drie personen ondervraagd over het testen van Service Oriented Architecture (SOA): een trainer, een leverancier en een SOA-gebruiker. Randy Rice is een vooraanstaand auteur, spreker en consultant op het gebied van software-testen en software-kwaliteit. Randy's onderneming biedt trainingen in SOA-testing aan. Frank Cohen is auteur en oprichter van PushToTest, een onderneming die open source testsoftware levert. Jim Giddings heeft de laatste jaren aan verschillende SOA-initiatieven gewerkt.

Wat zijn de belangrijkste gevolgen van de opkomst van SOA voor testen?
Randy stelt dat de "toegankelijkheid van diensten" of de "stuurloze aard van de diensten" nieuwe uitdagingen creëert voor testers. Testers zullen veel diensten moeten testen zonder de hulp van user interfaces en ze moeten rigoreus testen om deze diensten te valideren. Randy zegt dat het testen van diensten hem herinnert aan de uitdagingen bij het testen van drivers waarbij test-frameworks nodig waren.

Frank noemt dat de diensten "altijd beschikbaar" zijn, wat heel anders is dan de n-tier architectuur waarbij "jij de controle hebt". Met SOA heb je diensten die andere diensten aanroepen en in deze wereld van mash-ups hebben testers niet altijd de kennis over hoe deze diensten gebruikt zullen gaan worden. Schaal en uitvoering staan ook hoog op Franks lijst van uitdagingen.

Jim zegt dat je verschillende testcycli moet verwachten, net zoals bij Agile-projecten, en dat een door testen aangestuurde omtwikkelingsmethodologie moet worden ontwikkeld. Net als zijn collega's noemt Jim de stuurloze aard van de diensten en de performance-testen.

Hebben testers de vereiste technische vaardigheden om SOA te begrijpen?
Randy benadrukt het belang van solide technische kennis. Hij stelt dat testers vanuit verschillende gebieden van de onderneming komen (business, ontwikkeling enz.) en dat ze niet noodzakelijkerwijs de juiste vaardigheden hebben voor SOA. Hij benadrukt ook de noodzaak van oriëntatie op bedrijfsprocessen, wat hij "het vergeten terrein van het testen" noemt. Testers die alleen op de technologie focussen, missen de bedrijfsprocedurele kant. Testers die niet op de business gericht zijn hebben vaak ook geen toegang tot de juiste business-mensen.

Frank wijst erop dat testers beginnen te coderen en codeschrijvers beginnen te testen. Testgedreven ontwerp heeft deze verandering in rollen en verantwoordelijkheden gecreëerd. Als je testers hebt die niet kunnen coderen, wordt het een uitdaging. Een ander punt van Frank is dat de gewone methodes van 'opnemen-en-afspelen' niet werken bij SOA en dat frameworks nodig zijn. Testers moeten leren hoe ze daarmee moeten werken, wat vraagt om codeschrijven.

Jim meldt dat veel testers SOA gelijkstellen aan Web Services en dat ze niet het hele terrein van de architectuur begrijpen. Niet alle testers zijn technisch genoeg om "te graven in de architectuur zoals die is geïmplementeerd". SOA vraagt meer dan alleen ‘black-box-testen'. Jim zegt dat SOA een combinatie vereist van zwart, wit en grijs testen omdat er "zoveel gebeurt op iedere laag" van de architectuur.

Welke tools zijn noodzakelijk om SOA te testen?
Randy noemt een aantal tools, waaronder SoapUI en ITKO's Lisa product als twee test-tools die zodanig zijn vormgegeven dat ze testers structurele toegang tot diensten geven. Hij zegt dat sommige bestaande tools uitgebreid kunnen worden, maar niet naar het niveau dat vereist is om effectief SOA te testen.

Frank stelt dat test-tools voor SOA je in staat moeten stellen platform-neutraal te ontwikkelen. De tools zouden bijvoorbeeld de tester moeten toestaan de test-leidraad van de ontwikkelaar te nemen en deze uit te breiden door functioneel te testen. Frank's bedrijf heeft Testmaker Pro gebouwd, een open source tool die testers voorziet van een framework zonder dat ze nieuwe talen als Groovy of Jython moeten leren.

Jim benadrukt het belang van uitvoeringstesten en ook hij beveelt ITKO's Lisa aan om proxy-diensten te volgen en het pad van aangeroepen diensten te detecteren. Bij sommige SOA-implementaties hebben architecten de neiging om veel proxies op te leveren voor hun diensten.