Veranderingen binen het testersvak als gevolg van de Cloud. (Whitepaper van Leo Schijns, Senior Test Specialist bij Calco te Maarssen)

Inleiding. Het vak van tester is duidelijk aan het veranderen. Deze whitepaper geeft mijn visie weer over dit item. Opzet van dit document is een voorstelling te geven van hoe de omgevingen er uit zien van eerst de conventioneel gebouwde applicaties, daarna de zogenaamde op het web gebaseerde applicaties en vervolgens een uitgebreide visie over de Cloud. Als tester heb ik 70 % gebruik gemaakt van de TMap en TMap Next methodologie , deze methoden geven een mogelijke benadering van een testtraject en in een later stadium meer vanuit bedrijfsoogpunt met een Product Risico Analyse. Ik zal dan ook kort op gebruik van TMap in relatie tot Cloud testen beschrijven en iets over het geautomatiseerd testen. Tot slot een eindconclusie waarin de eventuele aanvullende competenties worden weergegeven die een tester zal moeten bezitten (of moeten verbeteren) bij het testen van een Cloud.

Van toen naar heden…..

1. Conventionele applicaties

Sinds meerdere jaren ben ik bezig met het testen van software, laten we zeggen binnen het OSI meer-lagen- model (n lagen) met de opgeleverde te testen software in een testomgeving die identiek is aan de productie omgeving . Binnen het OSI model wordt met Laag 0 vaak de bekabelingen bedoeld en Laag 8 de gebruiker. Dit kon zijn middels iteraties met bijvoorbeeld een waterval methodiek. Hierbij was de documentatie en software gefixeerd, werd er getest ( ik ga er van uit dat iedereen dan spreekt over alle facetten die tot het testen behoren ), melden van voorkomende issues, hertesten en een testverslag als uiteindelijk eindproduct. Dit type van applicaties worden uiteraard nog steeds gebouwd en gebruikt, er wordt veel onderhoud aan gepleegd en is dus nog steeds bijzonder relevant

Afbeelding 1: Het OSI model

2. Webbased applicaties

Als in een later stadium veel meer internet wordt toegepast, worden er meer web-based applicaties gebouwd wat ook weer andere test strategie vereist. Veel voorkomende terminologie in deze context is Back-end en Front-end. Deze applicaties maken het mogelijk om als gebruiker vanuit een front-end applicatie, online de gewenste, eventueel verrijkte data uit de back end te tonen. Front end is de interface tussen gebruiker en Back end. Het is een applicatie waarmee gebruikers oftewel direct kunnen omgaan met de "back-end" toepassing of indirect met een programma dat dient ter ondersteuning van de front-end services. Dit ondersteunende programma is dan meestal dichter bij de vereiste middelen of met de mogelijkheid om te communiceren met de vereiste middelen. De back-end applicatie kan rechtstreeks communiceren met de front-end of misschien, meer in het bijzonder een tussenliggende programma dat bemiddelt front-end en back-end-activiteiten. Het gebruikte lagen model zie je in afbeelding 2.

Afbeelding 2: Het 3 lagen model bij een web based applicatie

In de ontwikkeling van web-based applicaties wordt vaak het drie lagen model gebruikt om te verwijzen naar websites. Om voor een goede performance te zorgen wordt de presentatielaag licht gehouden en zal daar over het algemeen niet veel code instaan. De gegevens die in de presentatielaag zichtbaar zijn, zullen meestal samengesteld worden in de logische laag.

Ook websites voor b.v. online winkels worden vaak gebouwd met behulp van deze drie lagen:

Presentatie laag, een front-end-webserver dient voor statische inhoud, en mogelijk een dynamische inhoud in de cache. Cache geheugen is het buffergeheugen van kleine capaciteit en hoog prestatievermogen tussen de CVE (Centrale Verwerkings Eenheid, ook wel processor genoemd) en het werkgeheugen; snel niet-adresseerbaar buffergeheugen, geplaatst tussen hoofdgeheugen en rekenorgaan, waarin veelvoorkomende opdrachten of veelgebruikte gegevens worden opgeslagen, zodat het rekenorgaan deze niet steeds uit het hoofdgeheugen behoeft op te halen. In web-based applicaties is Front End de inhoud weergegeven door de browser.

Logische laag, een middelste dynamische inhoud verwerking en generatie niveau applicatie server, bijvoorbeeld Ruby on Rails, Java EE, ASP.NET, PHP, ColdFusion platform.

Data laag, een back-end database of de data store, bestaande uit zowel datasets en het database managementsysteem of RDBMS software die beheert en biedt toegang tot de gegevens.

Omdat de drie lagen vaak op drie verschillende servers staan, te weten 1. Web server, 2. Applicatie server en 3. Data server, moeten er interfaces aanwezig zijn tussen deze servers. Overdracht van gegevens tussen lagen is onderdeel van de architectuur. Vaak wordt middleware gebruikt om verbinding te maken met de afzonderlijke lagen. Afzonderlijke lagen worden vaak (maar niet noodzakelijkerwijs) uitgevoerd op afzonderlijke fysieke servers. Middleware is een verzameling van programmatuur en afspraken die het mogelijk maakt om afzonderlijke applicaties met elkaar te laten communiceren. In de technische systeemarchitectuur zit middleware in het midden tussen meerdere applicatieservers, bijvoorbeeld tussen een webserver en een andere server of een mainframe. Deze applicaties kunnen de middleware gebruiken om berichten (messages) uit te wisselen. Hiervoor is een standaard taal nodig, zoals XML of een andere standaard. Het voordeel van middleware is een soort van coördinatorfunctie: de applicaties hoeven niets van elkaar te weten en hoeven alleen maar met de middleware te communiceren. Ze hoeven zelfs niet te weten waar een samenwerkend programma zich bevindt of wat het precies doet. Deze vorm van communicatie staat ook bekend als "Application to Application", of A2A. Middleware kan ook gebruikt worden om de applicaties van verschillende bedrijven met elkaar te laten communiceren. Dit wordt "business to business" genoemd, waarvoor de afkorting B2B wordt gebruikt. De boodschappen kunnen de meest uiteenlopende dingen bevatten: een vraag om informatie, het antwoord daarop, een foutmelding, een update, etc.. Niet te verwarren met een P2P netwerk, waar bv LinkedIn de grootste ter wereld van is; bestaat uit zogenaamde nodes, een node kan aan- of uitstaan. Een node geeft de bereidheid weer om informatie zoals bv contactpersonen etc te willen delen met overige P2P-gebruikers. Een actieve node geeft andere mensen de mogelijkheid bestanden te downloaden van zijn computer.

3. Cloud computing

Wat heden ten dage erg sterk in opkomst is, wordt vaak Cloud computing genoemd. Cloud computing onderscheidt zich van klassieke IT door de volgende karakteristieken:

'multi-tenancy' (de IT-middelen gedeeld over meerdere afnemers);

huur van diensten (het gebruik van IT-middelen is losgekoppeld van het bezit van IT-middelen);

elasticiteit (capaciteit kan zowel terstond opgeschaald als afgebouwd worden);

externe dataopslag (data worden doorgaans extern bij de leverancier opgeslagen). Binnen cloud computing worden verschillende typen onderkend. Afbeelding 3 geeft hiervan een overzicht.

Afbeelding 3: Verschillende typen van Cloudcomputing

De Publieke cloud is het meest gangbare type cloud. Hierbij is de mate van multi-tenancy sterk en de diensten worden zoveel mogelijk generiek aangeboden. In afbeelding 4 krijg je een overzicht van de mate waarin de karakteristieken van cloud computing terug te vinden zijn in de verschillende typen clouddienstverlening.

Afbeelding 4: Karakteristieken van de Cloud

Alvorens in te gaan op de vraag wat een “services georiënteerde architectuur” (SOA) is, is het zinvol stil te staan bij de vraag waarom een organisatie SOA wil implementeren. De laatste decennia is de wereldeconomie snel veranderd. De komst van het Internet, de toenemende wereldwijde concurrentie en de snel veranderende klantwensen zijn de belangrijkste veranderingen. Voor bedrijven is het van levensbelang om te anticiperen op deze trends. Het is de taak van IT om de noodzakelijke veranderingen mogelijk te maken. Het antwoord van IT op deze ontwikkelingen is het inrichten van een service georiënteerde architectuur. SOA is een architectuurstijl die het mogelijk maakt IT te optimaliseren en sneller aan te passen aan veranderende klantwensen. Met SOA maakt IT het mogelijk om een toenemende flexibiliteit van de IT middelen te realiseren en de kosten van IT te verlagen. Een andere belangrijk uitgangspunt van SOA is het verlagen van de risico’s die genomen worden bij het in productie brengen van IT, omdat de verantwoordelijkheden nu via SLA’s veel meer bij de providers liggen. Een succesvolle implementatie van SOA begint op het hoogste bedrijfsniveau met zoeken naar relatief constante componenten die binnen en buiten de organisatie gedeeld kunnen worden. De herbruikbare bedrijfs- en IT componenten zijn de services in SOA. Zoals een bedrijfsproces in kleinere deelstukken is op te splitsen, is dat ook toepasbaar voor bedrijfsservices. Ook die kleinere deelstukken zijn op hun beurt weer verder onder te verdelen in kleinere delen. Op deze manier ontstaat een heel landschap van aan elkaar gerelateerde services. De services op het hoogste abstractieniveau liggen hierbij het dichtste bij de belevingswereld van de gebruikersorganisatie. Services op het laagste abstractieniveau hebben een specifieke taak en zijn technischer van aard dan services op een hoger niveau. Het opdelen van services leidt tot servicelagen. Servicelagen zijn hierbij services die zich op hetzelfde abstractieniveau bevinden.

Afbeelding 5: Schematische weergave van Business en de Services

Tevens laat bovenstaande afbeelding zien dat een nieuw of gewijzigd bedrijfsproces gemaakt kan worden door hergebruik van services. Bijvoorbeeld in de situatie dat alle benodigde services voor een nieuw bedrijfsproces al bestaan, is het creëren van een nieuwe bedrijfsproces voornamelijk een kwestie van het aanbrengen van de juiste bedrijfslogica (business workflow). Programmeren maakt in dat geval plaats voor configureren.

Een Application Programming Interface (API) is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel (meestal in de vorm van bibliotheken). Vaak vormen API's de scheiding tussen verschillende lagen van abstractie, zodat applicaties op een hoog niveau van abstractie kunnen werken en het minder abstracte werk uitbesteden aan andere programma's. Hierdoor hoeft bijvoorbeeld een tekenprogramma niet te weten hoe het de printer moet aansturen, maar roept het daarvoor een gespecialiseerd stuk software aan in een bibliotheek, via een afdruk-API.

SOA bevat, naast een logische samenhang tussen services, een ESB (Enterprise Service Bus) om het fysieke gegevenstransport tussen services mogelijk te maken. De drager van de gegevens tussen twee services wordt een bericht genoemd. Dus alle berichten tussen de services, zoals aangegeven met stippellijnen in bovenstaand afbeelding, lopen via de ESB. De belangrijkste eigenschappen van een ESB zijn:

1. routeren en adresseren van berichten; 2. ondersteunen van berichttypen (zie Figuur6) en transportprotocollen (bijv. SOAP); 3. ondersteunen van integratiestijlen (bijv. ERP integratie of gateway met het Internet) met

verschillende adapters; In figuur 6 en 7 aangeduid als A. 4. kwaliteitsgaranties voor de levering van services, in het bijzonder zekerheid, beveiliging en

snelheid van de berichtafhandeling; 5. mogelijkheden voor het beheren van de enterprise service bus.

Services worden bij voorkeur met gestandaardiseerde interfaces aan de Enterprise Service Bus gekoppeld. Applicaties en niet-gestandaardiseerde services worden via een adapter aan een Enterprise Service Bus gekoppeld. Via deze adapters komen de applicaties beschikbaar als services.

Afbeelding 6: Voorstelling van de enterprise service bus

Binnen SOA worden een aantal categorieën van services onderscheiden.

Services voor het uitvoeren van bedrijfslogica (business rules),

services die gegevens ophalen uit databases (data),

services die communicatie met een GUI mogelijk maken, (Presentatie),

services die legacy systemen ontsluiten naar de SOA (legacy)

services die externe services koppelen aan de SOA. Externe services zijn services van service leveranciers en service afnemers buiten de infrastructuur van een bedrijf.

Afbeelding 7: De A staat voor adaptor

Deze beschreven typen worden doorgaans op één of meer lagen van de IT aangeboden. Op de softwarelaag wordt dit Software-as-a-Service (SaaS) genoemd. Platform-as-a-Service (PaaS) levert IT-diensten op de platformlaag, zoals een besturingssysteem of een applicatieraamwerk; additionele software moet dan wel door de afnemer worden ontwikkeld of worden geïnstalleerd. Infrastructure-as-a-Service (IaaS) levert technische infrastructuurcomponenten zoals opslag, memory, CPU en netwerk. Additionele platforms en software dienen te worden geïnstalleerd door de afnemer (zie onderstaand

figuur). Afbeelding 8: Categorieën van Services met voorbeelden

De cloud is onderverdeeld in drie lagen, namelijk IaaS, PaaS en SaaS (Infrastructure-, Platform-, en Software-as-a-Service) waarvan de laatste de meest bekend is. Het gaat hierbij om software die buiten de organisatiegrenzen wordt gehost bij een externe leverancier. In het cloud-paradigma wordt die externe leverancier aangeduid als de cloudprovider. Indien die cloudprovider ook nog platformvoorzieningen ter beschikking stelt om applicaties te ontwikkelen, dan spreken we van PaaS. Beperkt de behoefte zich tot het afnemen van netwerkdiensten en storage bij een provider dan spreken we van IaaS. En waarom dan ook niet de benodigde testfaciliteiten, ofwel STaaS, Software-Test-as-a-Service. In de basis is het van belang om naast de cloud-applicaties ook de cloud-architectuur onder de loep te nemen. Eigenlijk moet je als STaaS-provider verder kijken dan de cloud-systemen zelf. Daarbij rijzen vragen zoals:

Welke kwaliteitseisen zijn van belang voor de opdrachtgever? Stuurt een opdrachtgever voor een hoge beschikbaarheid of juist hoge een

betrouwbaarheid? Kennis over kwaliteitseisen helpen je de juiste testmaatregelen toe te passen. Hoe is het te testen cloudsysteem opgebouwd? Wat is de decompositie?

Kennis van toegepaste integratie-patterns binnen de cloud helpen je om de structuur van het cloudsysteem te begrijpen en de juiste testmaatregelen toe te passen.

Door gevoel te krijgen voor deze vragen wordt het mogelijk om een oordeel te vormen over de kwaliteit en conditie van de gehele cloud-architectuur.

Afbeelding 9: De service Software Testing over alle Services

Wat gaan we testen? (Dus vanuit het oogpunt van een TMap tester)

Zoals u zeker heeft gemerkt ben ik dieper ingegaan op het Cloud verhaal, omdat dit nu erg actueel is. Zoals beloofd in de inleiding nu iets over TMap en TMap Next. TMap Next is een door de Business gedreven benadering van testen. Daar ik voor het grootste deel van mijn testersbestaan de TMap methodologie gebruikt heb, wil ik kenbaar maken dat TMap zeer geschikt is voor het testen van een Cloud. We kunnen in ieder geval al een aantal in TMap Next genoemde Kwaliteitsattributen gebruiken met de daaraan gerelateerde testtechnieken.

Kwaliteitsattribuut Testmethode (TMapNEXT®) Randvoorwaarde

Scalability Load test Enterprise Integration Patterns

Availability Plug/Unplug FOLB (Fail Over Load Balancing) Patterns

Reliability Negative Testing Enterprise Integration Patterns

Adaptability Real Life Test Enterprise Integration Patterns

Security Multi Tenant Proof Hacker like tests

Ook het V-model vertoont bij het testen van SOA enige afwijkingen.

Afbeelding 10: Het V model met daarin nu de Services Tests en de Services Integratie tests

De theorie van IT-governance laat projecten sturen op een viertal aspecten: resultaat, risico, tijd en kosten. We noemen deze vier aspecten samen wel “Het Duivels-kwadrant”. De business driven testmanagement (BDTM) aanpak van TMap® gebruikt deze vier aspecten als basis voor de testaanpak. Business driven testmanagement wijst dus de weg naar de testaanpak bij SOA. Overeenkomsten Tmap Next en SOA testen:

Requirements coverage based testing

Risk-based structured test approach

Test Plan / Test Phases

Test Cases / Test Data / Test Automation

Defect Management / Functional Test

Use of off-shore resources / Virtualization

Politics {Quality / Schedule / Resources}.

Traditionele testmethoden bevatten een enkele vorm van eenvoudige Unit Testing, vaak uitgevoerd door ontwikkelaars. Deze tests zijn ontworpen met een kennis van de software internals, en zijn bijna altijd gericht op het testen van een zeer klein en specifieke deel van het product. Dit soort proeven zijn goed geschikt voor eenvoudige Webdiensten die weinig of geen interactie met andere onderdelen van de code hebben. Waarom zou je niet alle services zo goed en diepgaand mogelijk testen? Als een organisatie een oneindig aantal middelen tot haar beschikking heeft dan is dit een optie. Maar in het echte leven heeft geen enkele organisatie onbeperkte middelen. Er moeten dus keuzes gemaakt worden over wat getest moet worden en hoe diepgaand getest moet worden. De kern van de testaanpak is dat getest wordt wat ook daadwerkelijk getest moet worden. Niet te weinig testen, maar ook niet te veel testen, uiteindelijk om de productrisico’s af te dekken. De acceptanten moeten er zeker van zijn dat alle services getest worden die later een risico kunnen vormen als ze niet juist functioneren in productie. Dit betekent dat allerlei risico-afwegingen gemaakt moeten worden voordat er ook maar één testgeval wordt bedacht en uitgevoerd. Maar naast een kwalitatief excellente SOA willen de acceptanten ook de kosten van testen zo laag mogelijk houden en zo snel mogelijk inzicht in de kwaliteit.

Afbeelding 11: Business Driven Test Management (BDTM)

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 van BDTM is dat de testen worden gebaseerd op productrisico’s. Of in vakjargon, de teststrategie wordt gebaseerd op een productrisicoanalyse. Voor SOA verdient dit kenmerk extra aandacht omdat het vertalen van productrisico’s naar de testinspanning per service een goede analyse vereist. Ten slotte maakt BDTM de resultaten van testen zichtbaar voor de opdrachtgever.

Geautomatiseerd testen. Als laatste wil ik voor dat ik mijn conclusie met u deel, even het geautomatseerd testen aantippen. In de bovenstaand items is het al hier en daar genoemd, met name als je spreekt over web based en Cloud applicaties. We krijgen hier vaak te maken met Load en Stress testen, Performance testen en natuurlijk ook Security testen. De belangrijkste testitems zij even op een rijtje gezet:

o Veiligheid

o Autorisaties

o Bereikbaarheid

o Transactieverwerking

o Performance

o Stressgevoeligheid

o Betrouwbaarheid

We zullen vooral zien dat het testen geautomatiseerd zal gaan geschieden. Hiervoor worden verschillende tools aangeboden, waarvan sommige freeware. (Badboy, Jmeter, Selenium IDE) Hieraan zitten natuurlijk beperkingen. Meestal kan men hier voor een of meerdere browsertypes een script opnemen en daarna hergebruiken of als performance test tool gebruiken. De zwaardere ( en met licenties) tools zijn Selenium (toonaangevend), SOASTA, Advaltis, Parasoft SOAtest, HP Loadrunner, Loadstorm, Keynote en bv kostenloze Keynote Lite uitprobeer versie.

CONCLUSIE

Ondanks het feit dat anno 2010 het aandeel van cloud computing marginaal is, is de trend richting de cloud onmiskenbaar. Cloud computing is een sterk opkomend fenomeen dat past in de paradigmaverschuiving; cloud computing kan worden gezien als een verregaande of de volgende stap in het proces van uitbesteding (outsourcing) waarbij steeds meer IT-middelen worden gedeeld. De testen zijn steeds meer gericht op geautomatiseerd testen. Hierbij wordt programmeerkennis van de tester verwacht, bij voorkeur in een moderne taal zoals C#, VB, Java etc. Men spreekt dan ook steeds meer over een TESTER/DEVELOPER. Dit is om de door de ontwikkelaars geschreven UNIT tests te kunnen reviewen en om eigen geautomatiseerde tests te kunnen ontwikkelen. De tester zal van de Business en zijn processen op de hoogte moeten zijn en goede communicatieve eigenschappen moeten bezitten om de product risico’s te kunnen analiseren. Binnen SCRUM wordt al gesproken van Scrumlead/tester; mijn ervaringen binnen een Scrum team zijn dat het Scrumteam bestaat uit + 4 ontwikkelaars met een tester en als Scrum Master de analist, die de business door en door kent. Gezien de Sprints (Weliswaar variërend in tijdsduur) wordt hier een groot flexibel en creatief vermogen vereist van de tester. Er wordt steeds meer gevraagd van de tester naar mate de tijd verstrijkt, houd jezelf de spiegel ook eens voor: Je bent pas wijs, indien je beseft dat je nog maar zo weinig weet……. (Het prototype van het constante leerproces en uitdagingen)