Bij de implementatie van out-of-the-box-applicaties mag men

Methodieken Efficiënt testen van out-of-the-box-applicaties

5.9

Efficiënt testen van out-of-the-boxapplicaties

369

ij de implementatie van out-of-the-box-applicaties mag men verwachten dat de leverancier ze gedegen heeft getest en dat ze naar behoren werken. Zijn hiermee de risico’s voor de productieomgeving gedekt? Helaas niet helemaal. Factoren als complexe infrastructuur, applicatieketens, interfaces, capaciteitsplanning, performance, kwaliteit van de data en flexibiliteit van de inrichting brengen ook hier talloze risico’s met zich mee. Een testtraject blijkt nog steeds nodig te zijn voordat de productie-implementatie begint. Veel testmethoden zijn gebaseerd op het projectmatig ontwikkelen van software. Zijn deze methoden efficiënt toepasbaar in een procesgerichte beheerorganisatie?

B

Auteurs: Ron Bovee en Cees Eveleens - Mansystems

INLEIDING Steeds meer bedrijven kiezen voor out-ofthe-box-applicaties in plaats van maatwerkapplicaties. Daardoor worden de beheer- en onderhoudskosten sterk gereduceerd. Een out-of-the-box-applicatie heeft standaard veel functionaliteit, maar zal zodanig ingericht en geconfigureerd moeten worden dat deze functies bruikbaar worden voor het bedrijfsproces. De out-of-the-box-applicatie wordt daarom ingericht en indien gewenst aangepast aan de specifieke behoeften van de klant. Gegevensbronnen worden ontsloten waardoor de applicatie zo goed mogelijk het bedrijfproces kan ondersteunen. De applicatie krijgt een plaats in de complexe ITinfrastructuur. Een uitgebreid testtraject is bij de implementatie van een maatwerkapplicatie normaal. In het geval van een out-of-the-box-applicatie ziet men in de praktijk vele verschillen in het testtraject. Bij de ene organisatie wordt uitgebreid getest, terwijl bij een andere organisatie de applicatie niet of nauwelijks aan een test onderworpen wordt. Welke productierisico’s treden nu op of worden juist afgedekt?

Een test is belangrijk, maar is de investering gerechtvaardigd? De verschuiving van maatwerkapplicaties naar out-of-the-box-applicaties zorgt voor een veranderende visie op het testen. Het functioneel testen wordt minder en de behoefte aan een meer exploitatiegerichte testaanpak wordt groter. De meeste beschikbare testmethoden zijn echter gebaseerd op maatwerkapplicaties en zijn veelal te complex en daarom minder efficiënt en bruikbaar bij een out-of-the-box-implementatie. De testprocedure wordt echter steeds belangrijker om risico’s tijdens de exploitatie te beheersen. In de praktijk blijkt dat een aantal IT-organisaties zelfs kiest voor een apart testproces binnen de ITIL-werkwijze.

5

Dit artikel gaat in op het volgende vraagstuk: “Op welke manier kan het testen van out-ofthe-box-applicaties op een efficiënte manier worden ingericht?”. In de volgende paragraaf wordt ingegaan op de motivatie van het testen, het bijzondere van het testen van een out-of-the-box-applicatie en de praktische problemen die daarbij kunnen spelen.

IT Service Management, best practices Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

370

Daarna komen economische aspecten van het testen aan de orde. Dan wordt testmanagement uitgewerkt, en daarna wordt ingegaan op verwachtingsmanagement in relatie met het testen. Het artikel wordt afgesloten met een reeks conclusies en aanbevelingen. Dit artikel is met name bedoeld voor de ITafdelingsmanager, de change-managers en de testmanagers die betrokken zijn bij de implementatie en beheer van out-of-the-boxapplicaties.

TESTEN: WAAROM EN HOE? Waarom testen? Testen is een middel om risico’s te beheersen bij het invoeren en veranderen van een informatiesysteem. Wanneer een informatiesysteem wordt ingevoerd of wordt veranderd, bestaat een reële kans op onbeschikbaarheid tijdens de productie. Daarnaast bestaat het risico dat het systeem niet aansluit bij de gebruikerswensen of dat de bedrijfsprocessen niet optimaal worden ondersteund. Dit kan resulteren in productiviteitsverlies en herstelkosten. Productiviteitsverlies is de belangrijkste factor voor de investering in een testen hersteltraject. De herstelkosten nemen exponentieel toe als de fout pas in een laat stadium van de implementatie wordt hersteld [Boehm, 1981]. Daarom zijn de testmethoden erop ingericht om in een zo vroeg mogelijk stadium de fout te ontdekken zodat de productierisico’s vroegtijdig kunnen worden aangepakt. De out-of-the-box situatie Testen is in de praktijk noodzakelijk. Iedere IT-afdeling heeft wel een oplossing op het testgebied ingericht, waarbij bekende testmethodieken zoals ISEB [Spillner e.a., 2004] die examineert, en TMap® [Pol e.a., 1998], veel voorkomen (zie kader). Testmethoden voor maatwerksoftware zijn in het algemeen goed bruikbaar, maar voor een out-of-thebox-applicatie ligt het anders (figuur 1). In de testmethoden ligt de focus vooral op het ontwikkelen van software en niet op de implementatie van het informatiesysteem.

De soorten testen verschillen bij een out-ofthe-box-applicatie: in plaats van een functionaliteitstest van een initieel functioneel ontwerp komt het testen meer neer op de vraag: “Hoe wordt de functionaliteit ingezet en kan het in de praktijk acceptabel werken?” De tester krijgt een geheel nieuwe functionaliteit voorgeschoteld en zal moeten wennen aan de nieuwe applicatie. De acceptatie van de nieuwe applicatie speelt een grote rol in het zorgvuldig en objectief testen. ISEB: Information Systems Examinations Board Is een exameninstituut voor o.a. het behalen van Foundation en Practitioner certificaat op het gebied van software testen. De opleidingen “software testen” worden gegeven door erkende instituten. De Foundation opleiding voorziet in de basiskennis voor een gestructureerde en systematische werkwijze bij het testen. TMap®: Test Management Approach Een generiek model, geschikt voor vrijwel alle testsoorten en testactiviteiten. Het model behelst een gestructureerde testaanpak voor informatiesystemen. De methode wordt door de volgende pijlers ondersteund: • een aan de ontwikkelingcyclus gerelateerde fasering van testactiviteiten; • een goede organisatorische inbedding; • de juiste hulpmiddelen en infrastructuur; • bruikbare technieken voor de testactiviteiten. De functionaliteit van een out-of-the-boxapplicatie wordt gedegen getest door de leverancier en getoetst door verschillende klanten. Het risico op functioneel gebied is dus minimaal. Op het gebied van data, performance, schaling van het systeem en het inbedden in de complexe infrastructuur met vele interfaces en ketenapplicaties zijn echter wel veel exploitatierisico’s te herkennen. De out-of-the-box testmethodiek moet juist deze risico’s aanpakken. Hier vindt een duidelijke verschuiving plaats van functioneel gericht naar exploitatiegericht testen.

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Out-of-the-box-testmethoden Generieke testmethoden (Tmap) Programmatest

Integratietest

Systeemtest

Functionele acceptatietest

Productie acceptatietest

371

Figuur 1 Positionering van out-of-the-box testen

Testmethoden Binnen TMap® en andere testmethodieken die hun oorsprong hebben in de software ontwikkeling, krijgen facetten van het testen van out-of-the-box-applicaties wel aandacht, maar blijft dit toch onderbelicht. De ITIL best practices bieden eveneens weinig houvast. In de change- en release-managementprocessen wordt heel kort aangegeven dat testen belangrijk is en dat testen uitgevoerd moeten worden op een separate testomgeving, maar dat is alles. De procesmodellen van ASL en MOF gaan een stap verder met het beschrijven van de testactiviteiten, maar geven geen richtlijnen voor testen die efficiënt uitgevoerd kunnen worden bij een out-of-the-box-implementatie. Bij het gebruik van een testmethodiek ontstaat snel de situatie dat met een kanon op een mug wordt geschoten en de benodigde dynamiek tijdens de implementatie uit het oog wordt verloren. Het andere uiterste, niet of nauwelijks testen, komt in de praktijk eveneens voor. Vooral bij implementaties onder een hoge tijdsdruk of met een laag budget wordt het testtraject ad hoc en ongestructureerd uitgevoerd en de testtijd geminimaliseerd. Hierdoor worden ongekende risico’s gelopen. De out-of-the-box testmethode moet mee kunnen schalen met het budget van het implementatietraject en de potentiële productierisico’s, zodat op efficiënte wijze de risico’s ontdekt worden. In de hiernaast afgebeelde case wordt een voorbeeld uit de praktijk gegeven.

Praktijk case Bij KPN OVN is Indus Service Suite geïmplementeerd. Dit is een planning- en scheduling applicatie waar momenteel zo'n 60 planners en 700 monteurs gebruik van maken. KPN stelde zich de vraag of dit systeem opgeschaald kon worden naar 200 planners en 1.000 monteurs. Om deze vraag te onderzoeken is een loaden stress-test-tool ingezet van Scapa Software. Deze tool simuleert een load van gebruikers en geeft metrics van het te testen systeem af. De Scapa omgeving draaide testscripts met stress-test-clients richting de citrix-servers voor de planners en de web-servers voor de monteurs. Deze vorm van testen genereert een realistische belasting van het systeem. Een van de kritische succesfactoren bij het stress-testen is het bepalen van de frequentie van het gebruik van de functies. Afwijkingen in de frequentie ten opzicht van de werkelijke situatie resulteren in onbetrouwbare stress-testresultaten.

5

Door het uitvoeren van deze test heeft het management vertrouwen gekregen in de capaciteit van het totale informatiesysteem en kan zij de gewenste plannen ten uitvoer brengen. Problemen bij een projectmatige testaanpak Testen wordt meestal projectmatig opgepakt. Bij een grote implementatie van een out-of-the-box-applicatie wordt een test-


372

team samengesteld onder leiding van een testcoördinator met veel kennis van de bestaande testmethodieken. Het testteam bestaat bewust uit personen die geen deel uitmaken van de realisatie- en implementatieteams, om belangenverstrengeling te voorkomen. Deze projectstructuur is vergelijkbaar met een bouw- en implementatieproject van een maatwerkapplicatie. Bij het voorbereiden van het testtraject ontstaat een aantal kenmerkende situaties. De testcoördinator zoekt het functionele ontwerp op basis waarvan getest kan worden. Maar bij een outof-the-box-applicatie is een functioneel ontwerp een document dat de leverancier niet ter beschikking van de klant zal (willen) stellen. In dat geval zal teruggegrepen moeten worden op de beschrijving van de functionaliteit in andere documenten, zoals handboeken en trainingsmateriaal. Nog een andere mogelijkheid is dat de leverancier standaard-testmateriaal beschikbaar stelt, of dat samengewerkt kan worden met andere klanten die dezelfde applicatie in gebruik hebben genomen. Veel tijd gaat zitten in het uitgebreid voorbereiden van het testtraject, zoals het vaststellen van de bevindingenprocedure, het maken van afspraken met het realisatieteam en met leveranciers met betrekking tot de herstelactiviteiten, het ontwerpen van de testplannen en test-scripts en het realiseren van een testomgeving. Deze activiteiten komen bij elk project weer terug. Tijdens het testen zijn de volgende situaties kenmerkend: • De testcoördinator wil gedetailleerd inzicht hebben in de testresultaten van een leverancier. • De testers zijn meestal eindgebruikers met weinig testervaring. • De testers hebben een ander verwachtingspatroon bij de applicatie en vergelijken deze met hun oude situatie. • Wijzigingsverzoeken worden als bevinding gekenmerkt. • Standaardfunctionaliteit wordt uitgebreid getest, wijzigingen op de standaardapplicatie krijgen onvoldoende aandacht.

Na een implementatie worden aanpassingen in de applicatie procesgericht aangepakt via de change- en releasemanagementprocessen waarin eveneens testactiviteiten zijn ingebed. Meestal worden deze activiteiten echter ongestructureerd uitgevoerd. Bij out-of-the-box testen is het mogelijk om een groot deel van het testmateriaal, de methoden en de aanpak te standaardiseren en te hergebruiken. De bevindingen kunnen bijvoorbeeld op eenduidige wijze worden afgehandeld en scripts kunnen worden hergebruikt. Afspraken met leveranciers en interne afdelingen kunnen blijvend worden vastgelegd. Om het testen goed op de kaart te zetten kan testen als een separaat proces worden gepositioneerd met duidelijke relaties tot de change- en release-managementprocessen. Het proces kan zodanig schaalbaar en flexibel worden opgezet dat het eveneens voor testtrajecten in projecten toepasbaar is. Het voordeel van het positioneren van testmanagement als proces is de besturingscyclus. Het testen zelf herstelt of verbetert niets, uit de testbevindingen kan echter interessante informatie komen voor verbeteringen van andere processen. Zo kan bijvoorbeeld blijken dat het change- of releasemanagementproces verbeterd kan worden zodat de kans op fouten vermindert.

DE ECONOMIE VAN HET TESTEN Testen kost tijd en geld. Schaarse middelen dus, die op een verantwoorde wijze moeten worden ingezet om de gestelde doelen te bereiken. Dat betekent dat er een goede afweging tussen kosten en baten gemaakt moet worden. Een centraal begrip in dit artikel is ‘efficiëntie’. Om dit begrip uit de economie goed te kunnen plaatsen in het kader van dit artikel, is het nuttig om in te gaan op wat de woorden ‘kosten’ en ‘baten’ in relatie tot het testen betekenen. Om efficiënter te kunnen testen is het nodig om te weten door welke factoren kosten en baten worden bepaald en hoe deze zijn te beïnvloeden.



Kosten Op het gebied van kosten kunnen we onderscheid maken tussen directe en indirecte kosten die aan het testen zijn verbonden. Met directe kosten worden de kosten bedoeld die direct samenhangen met de uitvoering van de testen. Hierbij kan gedacht worden aan salariskosten, IT-voorzieningen en facilitaire zaken. Onder indirecte kosten worden de kosten verstaan die gemoeid zijn met het uitstel van de live-datum. Voorbeelden zijn: • De winst die de implementatie van de nieuwe (versie van de) applicatie met zich mee brengt, laat langer op zich wachten. • Langere inwerkperiode doordat de kennis en ervaring uit het opleidingstraject is weggezakt. Er is eventueel een opfriscursus nodig. • Het oude systeem moet langer operationeel blijven. Voor het begroten van de benodigde testcapaciteit zijn inmiddels diverse methodieken ontwikkeld, waarvan Testpuntanalyse [Veenendaal & Dekkers, 1999] de bekendste is. Voor het testen van pakketten is Testpuntanalyse echter ongeschikt. Voor het begroten van het testen van een out-of-thebox-applicatie zal men daarom moeten terugvallen op industrienormen, eigen ervaringscijfers of, last but not least, ervaringen van de leverancier die een dergelijke implementatie van hetzelfde pakket immers al bij diverse klanten heeft gedaan. Enkele factoren die de kosten van een testtraject beïnvloeden zijn: • Verwachte kwaliteit - dit bepaalt hoe grondig en uitvoerig moet worden getest. • Omvang van de wijziging - reken bijvoorbeeld voor implementatie van een x.0-versie 10% extra inspanningen. • Kwaliteit van de aangeleverde gegevens veel bevindingen ontstaan doordat aangeleverde gegevens onvolledig of incorrect zijn. • Ervaringsniveau - herbruikbaarheid testware, besparing op opleiding van ervaren testers.

Casus TrustMe B.V. Verzekeringsmaatschappij TrustMe B.V. heeft 20 medewerkers op de afdeling polisadministratie. De applicatie waarmee deze administratie wordt gedaan is geupgrade naar een hogere versie.

373

Op de eerstvolgende werkdag wordt echter duidelijk dat de stabiliteit en de performance ten opzichte van de oude situatie sterk zijn teruggelopen. Mede als gevolg van de ongeplande reboots gedurende werkdagen, is het aantal polismutaties per dag nu teruggelopen van gemiddeld 24 naar 18 per medewerker. Pas na 8 werkdagen is de beheerafdeling er in nauwe samenwerking met de leverancier in geslaagd de problemen weer onder controle te krijgen. Twee werkdagen en een weekend zijn besteed aan een upgrade naar een hogere database-versie, het indraaien van een patch van de leverancier, het uitbreiden van het intern geheugen van de server en het uitvoeren van regressietesten. Totale schadepost: Inhuur uitzendkrachten i.v.m. 25% productiviteitsverlies gedurende 8 werkdagen: 320 uur à €25,= €8.000,Extra uren beheer: 40 uur à €70,= €2.800,Extra hardware-investering: = €200,Totale schade = €11.000,-

5

Baten De baten van het testen liggen in het terugbrengen van de operationele risico’s die een bedrijf loopt wanneer het betreffende product in gebruik wordt genomen. Om een verantwoorde inschatting van die risico’s te maken, is het noodzakelijk om inzicht te hebben in de afhankelijkheden tussen enerzijds de bedrijfsprocessen en anderzijds de informatiesystemen die deze processen ondersteunen. Het uitvoeren van een risicoschatting is een complexe activiteit waarvoor specifieke vaardigheden vereist zijn. Omdat risico het pro-


374

Naast het productiviteitsverlies wordt de schade bepaald door de component ‘herstelkosten’. Factoren die hierbij een rol spelen zijn bijvoorbeeld: • Roll back naar oude situatie (indien überhaupt mogelijk). • Extra inzet van ontwikkelaars (bij zelfbouw; bij aanschaf van standaardpakket is dit afgedekt door de garantie). • Extra inzet beheerders om herstelacties uit te voeren.

van indirecte schade. Als de effecten van de storing merkbaar zijn voor de klant, kan er sprake zijn van bijvoorbeeld schade aan reputatie of vergoedingen aan klanten in verband met een lager serviceniveau. Acceptatieniveau Zoals we al eerder zagen, is het doel van het testen gelegen in het terugbrengen van de operationele risico’s tot een aanvaardbaar niveau. Bij het afwegen van welke risico’s aanvaardbaar zijn, speelt het kosten- en batenplaatje een essentiële rol. Het verlagen van het risico zal steeds meer inspanning vergen, naarmate meer fouten zijn opgelost (figuur 2). Opbrengsten (risico-vermindering)

duct is van kans en schade, is kennis van zowel de business (‘schade’) als van de techniek en het gebruikersgedrag (‘kans’) noodzakelijk. Het risico dat een geconstateerde fout met zich meebrengt kan dus ook op twee manieren worden teruggebracht. Enerzijds kan een goede bugfix de kans terugbrengen naar nul, of kan worden gekozen voor een aanvullende gebruiksinstructie waarmee de fout omzeild kan worden. Anderzijds kan ook geprobeerd worden de schade te beperken. Een belangrijk schade-element is productiviteitsverlies als gevolg van verminderde beschikbaarheid van het informatiesysteem gedurende de periode waarin de problemen zich voordoen. Factoren die de hersteltijd kunnen beïnvloeden zijn bijvoorbeeld: • Reparatievermogen van de leverancier als de leverancier zelf fabrikant van de applicatie is, kan een bugfix sneller beschikbaar zijn. Bij een leverancier die slechts doorverkoper is, kan foutherstel echter een langdurige geschiedenis worden. • Aard van de applicatie - een fix door een parameteraanpassing in een out-of-thebox-applicatie is veel sneller doorgevoerd dan een aanpassing in maatwerkprogrammatuur. • Beschikbaarheid van ontwikkelaars en beheerders - door het reserveren van capaciteit bij de ontwikkelaars en beheerders tijdens de eerste live-dagen wordt voorkomen dat er vertraging optreedt door plannings-issues.

Kosten Figuur 2 Kosten en baten

Het is daarom van groot belang om voorafgaand aan de test te bepalen wat de drempelwaarde is voor het risico dat men wil lopen in productie (figuur 3). Als maatstaf neemt men daarvoor dan bijvoorbeeld de frequentie waarmee bevindingen worden geconstateerd. Een vuistregel kan dan zijn dat kan worden gestopt met het testen als er na 1 dag testen minder dan 10 nieuwe bevindingen worden gedaan. Hierop zijn natuurlijk tal van varianten denkbaar, maar waar het om gaat is dat het testproces transparant wordt gemaakt voor de eindgebruikers, de testers, de leverancier en de overige betrokkenen.

Naast de directe schade die in het bovenstaande is genoemd kan er ook sprake zijn



Bevindingen per tijdseenheid risico drempelwaarde

tijd Figuur 3 Drempelwaarde

In tegenstelling tot de baten zijn de kosten van het testen over het algemeen wel duidelijk zichtbaar. De kosten van de testinspanningen en het verschuiven van de productiedatum zijn bijvoorbeeld vrij goed in euro’s uit te drukken. Voor het teruggebrachte risico geldt dit niet. Dit brengt het risico met zich mee dat te vroeg besloten wordt te stoppen met testen en over te gaan tot het in gebruik nemen van de applicatie. Organisaties moeten daarom bij het testen niet alleen op kosten maar ook op risico’s managen.

TESTEN ALS PROCES In het voorgaande is al ingegaan op de verschillen tussen een projectmatige en een procesgerichte aanpak van het testen. Nu wordt een procesgerichte benadering als mogelijkheid geopperd om een hogere efficiëntie te bereiken. In deze paragraaf komt een mogelijke uitwerking van het testmanagementproces aan de orde. Daarnaast wordt aandacht besteed aan het omgaan met bevindingen die tijdens de test worden gedaan. In de afhandeling daarvan liggen eveneens mogelijkheden om efficiëntievoordeel te behalen. Voor het uitvoeren van een test kunnen diverse activiteiten worden onderscheiden, die door mensen met verschillende rollen in onderlinge samenhang worden uitgevoerd. Voor een goed eindresultaat is het bovendien belangrijk dat dit volgens een gespecificeerde

procedure wordt uitgevoerd [Veenendaal, 199]). Gelet hierop is er veel voor te zeggen het testen als afzonderlijk proces te beschouwen. Ook bij bijvoorbeeld TMap® [Pol e.a., 1998] komen we deze gedachte tegen.

375

Een andere benadering, die we ondermeer bij ITIL [Van Bon e.a., 2004] tegenkomen, positioneert het testen als een fase binnen het change-managementproces. De gerealiseerde wijziging wordt onder verantwoordelijkheid van de change-manager getest voordat zij in productie wordt genomen. Welke benadering in een organisatie de beste is, hangt sterk af van de wijze waarop de diverse (ITIL) processen zijn ingericht. Bij deze overweging zal tenminste naar de raakvlakken met de processen incidentmanagement, operations management [Bovee & Ruwaard, 2001], change management en release management moeten worden gekeken. Testmanagement als efficiënt proces Belangrijke voordelen van het kiezen voor een afzonderlijk testmanagementproces, zijn: • Schaalvoordeel - door de bundeling van testactiviteiten kan een besparing worden bereikt op het gebied van personeel (delen van kennis en ervaring) en infrastructuur (delen van testomgevingen). Bovendien wordt het lonend om te investeren in bijvoorbeeld afzonderlijke testruimtes en geautomatiseerde hulpmiddelen ter ondersteuning van de testen. • Kwaliteit - door het testen te positioneren als afzonderlijk proces met een eigen proceseigenaar en eigen verantwoordelijkheden, wordt een zekere objectiviteit geïntroduceerd. De praktijk heeft uitgewezen dat hiermee goede resultaten te behalen zijn. • Efficiëntie - wanneer de uitvoering van testactiviteiten wordt geconcentreerd, zal met het doorlopen van een leercurve een zekere expertise worden ontwikkeld waardoor het wiel niet steeds opnieuw hoeft te worden uitgevonden. Hergebruik van testware en het volgen van best practice-procedures is een belangrijk aandachtspunt bij het streven naar meer efficiëntie in het testen.

5


Changemanagement Releasemanagement

Testmanagement

Knowledgemanagement

Incidentmanagement

Intake

376 Analyse

Voorbereiding

Realisatie

Specificatie

Uitvoering

Implementatie

Intake Knowledge item

Intake

Vrijgave Knowledge item

Analyse

Afronding

Figuur 4 De relatie van testmanagement met overige IT-beheerprocessen

Het out-of-the-box testproces afgeleid van TMap® biedt op zichzelf al veel mogelijkheden om efficiënt te gaan testen. Echte efficiëntie wordt haalbaar door in de processtappen een handige werkwijze te volgen. Met de ervaring die vanuit het testmanagementproces wordt opgebouwd, kan een steeds betere invulling van het testtraject worden gemaakt. “Ken de applicatie en de leverancier” is hier het motto. In de volgende subparagrafen worden de diverse fasen binnen het testmanagementproces uitgewerkt (figuur 4). Daarbij wordt ingezoomd op de out-of-the-box-context en het efficiëntieaspect. Voorbereiding In de voorbereidende fase van een test vindt er een intake plaats van de vastgestelde specificaties. Het gaat hierbij om zowel technische (performance, beschikbaarheid) als functionele aspecten (beschrijving van de gewenste werking). In het geval van een outof-the-box-applicatie beperkt de functionele specificatie zich tot een beschrijving van de parameters die in het systeem moeten worden ingevoerd. Denk hierbij aan beschrijvingen van de klantgegevens, de afspraken met de klanten (SLA’s) en de uitwerking van de workflow.

Na het bepalen van de specificaties wordt een inschatting van de kwaliteit van de outof-the-box-applicatie gemaakt. Deze inschatting is gebaseerd op ervaring met de applicatie en het vertrouwen in de leverancier. Van de leverancier mag immers verwacht worden dat deze de applicatie zelf grondig heeft getest en een kwalitatief hoogwaardig product levert. Wanneer de relatie met de leverancier goed is, kunnen gegevens over known errors en bevindingen uit pilotimplementaties betrokken worden bij de kwaliteitsschatting. Als dit vertrouwen niet aanwezig is, kan besloten worden om bijvoorbeeld een audit uit te voeren op het bouw- en testproces bij de leverancier, of een referentiebezoek te brengen aan een andere gebruikersorganisatie. Deze maatregelen zijn beter (en vooral goedkoper!) dan het herhalen van het testwerk van de leverancier. Vervolgens moet het risico worden geschat bij het inbedden van de applicatie in de bestaande infrastructuur. Hierbij moet worden gekeken naar mogelijke performanceen capaciteitsrisico’s, de impact van interfaces en netwerkaspecten. De leverancier kan met zijn ervaring hierin een grote adviserende rol spelen en aangeven op welke aspecten testen nodig wordt geacht. De kwaliteit van de benodigde ‘set-up’ gege-



vens moet worden geschat. Met behulp van een vaste methode voor het inventariseren van de risico’s kan efficiëntie bereikt worden. Met de opgebouwde ervaringscijfers en de kennis vanuit het testmanagementproces wordt de risicobepaling steeds eenvoudiger. Als de risico’s in kaart zijn gebracht wordt bepaald welke soorten testen noodzakelijk zijn. Het kiezen van de soorten testen is sterk afhankelijk van verschillende aspecten. Een belangrijke vraag is of productierisico’s acceptabel zijn in termen van productiviteitsverlies en herstelkosten. Het productiviteitsverlies kan worden bepaald door rekening te houden met de hersteltijd. Daarom is het van belang om te weten hoe snel de leverancier fouten kan oplossen en bugfixes kan aanleveren. In de praktijk blijkt dat in een out-ofthe-box-situatie fouten in de set-up- gegevens de productie sterk belemmeren. Deze aspecten zijn echter meestal snel en zonder veel consequenties te herstellen (zie paragraaf ‘De economie van het testen’). Daarom is het accepteren van bepaalde snel op te lossen risico’s een reële manier om een testtraject te bekorten. In deze fase wordt gekozen welke testen met welke diepgang uitgevoerd worden. Met ervaring vanuit vorige trajecten, zoals statistieken van gebruikte testinspanning en de behaalde resultaten, kan worden geschat welke inspanning nodig is voor het testen. Specificatie In de specificatiefase wordt uitgewerkt wat er precies getest wordt en hoe dat gebeurt. Allereerst wordt er een ontwerp gemaakt, waarna de testgevallen worden uitgewerkt. De specificatie van de testgevallen loopt parallel aan de realisatiefase van het testobject. Gedurende deze realisatie zal meer en meer duidelijk worden hoe het object er concreet uit komt te zien. Tegen die achtergrond wordt er in de specificatiefase een onderscheid gemaakt tussen het maken van een logisch en fysiek testontwerp. Het logisch testontwerp geeft een beschrijving van de uitgangssituatie, de benodigde acties en het

Voorbeeld: risico’s en budget bepalen Het uitgangspunt voor het testbudget is een ervaringscijfer dat een percentage is van het projectbudget: Projectbudget Prijs testdag dagen testbudget Perc. €400.000 €1.000 20 €20.000 5,00% €100.000 €1.000 5 € 5.000 5,00% Risicoprofiel inventarisatie: Risico-criteria opties Informatiesysteem hoog +2%, is bedrijfskritisch midden +0 %, laag -0,5% Mate standaard product maatwerk +1,5%, meerwerk +0,5%, standaard -0,5% Kwaliteit leverancier

laag +2%, matig +1%, goed 0%, zeer goed -0.5%

Snelheid aanbrengen live bugfixes

> 10 dagen + 2%, > 5dagen + 1%, < 1dag –1%

Aanwezigheid testbasis nee +1%, minimaal +0,5%, -0,5%

keuze +2%

+0,5%

0%

-1%

+0,5%

Inspraak eindgebruikers hoog +0,5%, normaal +0%, laag -0,5%

0%

Complexiteit applicatie Hoog +1,5%, en integraties Redelijk +1%, Laag -0,5%

+1,5%

Testinformatie van leverancier Totaal

Geen +1%, Normaal +0%, Veel -0,5%

377

-0,5% +3%

5

Projectbudget Prijs testdag dagen testbudget Perc. €400.000 €1.000 32 €32.000 8,00% €100.000 €1.000 8 € 8.000 8,00%

resultaat. Bij het maken van het fysiek ontwerp wordt de vertaling gemaakt naar meer gedetailleerde en concrete testgevallen. In de testontwerpen moet goed gekeken worden wat precies getest moet worden. Hiervoor is kennis nodig van zowel de functionele, als de kwaliteitseisen, ofwel een testbasis. Tijdens het selectietraject van de outof-the-box-applicatie zijn veel eisen gesteld en heeft er een toetsing plaatsgevonden op deze eisen. Deze selectie-eisen zijn meestal veel breder dan de aspecten die in eerste


378

instantie tijdens de exploitatie van de applicatie gebruikt gaan worden. Het is niet noodzakelijk om al deze aspecten opnieuw grondig te testen. Een out-of-the-box-applicatie heeft bijvoorbeeld vele interfacemogelijkheden. Als er slechts één mogelijkheid gebruikt wordt, test dan alleen deze ene mogelijkheid. Indien later nieuwe interfaces worden aangesloten kunnen die op dat moment worden getest. Tijdens de realisatiefase is het van belang om te bepalen hoe de out-of-the-box-applicatie wordt gebruikt en welke set-up wordt gekozen. Dit moet worden vastgelegd in een setup-document. Tijdens het bepalen van de set-up kan blijken dat veranderingen of aanvullingen nodig zijn op de out-of-the-boxapplicatie. Het is van belang om deze wijzigingsverzoeken tot een minimum te beperken. Indien wijzigingen nodig zijn moeten deze grondig worden getest, hoe eenvoudig ze ook zijn. Hier is namelijk feitelijk sprake van een nieuwe versie van de software. Het aanpassen van software brengt altijd het risico met zich mee dat ergens anders in de applicatie fouten ontstaan. Om dit grondig te testen is een volledige hertest van alle facetten nodig. Een dergelijke test (regressietest genoemd) kost in de regel veel tijd en geld. De leverancier brengt deze wijzigingen meestal in de out-of-the-box-applicatie aan en kan daarom aangeven welke softwareobjecten er bij betrokken zijn. In goed overleg kan zo bepaald worden wat de kans is op fouten in andere gedeelten van de applicatie zodat een algehele regressietest niet noodzakelijk is. Deze werkwijze wordt ook wel een delta-regressietest genoemd. Het set-up-document is een uitstekende basis voor de testen. De test-scripts kunnen op basis van dit document en de handleidingen worden samengesteld. De test-scripts bevatten concrete testacties die in een uitvoerbare volgorde zijn geplaatst. Uiteindelijk worden de scripts opgenomen in een testdraaiboek waarbij de onderlinge samenhang is uitgewerkt. Bij het opstellen van het logisch ontwerp valt er een aanzien-

lijk voordeel te behalen wanneer het te testen object een out-of-the-box-applicatie betreft. De leverancier zal dan wellicht een standaard hebben die door het verwerken van de diverse parameters toegesneden kan worden op de klantsituatie. In de specificatiestap zal ook de testinfrastructuur worden voorbereid. Bij een implementatietraject is een scheiding tussen testen productieomgeving van belang. Afhankelijk van de hoeveelheid wijzigingen in de applicatie-release of veranderingen in de set-up, kan een testsysteem worden ingehuurd of een permanente testomgeving beschikbaar worden gesteld. Bij een applicatie met veel interfaces zal de testinfrastructuur het end-to-end testen van de interfaces moeten faciliteren. De andere applicatietestomgevingen moeten beschikbaar zijn, inclusief de interfaces. In de praktijk blijkt dat interfaces een grote bron zijn van problemen tijdens de exploitatie. Het goed beheren van de testomgeving, inclusief de interfaces, voorkomt veel coördinerend werk tijdens het voorbereiden van de test. Uitvoering Wanneer het object is vrijgegeven om getest te worden, kan daadwerkelijk begonnen worden met de uitvoering van het draaiboek. Dan wordt bepaald wie de testen gaat uitvoeren. Meestal zijn hier eindgebruikers bij betrokken. Het is van belang dat de persoon enige ervaring met testen heeft. De nieuwe applicatie is onbekend voor de gebruiker. Daarom is een functionele en procesgerichte training voor het testen van belang. Anders treedt het effect op dat de testers een ander verwachtingspatroon hebben bij de applicatie en deze vergelijken met hun oude situatie. Daardoor komen allerlei oneigenlijke wensen naar boven. De tester moet dit effect kennen en zich bij het testen louter baseren op het set-up-document. De testers doorlopen de verschillende scripts en hun bevindingen worden geregistreerd. Het managen van deze bevindingen zal bij elke test gelijk zijn. Deze procedure kan binnen het testproces worden vastgesteld en



vele malen worden hergebruikt. Het is van belang dat de bevindingen worden gecategoriseerd en goed omschreven. Om de uitvoering zo efficiënt mogelijk te maken is het belangrijk om de leverancier nauw bij het testen te betrekken. De leverancier kan de gebruikers helpen bij functionele vragen en zaken opnieuw uitleggen. De leverancier kan bevindingen ook snel controleren en in zijn eigen woorden omschrijven. Belemmerende bevindingen kunnen direct worden hersteld zodat het testen kan doorgaan. Op deze manier komt het dynamische karakter tijdens het testen naar boven zodat snel ingespeeld kan worden op de veranderende situatie tijdens het implementatietraject. Afronding Nadat de testen zijn uitgevoerd, breekt de fase ‘Afronding’ aan. Deze fase komt in de praktijk vaak in de knel door tijdgebrek, terwijl juist hier de nodige efficiëntie valt te behalen. De belangrijkste activiteit in deze fase betreft het rapporteren aan de opdrachtgever over de kwaliteit van het testobject. Door het doorlopen van een herstel- en hertest-cyclus is de kwaliteit op een acceptabel niveau gebracht, en in de rapportage komt aan de orde welke bevindingen nog open staan, en welk risico de opdrachtgever daarmee loopt. Het tweede speerpunt betreft het testproces zelf. Er zal een evaluatie plaats moeten vinden over de gekozen aanpak en het verloop van de testen. Juist in een procesgerichte benadering, waarbij het testen van bijvoorbeeld nieuwe releases van een applicatie een terugkerende activiteit is, is het van belang om gespitst te zijn op verbeterpunten in het proces. Hieronder valt ook het herbruikbaar maken van zogenaamde testware (testbestanden, testscripts, et cetera) zodat deze gebruikt kunnen worden bij (regressie)testen van volgende releases. Aandachtspunten bij de evaluatie zijn bovendien de testkosten en de begroting daarvan. Zoals eerder al aan de orde kwam, spelen eigen ervaringscijfers bij het maken van een begroting een belangrijke rol.

Het derde punt betreft het formeel afsluiten van de test, waarbij de opdrachtgever decharge verleent aan het testteam. Dit lijkt een triviale stap, maar in de praktijk komt het er soms toch niet van. Als er geen punt achter het testen wordt gezet, en er worden tijdens de productievoorbereiding nog hier en daar wat testen uitgevoerd, kunnen er allerlei ongewenste situaties optreden. Zo kan bijvoorbeeld onduidelijkheid optreden over wie verantwoordelijk is voor de coördinatie van die nakomende testen, of wordt deining veroorzaakt door ‘bugs’ die bij nader inzien toch geen bugs blijken te zijn. De testmanager zal er in deze situaties op aan moeten sturen dat de opdrachtgever een keuze maakt tussen het beëindigen en het voortzetten van het testen. Bevindingmanagement Een vraagstuk dat zich voordoet bij de uitvoering van testen, is hoe moet worden omgegaan met bevindingen die tijdens de testen naar voren komen. Het volume aan bevindingen kan groot zijn, door bijvoorbeeld het veelvuldig aanpassen van de inrichting van de applicatie aan de dynamiek van de organisatie, of het parallel laten lopen van meerdere testtrajecten. In die gevallen is een goede procedure nodig om te waarborgen dat de juiste prioriteiten worden gesteld en het overzicht wordt gehouden over de voortgang van de verwerking ervan. Door track-and-trace van bevindingen kan snel worden bepaald wat de actuele stand van zaken is. Niet alleen aan het einde van de testperiode, maar ook gedurende de uitvoeringsfase is er immers behoefte aan managementinformatie over de voortgang en resultaten van de testen.

379

5

Bevindingen die tijdens het testen naar voren komen, kunnen globaal worden ingedeeld in vier prioriteitsgroepen (figuur 5). Daarbij is het moment waarop de bevinding opgelost moet zijn bepalend.


4 3 1

2

380 Release X

Acceptatiemoment

Release X+1

LIVE-datum

1 = bevinding niet acceptabel, moet voor acceptatiemoment opgelost zijn 2 = bevinding acceptabel, mits opgelost tijdens nazorg --> bevinding is known error gedurende nazorg periode 3 = bevinding is acceptabel, wordt opgelost in volgende release --> known error, input voor release X+1 4 = bevinding is acceptabel en wordt niet opgelost --> known error voor release X

ontwerp realisatie test implementatie nazorg

Figuur 5 Categorisering van bevindingen in relatie tot herstelmomenten

Voor bevindingen met prioriteit 3 en 4 geldt dat wanneer release X+1 live gaat, de known errors uit de known error database kunnen worden verwijderd. Wanneer deze known errors niet worden opgelost, zullen ze immers via het testen van release X+1 weer boven tafel komen. Om te voorkomen dat er met het verwijderen van deze known errors belangrijke informatie verloren gaat, is het verstandig om dit te betrekken bij de testvoorbereiding. Wanneer de prioriteiten zijn bepaald, is het nodig om voldoende grip te houden op de afhandeling van de bevindingen. Hieraan zitten zowel plannings- als workflow-aspecten. Planningsaspecten, omdat de testmanager de beschikbare resources op een efficiënte manier moet inzetten zodat de onvolkomenheden tijdig verholpen worden. Bovendien zal hij tijdig moeten rapporteren wanneer de deadlines in gevaar komen. Bij grotere testtrajecten kunnen projectmanagementtechnieken en –tooling waardevol zijn. Daarnaast spelen ook workflow-aspecten een rol. Het kan immers zo zijn dat voor de oplossing van een bevinding diverse partijen een rol vervullen die achtereenvolgens (of

parallel aan elkaar) herstelwerkzaamheden verrichten. Wanneer het gaat om grote aantallen bevindingen, of een groot aantal interne en externe oplosgroepen, volstaat een eenvoudige spreadsheet niet meer, en zullen zwaardere instrumenten moeten worden ingezet. Het kan in dat kader interessant zijn om te bekijken in hoeverre hiervoor een servicemanagementapplicatie kan worden ingezet. Het afhandelen van de bevindingen uit de testen vertoont immers grote gelijkenis met een incidentmanagementproces.

TESTEN EN VERWACHTINGEN Testers en eindgebruikers kunnen bij een outof-the-box-applicatie een totaal andere verwachting hebben van de functionaliteit omdat ze zich een beeld vormen op basis van de vorige situatie. Testen is hét moment binnen een implementatie waarop eventuele onduidelijkheden, communicatiefouten, interpretatieverschillen en blinde vlekken in het voortraject cumuleren tot een mismatch tussen resultaat en verwachting. Het testproces wordt sterk geoptimaliseerd wanneer men in staat is deze kloof (‘GAP’) tussen werkelijkheid en verwachting te verkleinen. Om dat te bereiken is het noodzakelijk om dieper in te gaan op de achtergronden van dit probleem.



Verwacht resultaat 5 Ervaren resultaat

1

Opgeleverd Informatiesysteem

381

4

Rapportage over systeemeigenschappen

3 Architectuurontwerp 2 Interpretatie klant-wens Figuur 6 GAP-model

Hiervoor wordt in deze testmethode een variant van het GAP model [Zeithaml & Bitner, 1996] gebruikt, waarmee het verschil tussen ‘beleefde’ en ‘verwachte’ kwaliteit wordt verklaard (figuur 6). GAP 1: Verschil tussen verwachting van de klant en de interpretatie door de leverancier Het eerste verschil heeft betrekking op de verwachtingen van de klant versus de interpretatie daarvan door de leverancier. In het voortraject is men blijkbaar niet in staat geweest een zelfde beeld te krijgen over wat de opdracht precies inhoudt en aan welke criteria het resultaat dient te voldoen. Oorzaken daarvoor kunnen bij de leverancier gezocht worden (onvoldoende inspanning om de wensen boven tafel te krijgen, niet klantgericht genoeg, eigen interpretatie niet getoetst, et cetera), maar ook de klant gaat niet altijd vrijuit (niet in staat de wensen expliciet en eenduidig te formuleren, bijstellen wensen naar aanleiding van ‘voortschrijdend inzicht’, et cetera). Oplossingen moeten worden gezocht in het extra investeren in afstemming van de resultaatverwachtingen. Zo kan het toetsen van de verwachtingen veel ellende besparen. GAP 2: Vertaling van requirements naar architectuurontwerp Het tweede gat ligt geheel aan de kant van

de leverancier. Het wordt veroorzaakt doordat de leverancier een ontwerp heeft gemaakt van een architectuur waarmee de requirements niet kunnen worden gehaald. Denk hierbij bijvoorbeeld aan de capaciteit van computerapparatuur of verbindingen daartussen die ontoereikend zijn voor de overeengekomen responsietijden. Of aan versies van softwarecomponenten die niet met elkaar kunnen samenwerken. Om dit te voorkomen, zou de leverancier zijn ontwerp kunnen laten toetsen door een deskundige buiten zijn projectgroep of door een onafhankelijke derde partij. GAP 3: Inrichting informatiesysteem Helaas is een goed ontwerp geen garantie voor een goed eindresultaat. In het proces van ontwerp naar realisatie kunnen nog veel dingen mis gaan die er uiteindelijk voor zorgen dat het resultaat niet overeenkomstig de verwachtingen is. Zaken waar de implementator op stuit bij de uitrol van out-of-the-boxapplicaties zijn bijvoorbeeld: fouten bij het vullen van de gegevensverzamelingen, bugs in software en slechte kwaliteit van overige infrastructuurcomponenten.

5

Gap 4: Rapportage eigenschappen informatiesysteem De verwachtingen van de klant kunnen worden beïnvloed door de rapportage die de leverancier oplevert over het resultaat van z’n


382

werk. Welke requests for change er bijvoorbeeld in de nieuwe release zijn meegenomen, en welke known errors er na de systeemtest van de leverancier nog in de applicatie zitten. Op het moment dat de rapportage afwijkt van de werkelijke systeemeigenschappen, en de leverancier de zaken bijvoorbeeld te rooskleurig voorstelt, vergroot dat de kloof tussen de verwachtingen van de klant en zijn ervaringen tijdens de testen. GAP 5: Ervaren versus verwachte resultaat De kloof tussen het verwachte resultaat en de beleving van het resultaat tijdens de testen zal er voor zorgen dat het resultaat in de beleving van de klant mee- of tegenvalt. Centrale gedachte in het GAP-model is, dat wanneer de GAPs 1 t/m 4 zijn gedicht, ook GAP 5 is verdwenen. Er is dan sprake van de ideale situatie waarin het testen is teruggebracht tot een overbodige handeling. Vanzelfsprekend is dit een zuiver academische situatie, die helaas niet overeenkomt met de weerbarstige praktijk. De meerwaarde van dit model is echter dat het inzichtelijk maakt waar de oorzaken van geconstateerde GAPs uit voortkomen. Met die kennis kan tevens worden bepaald op welke punten er nog verbeteringen zijn te realiseren. Moet er in het voortraject meer geïnvesteerd worden om de wensen van de klant helder te krijgen? Kunnen tussentijdse demonstraties nuttig zijn om de verwachtingen van de klant te managen? Zo kan met een analyse van de pijnpunten een besturingscyclus in gang worden gezet waarbij allereerst in de testfase de feitelijke GAP wordt gemeten, vervolgens naar aanleiding van de GAP-analyse een reeks verbeteringen wordt doorgevoerd, en tenslotte bij de test van de volgende release opnieuw een meting wordt gedaan.

CONCLUSIE EN AANBEVELINGEN Het is een feit dat testtrajecten aan het veranderen zijn, of eigenlijk moeten veranderen, omdat een overgang van maatwerk- naar out-of-the-box-applicaties een trend is. Risico’s met betrekking tot software-fouten

zijn hierdoor geringer. De IT-infrastructuur wordt echter steeds complexer door het integreren van applicaties in ketens in het kader van end-to-end servicemanagement. De testmethoden met als oorsprong softwareontwikkeling voldoen niet meer. De vernieuwde testmethode is minder op software en meer op exploitatie gericht, en sluit bovendien beter aan bij een ITILgerichte beheerorganisatie. Het testen kan worden ingebed in de bestaande processen zoals het wijzigingsproces. Maar nog beter is het testen te beschouwen als afzonderlijk proces. Door middel van een proces krijgt het testen de aandacht die nodig is. De kennis en kunde binnen het proces kunnen worden behouden en uitgebreid. Het procesgericht managen van de bevindingen draagt eveneens bij aan een efficiënte verbetering van de applicatie. Met de kennis uit het bevindingenmanagement kan niet alleen het testproces verbeteren, maar nog belangrijker het wijzigingsproces of het implementatieproject. Hiermee wordt de bron aangepakt en daardoor kan het testen nog efficiënter worden. Een belangrijke valkuil bij het opzetten van een testproces is overdadig testen zonder dat de risico’s bekend zijn. Daarom is de belangrijkste vernieuwing om samen met de leverancier van out-of-the-box-applicaties tot een efficiëntere aanpak van het testen te komen. Het testproces moet gericht zijn op het verkleinen van het verschil tussen verwachting van de klant en de interpretatie door de leverancier. De GAP-analyse is specifiek voor out-of-the-box-applicaties toepasbaar omdat de functionaliteit van de applicatie van tevoren vaststaat en verkeerde verwachtingen funest zijn voor een efficiënt testproces. Een efficiënte procesaanpak begint met een juiste inschatting van de exploitatierisico’s, de ingebrachte kennis van de leverancier en een stabiele applicatie zodat de juiste testen efficiënt kunnen worden uitgevoerd.



Ir. Cees Eveleens is werkzaam bij Mansystems en als testmanager verantwoordelijk voor de testfase bij implementatie-trajecten. In die hoedanigheid is hij betrokken bij grote implementaties van onder meer ExpertDesk Service Management. Ing. Ron Bovee is hoofd van de afdeling Business Consultancy bij Mansystems. Als gecertificeerd ITIL Service Manager en grondlegger van Operations Management schreef hij al vele artikelen in het IT Beheer Jaarboek.

383

LITERATUUR • Boehm, B.W. Software Engineering Economics, Prentice Hall, 1981. • Bon, Jan van, Georges Kemmerling en Dick Pondman. IT Service Management, een introductie, Van Haren Publishing, 2004. • Bovee, Ron, en Marco Ruwaard. Operationsmanagement, een nieuw proces, Mansystems Nederland B.V., 2001. • Pol, Martin, Ruud Teunissen en Erik van Veenendaal. Gestructureerd testen: een introductie tot TMap®, Tutein Nolthenius, 1998. • Spillner, Andreas. Tilo Linz en Martin Pol. Testen volgens ISEB, Tutein Nolthenius, 2004. • Veenendaal, Erik P.W.M. van. ‘Checklist gestructureerd testen’, Checklist Informatiemanagement, aflevering 29, 1999. • Veenendaal, Erik P.W.M. van en Ton Dekkers. ‘Testpointanalysis: a method for test estimation’, Project Control for Software Quality, Shaker Publishing BV, Maastricht, The Netherlands, 1999. • Zeithaml, V.A., en M.J. Bitner. 'Services Marketing’, McGraw-Hill Series in Marketing, McGraw-Hill, 1996.

5



Bij de implementatie van out-of-the-box-applicaties mag men

Recommend Documents