De kerngedachte achter soa is dat de afzonderlijke verwerkende eenheden met elkaar communiceren zonder dat de wijze waarop gecommuniceerd wordt vast ligt. Dit alles met de gedachte dat het uiteindelijke systeem de business moet ondersteunen in het primaire proces.
Als tester heb je de gereedschapskoffer vol zitten met methoden en technieken, die je kunnen ondersteunen bij het opstellen van de testgevallen. Bij het testen van een soa krijg je te maken met heel andere uitdagingen dan bij een monoliet of een client/server applicatie:
1. Business is eigenaar van het proces
2. Hergebruik van de service
3. De afwezigheid van een GUI
4. Locatie en de beschikbaarheid van de service
Business is eigenaar van proces
De business moet door en de business brengt het geld binnen. Hier moet ict zich naar schikken. Ict is ondersteunend aan de business en dat is altijd zo geweest. Toch heeft ict de afgelopen jaren geprobeerd de vraagstukken van de business op te lossen vanuit de techniek. Waar dat toe heeft geleid, hebben we de afgelopen jaren mee kunnen maken. De soa-gedachte is dat de business leidend wordt in het oplossen van de vraagstukken en dat ict daar de middelen voor heeft om dit te ondersteunen. Doordat de business eigenaar is van het proces, zul je als tester dus ook veel meer te maken krijgen met de business. De business wil onafhankelijk van de architectuur een werkend systeem. De nadruk zal dan komen te liggen op de non-functionele eisen van een systeem zoals beschikbaarheid, betrouwbaarheid en interoperabiliteit.
Hergebruik van service
Een specifieke service, bijvoorbeeld het checken van de geldigheid van een bankrekeningnummer, kan voor meerdere doeleinden worden gebruikt. Enerzijds kan deze service gebruikt worden bij het uitgeven van bankrekeningnummers, anderzijds kan deze zelfde service ook onderdeel zijn van het valideren van een betaling. In beide gevallen wordt de geldigheid van een bankrekeningnummer gecontroleerd en veelal in beide gevallen heb je te maken met een ander proces of systeemeigenaar. Wat nu als de service ten behoeve van het proces van uit te geven bankrekeningnummers gewijzigd wordt, moet je dan als regressietest alle processen hertesten die de service gebruikten of hertest je alleen de services die de gewijzigde service aanroepen? Ook hier heb je te maken met de non-functionele eisen van een systeem, compatibiliteit.
Daarnaast zijn veel services al eerder gerealiseerd door andere partijen en veelal zijn de interfacespecificaties van die services beschikbaar op het net. Want waarom zou je zelf het wiel opnieuw uitvinden als anderen dat al voor je hebben gedaan en de service beschikbaar stellen voor gebruik?
Afwezigheid van user interface
Een groot deel van de services zal zich nooit manifesteren met een gebruikersinterface, toch zul je als tester deze moeten onderwerpen aan een test. Hiertoe kun je gebruikmaken van de keten, maar je kunt ook gebruikmaken van stubs en drivers of de expertise van een ontwikkelaar. Door zelf je tests te ontwikkelen en deze al in een vroeg stadium door de bouwer uit te laten voeren, maak je de service robuuster. Dit heeft als voordeel dat de tester kan doen waar hij goed in is, het vinden van fouten en de ontwikkelaar kan doen waar hij goed in is, het bouwen van een service. Indien er geen documentatie aanwezig is, kan de testspecificatie zelfs dienst doen als ontwerpdocument.
Locatie en beschikbaarheid van service
Binnen een soa hoeft een service niet per se op de locatie van de opdrachtgever te draaien. Sterker nog, veel van de aan te roepen services zullen zelfs buiten de landsgrenzen draaien. Toch wil de business maximale zekerheid als het gaat om de beschikbaarheid van de services. De vraag die dan beantwoord moet gaan worden is hoe we ervoor kunnen zorgen dat we die beschikbaarheid kunnen garanderen. Het antwoord op deze vraag is het maken van bindende afspraken in de vorm van service level agreements (sla's) tussen de afnemer en de provider van de service.
Conclusie
Het testen van een soa is anders dan het testen van een client/server applicatie of een monoliet. Bij een soa zal de nadruk komen te liggen op de non-functionele eisen van een systeem, daar waar bij een 'standaard' systeem veel meer de nadruk ligt op de functionaliteit. De functionaliteit van een soa staat of valt met een juiste samenhang van services en het is dus van groot belang dat de tester de bedrijfsprocessen van de business kan doorgronden. Hiertoe zal zijn gereedschapskoffer met zijn standaard methoden en technieken niet voldoende zijn om een soa op een juiste wijze te testen.
