Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Non-functionele eisen belangrijk bij testen SOA

08 augustus 2008 - 18:004 minuten leestijdOpinieCloud & Infrastructuur
Tom Langerhorst
Tom Langerhorst

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.

Meer over

ArchitectuurSOA

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Beveiliging begint bij de Server

    Waarom lifecycle-denken cruciaal is voor IT-security

    Computable.nl

    Bouw de AI-organisatie niet op los zand

    Wat is de afweging tussen zelf bouwen of het benutten van cloud?

    Computable.nl

    Slimme connectiviteit: de toekomst van bouwen

    Hoe stoom jij jouw organisatie in de bouw en installatie sector klaar voor de digitale toekomst?

    Meer lezen

    Filter
    OpinieCloud & Infrastructuur

    Ddos-aanvallen (en waarom L3-filtering niet optioneel is)

    Handen, samenwerken, fusie
    ActueelOverheid

    Meer regie en samenwerking bij digitalisering overheid

    ActueelGovernance & Privacy

    Microsoft: we zijn geen hulpsheriff

    ActueelCloud & Infrastructuur

    HPE-Juniper vormt blok tegen Cisco

    OpinieCloud & Infrastructuur

    Opkomst van soevereine clouds: stel dataportabiliteit centraal

    knop op toetsenbord met rolstoelsymbool
    ActueelOverheid

    Einde aan wildgroei van overheidswebsites

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Uitgelicht

    Partnerartikel
    AdvertorialInnovatie & Transformatie

    Ontdek de toekomst van IT-support en m...

    Op 16 september 2025 vindt in de Jaarbeurs in Utrecht een gloednieuw event plaats dat volledig is gericht op IT-professionals:...

    Meer persberichten

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine
    • Topics

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs