MAGAZINE VOOR DE NEDERLANDSE TESTER

TESTKRANT

Visual management

Meer resultaat en plezier met Kanban

Erik van Veenendaal Jeroen MengerinkBryan Bakker

Derk-Jan de Grood

Jaargang 2012 - Editie 1

Gratis magazine van TestNieuws.nl - Meer info op www.testkrant.nl

MAGAZINE VOOR DE NEDERLANDSE TESTER

En ook artikelen van

binnen de testafdeling

2 TestKrant - Jaargang 2012 - Editie 1 www.testkrant.nl

bekeken. Na de nodige mislukte pogingen kreeg ik het onder de knie en op een gegeven moment begon ik er zelfs plezier in te krijgen. Vanaf dat moment wist ik dat het goed zou komen. Na de heel wat spreekwoordelijke bloed, zweet en tranen ben ik dan ook heel trots dat ik, zij het iets later dan gepland, de eerste editie van de TestKrant mag aankondigen.

In deze editie vinden jullie allereerst het hoofdartikel van Derk-Jan de Grood over Kanban. In verhaalvorm vertelt hij hoe drie managers samen ontdekken hoe visual management meer plezier brengt en het testen kan ondersteunen. Dan volgt Bryan Bakker met een ervaringsverhaal over Model Driven Development en de impact die het gebruik van formele modellen heeft op het testen. Zijn testers wellicht overbodig als de software wordt gegenereerd? Verder een artikel van Jeroen Mengerink waarin hij enkele situaties beschrijft die aangeven waar de toenemende vraag naar technische testers vandaan komt. Het laatste artikel is van Erik van Veenendaal over het langverwachte ISTQB advanced level. Hij geeft onder andere een volledig overzicht van de bijbehorende syllabus, door sommige al het ISTQB kroonjuweel genoemd.

Hoewel ik al behoorlijk trots ben op deze eerste editie kan het natuurlijk altijd beter. Dus hebben jullie opmerkingen, aanmerkingen, suggesties, tips, pluimen, complimenten of uitzinnige lofbetuigingen, dan hoor ik dat graag. Mail ze dan naar [email protected]. Ook artikelen voor de volgende editie kunnen jullie naar dit adres mailen. Wanneer de volgende editie uitkomt weet ik nog niet, dat hangt mede af hoe deze eerste editie door jullie wordt ontvangen.

Ik wens jullie veel leesplezier en uiteraard ook een fijne zomervakantie toe. Groet,Marco van der Spek

VoorwoordEen aantal maanden geleden bedacht ik dat er een Nederlandstalig glossy magazine voor testers moest komen. Naast het feit dat zo'n blad er namelijk nog niet was, is TestNieuws met 100.000 bezoekers per jaar ook nog eens het uitgelezen platform om zo'n magazine te lanceren. Het plan was dat de artikelen werden aangeleverd door de Nederlandse testcommunity, waarna ik alles zou samenvoegen tot een mooi magazine. Dat laatste bleek toch iets meer voeten in de aarde te hebben dan gedacht.

Na het uitschrijven van de "call for papers" kwamen de artikelen inderdaad binnen en kon het opmaken beginnen. Maar dat was toch wel even andere koek dan een powerpoint of factsheet in elkaar knutselen. Gelukkig leer ik snel en kreeg ik een hoop hulp van mijn grootste "vriend" Google. Alle in ons huis aanwezige bladen dienden op een gegeven moment als inspiratiebron. Van de Computer Totaal tot de Linda, ja zelfs de Donald Duck heb ik met andere ogen

Inhoudsopgave Voorwoord door Marco van der SpekMeer resultaat en plezier met kanban door Derk-Jan de GroodModel Driven Development en de impact op testen door Bryan BakkerAdvertentie Test4gold door SQSGroeiende vraag naar technische testers door Jeroen MengerinkISTQB Expert Level ‘Verbeteren van het Testproces’ door Erik van Veenendaal

2 3 9141519

Meer resultaat en plezier met kanbanDoor Derk-Jan de Grood


Visual management binnen de testafdeling

Het is vrijdagmiddag Simon, Suzanne en Maik hebben afgesproken bij het whiteboard. Zij willen weten of kanban waarde heeft voor hun testafdeling. Suzanne denkt aan de rol met bruin papier die beneden ligt, kijkt naar de post-its in haar hand en besluit dat ze deze net zo goed op het whiteboard kunnen plakken. Ze pakt de stift en schrijft op het bovenste post-it: Kanban binnen onze testafdeling. Ze plakt hem midden op het whiteboard en kijkt haar collega’s aan. “Zo goed? “. Maik corrigeert haar. Eigenlijk is het niet “kanban”, maar “visual management” legt hij uit.


bottlenecks en verbeteringen te sprake. Door deze te verzamelen, raken ze niet verloren en kunnen ze beheerst worden doorgevoerd.“ “Goed, ik ben overtuigd” zegt Suzanne, ze schrijft een nieuwe post-it en plakt deze over de eerste heen: Visual Management voor testafdelingen.

Nu wordt het tijd voor het echte werk. Een goede brainstormsessie over de rol van visual management binnen testteams volgt.

Hieronder delen zij een paar van de conclusies:

Workflow? Dan kan kanbanKanban is toe te passen op veel verschillende processen. Eigenlijk is het toepasbaar zodra je een workflow hebt met een aantal vaste stappen die je doorloopt. Dat komt mooi uit want veel testafdelingen werken met een redelijk standaard workflow, die mogelijk zelfs in een algemene teststrategie is verwoord. Toch is het vaak moeilijk om overzicht te houden, omdat een afdeling werkt voor verschillende projecten met elk hun eigen projectmanagers.

Daarnaast worden testafdelingen vaak betrokken bij het testen van productieverstoringen of wijzigingen die buiten projecten omgaan.

K anban is een lean procesmanagement systeem dat erop gericht is om de flow te optimaliseren. Je gebruikt hiervoor een

een kanbanbord, dat kan bestaan uit een whiteboard met verschillende kolommen erop. Elk van de kolommen vertegenwoordigt een stap in het proces. Dit proces wordt ook wel de value stream genoemd”.

“Door middel van post-its worden taken op het bord geplakt. Elke post-it, of taak, maakt gedurende zijn levensloop een reis van de linker kolom op het bord (de back-log), door alle stappen in het proces naar de meest rechter kolom (afgeronde taken)”.

Suzanne voegt daar aan toe “In organisaties die kanban doen, wordt elke ochtend een meeting gehouden bij het bord. Hierbij zijn alle teamleden betrokken. Kanban helpt om het werk te verdelen, maakt inzichtelijk waar de bottlenecks zitten en zorgt voor een optimale afhandeling van werkpakketten”.

“Dat is precies wat we willen!”, roept Simon enthousiast, “Een betere beheersing van de testtaken en het vergroten van onze efficiëntie. Onze testafdeling heeft veel taken. We moeten reviewen, testen ontwerpen en uitvoeren, regressietesten uitvoeren. We werken aan verschillende projecten en releases en er loopt er een TPI traject. De business staat geregeld op de drempel met wijzigingen of productieverstoringen. Een betere grip op onze activiteiten, dat klinkt goed. Daarbij ook nog kostbare testtijd besparen klinkt nog beter !”.

Maar, Maik is nog niet klaar: “Bij visual management maken we gebruik van kanban, maar naast het kanbanbord hebben we nog twee andere borden. Dit zijn het keek op de week en verbeterbord.

Op het keek op de week bord wordt de stuurinformatie bijgewerkt. Aan de hand van een aantal dashboards wordt bijgehouden wat de productie van het team is. Dit bord wordt gebruikt om de effecten van beslissingen en verbeteringen inzichtelijk te maken, maar maakt tevens de waarde van het team zichtbaar.

Op het verbeterbord worden verbeterideeën vastgelegd. Omdat het hele team rond het bord staat en de voortgang bespreekt, komen er vaak

Betere beheersing van de testtaken en het vergroten van onze efficiëntie

Bestelling geplaatst

Betaald Verstuurd Afgeleverd

Sander knikt instemmend. “Overzicht houden is een probleem op onze testafdeling. We houden ons bezig met:

• Review van specificaties• Opstellen van testgevallen• Uitvoeren van testgevallen• Hertesten van opgeloste bevindingen• Uitvoeren van regressietesten• Assisteren bij productieproblemen• Doorvoeren van changes• Wegwerken van testautomatiseringsbacklog• Testverbeteringen en –innovaties

Dat zijn erg veel verschillende taken om het overzicht op te houden”.

Kanban helpt om een goed overzicht te houden op al deze activiteiten. Door de activiteiten te chuncken in kleinere werkpakketten, kan op het kanbanbord worden bijgehouden welke activiteiten onderhanden zijn of worden afgerond. Het overzicht maakt het mogelijk om een balans te houden tussen:

• hoge en lage prioriteit functies, • operationele- en projectactiviteiten• testverbeteringen en -innovaties en operationele activiteiten.

Flow boven utilisatieKanban is gebaseerd op de theory of constrains (TOC). TOC richt zich op een maximale throughput door het verwijderen van bottlenecks. Van oorsprong is dit toegepast op fabricageprocessen, waar, als je op utilisatie stuurt, elk van de teams hun deelproducten de workflow in drukken. Als er echter een bottleneck in het fabricageproces zit, bijvoorbeeld bij de integratie, ontstaan er grote stapels deelproducten en loopt het proces vast. Er worden geen extra eindproducten verkocht. Veel traditionele managers sturen nog op utilisatie en “we betalen je om te werken” is hun motto. Zo zorgen ze ervoor dat iedereen maximaal bezig is.

Door het accent te verleggen van utilisatie naar flow, ontstaat er oog voor de bottlenecks. De focus verlegt zich naar het maximaliseren van het aantal afgeronde producten. Deze vertegenwoordigen businesswaarde. Er ontstaat een pull in plaats van een push waarbij in dit voorbeeld de integratie-afdeling aangeeft hoeveel deelproducten ze kan verwerken. Binnen kanban werken we daarom met WIP-limieten.


WIP staat voor ‘work in progress’ en de WIP-limiet geeft aan hoeveel taken een team kan verwerken.


Dat mag; immers we weten

dat onze doorlooptijd

optimaal is.

Als er voldoende deelproducten gemaakt zijn, zit een teamlid misschien eventjes niets te doen.

“Dit principe is natuurlijk prima te

vertalen naar de eerdergenoemde

testactiviteiten”, legt Suzanne uit,

“De maximale flow levert een maximaal aantal geteste systeemonderdelen, changes, bugs of afgedekte risico’s op die naar productie kunnen”.

WIP-limieten

Het is adaptiefBij kanban leg je niet alles van te voren vast, je bent dus als team zeer adaptief. Je kunt dus optimaal meebewegen als de inhoud van de releases wordt aangepast, de functionaliteit wijzigt of het team moet bijspringen bij productie-verstoringen.

Dit maakt dat het team echt risicogebaseerd kan werken. Elke dag wordt er opnieuw bepaald welke risico’s aangepakt moeten worden. Nieuwe inzichten kunnen meteen worden meegenomen en het kanbanbord helpt daarbij om de resources te managen. Zo kunnen taken in de ‘priority lane’ worden geplaatst, en met zeer veel spoed worden afgehandeld. De impact van wijzigingen wordt direct inzichtelijk. Omdat ook het management bij de daily meetings betrokken is, wordt duidelijk wanneer inzet ten koste gaat van geplande verbeterslagen.


Grotere zichtbaarheid en betere samenwerkingDaarnaast triggert kanban een grotere zichtbaarheid en een betere samenwerking. Met het bord als de nieuwe hang-out plaats, worden de testers binnen het competence center uitgedaagd om elkaar te helpen. Met zijn teamgenoten kan hij bespreken wat er nodig is om zijn taak zo snel mogelijk af te ronden. Maar het kan lonen om ook andere disciplines uit te nodigen bij de standing meetings. Suzanne: “Ik sprak recent een klant van ons over dit voorstel en hij vertelde dat hij liever de testers laat aanschuiven bij de daily meetings van het ontwikkelteam”. “Een goed idee”, reageert Simon, maar binnen zijn organisatie wordt agile ontwikkeld. Dat gaat niet op voor de testafdelingen die werken in meer traditionele organisaties, zoals de onze. In deze organisaties levert het veel betrokkenheid op als je iemand van de business, de releasemanager of iemand van het ontwikkel-team uitnodigt bij het kanbanbord van de testers.”

Het is belangrijk om als testafdeling je toegevoegde waarde voor de business zichtbaar te maken. Samenwerken is perfect hiervoor, omdat de mensen met wie je samenwerkt als geen ander weten welk verschil je maakt. Daarnaast is het belangrijk om een goed ‘testverhaal’ te vertellen.

Visual management is een in de schoot geworpen tool om dit te doen. De borden maken zeer inzichtelijk wat er gebeurt. Een manager kan elk moment van de dag naar een van de borden lopen en zelf zien wat de status is. Visual management zorgt ervoor dat ook anderen weten wat er gebeurt. Geïnteresseerden kunnen met eigen ogen zien, welk werk klaar is en wat er nog open staat. Dit bevordert betrokkenheid en betrekt belang-hebbenden in de besluitvorming.

Meer plezier, van workflow naar personal flow“Hebben jullie weleens in de flow gezeten?”, vraagt Maik ineens. Suzanne en Simon kijken elkaar aan. Dit is een onverwachte vraag. Ze zitten graag in de flow en dat weten zij van elkaar. Ze zoeken elkaar niet voor niets op voor brainstormsessies zoals die van vandaag. Blijkbaar is dit voor veel mensen een relevante vraag omdat flow niet voor iedereen vanzelfsprekend is. Maik licht zijn vraag toe:

“Veel mensen zitten in de flow als ze bezig zijn met hun hobby, niet op hun werk. Werken met lean, kanban en visual management zorgt ervoor dat mensen positief worden uitgedaagd. Ze hebben een plek in het team en komen veel sneller in de flow.”

Simon fronst niet begrijpend zijn wenkbrauwen, maar voordat hij kan vragen hoe dat dan komt, neemt Susanne het woord. “Als je met kanban werkt, dan werk je samen. Het hele team werkt aan een gemeenschappelijk doel. Teamleden worden hierdoor ingezet op die dingen waar ze sterk in zijn en kunnen hierdoor meer zichzelf zijn. Je krijgt meer verantwoordelijkheid en hebt veel autonomie. Daarnaast krijg je directe feedback over je prestaties. Het bord maakt zichtbaar wat je hebt bereikt”

“Ja, en zo wordt de workflow een persoonlijke flow”, zegt Maik, “Dit werkt stimulerend en maakt dat teams beter presteren en meer plezier hebben in hun werk”. “Meer resultaat en meer plezier?” vat Simon het betoog samen. Maik en Suzanne knikken bevestigend.


“Welke manager wil dat zijn team onthouden?” Maik, Simon en Suzanne in ieder geval niet. Enthousiast geven ze elkaar een high-five. Tevreden met het resultaat van deze eerste brainstorm maken ze een foto van het whiteboard. “We moeten meer mensen in deze discussie betrekken”, stelt Simon, “we moeten nog veel leren, maar hiermee kunnen we vast meer halen uit onze bestaande testprocessen.”

Derk-Jan de Grood werkt als testexpert bij Valori. Hij adviseert organisaties bij het inrichten en verbeteren van hun testactiviteiten. Als productmanager werkt hij aan innovaties in het Valori dienstaanbod. Daarnaast spreekt en publiceert hij met groot enthousiasme over ontwikkelingen in het testvak.

Bij mijn werkgever worden meerdere projecten uitgevoerd met behulp van Analytical Software Design (ASD) [1]. Deze suite biedt software engineers de mogelijkheid delen van software te generen aan de hand van formele modellen, het zogenaamde Model Driven Development (MDD). Het aantal fouten in deze gegenereerde code zou aanzienlijk kleiner moeten zijn dan in zelf geschreven code. Wat is de impact van model driven development op het test traject? Zijn testers overbodig als de software wordt gegenereerd?

Model Driven Development en de impact op testen

Door Bryan Bakker



in het design (het model) gedetecteerd en aan de ontwikkelaar gerapporteerd. Deze kan de fouten vervolgens in het model oplossen. Pas als alle fouten uit het design verwijderd zijn, is het mogelijk de code (in verschillende talen) te laten genereren. De code correspondeert met het wiskundige model en is daarmee ook vrij van deadlocks, race-conditions etc. In onderstaand figuur is dit proces schematisch weergegeven.

Niet alle software die bij het redesign werd aangepakt is gegenereerd. Alleen kritieke en complexe onderdelen zijn op deze manier afgehandeld. ASD is uitermate geschikt voor het modelleren van constructies als state machines, gedrag beschreven met behulp van message-sequence-diagrams of complexe algoritmen. Ook communicatie vanuit software richting firmware of hardware is op deze manier te modelleren. De methode is daarmee zeer geschikt voor technische systemen, waar dergelijke constructies veel gebruikt worden, maar is zeker ook toepasbaar in andere omgevingen.

Naast de software bevat het systeem nog andere disciplines zoals mechanica, elektronica en optica. De functionaliteit van deze disciplines is niet op deze manier gemodelleerd, dus uiteindelijk is slechts een klein (maar kritiek) gedeelte van het systeem gemodelleerd. Wat betekent dit voor de test activiteiten in het project?

Bij een van onze klanten wordt de methode van model driven development gebruikt bij het ontwikkelen van software voor

elektronen microscopen. Deze microscopen bieden een veel hogere vergrotingsfactor dan traditionele licht microscopen. Het is zelfs mogelijk om atoomstructuren zichtbaar te maken. Een belangrijk onderdeel van een dergelijk systeem is het vacuüm, dat nodig is voor het transport van de elektronen. Deze moeten zonder verstoring het specimen (object dat vergroot wordt) bereiken. Dit vacuüm subsysteem bestaat uit verschillende pompen, kleppen en meters om vacuüm te creëren en in stand te houden. Deze onderdelen worden aangestuurd door complexe software. In een recent project werd dit subsysteem onderworpen aan een redesign, hiervoor werd MDD gebruikt.

Bij model driven development definieert de software ontwikkelaar het design van de software in modellen. De modellen moeten nauwkeurig gespecificeerd worden. Ook moeten ze volledig zijn en mogen geen fouten bevatten, zoals bijvoorbeeld deadlocks. Niet alleen het zogenaamde ¨goed weer¨ gedrag moet worden gemodelleerd, ook het ¨slecht weer¨ gedrag maakt onderdeel uit van de modellen. Dit model wordt automatisch geconverteerd naar een formeel wiskundig model. Op dit wiskundige model worden verschillende (automatische) verificaties uitgevoerd. Zo worden mogelijke deadlocks, race-condities of starvations

Model:- Precise- Complete- Correct

Formal modeland verification

Source code:- Java- MISCRA C- C++- C#

Generateformal model

Genrate defectfree source code

from verified model

Designerrors

Guaranteedequivalence

De functionele verificaties op systeem niveau (software en alle andere disciplines) moeten nog steeds gebeuren, of er nu wel of niet delen van de software zijn gegenereerd. In de modellen kunnen functionele fouten zitten, die zo ook in het systeem terecht zijn gekomen. Model driven development helpt hier niet direct bij, immers functioneel gedrag wordt niet automatisch geverifieerd. Hierbij geldt het “rubbish in = rubbish out” principe. Reviewen en executeren van de modellen voordat code wordt gegenereerd kan hier wel aanzienlijke verbeteringen brengen. Dit is vergelijkbaar met het reviewen van design documentatie. Test activiteiten op integratie vlak tussen software componenten onderling en tussen software en andere disciplines zijn ook nog steeds hard nodig. Juist de integratie tussen gemodelleerde componenten (met gegenereerde code) en niet gemodelleerde componenten (met “handwritten code”) is zeker niet triviaal. Model driven development heeft daarentegen wel grote invloed op de test activiteiten die normaalgesproken door de ontwikkelaars zelf worden uitgevoerd: de component testen. De component testen die gericht zijn op de structuur van de code (white box) controleren op onder andere de aanwezigheid van


programmeerfouten. Deze zullen door de aanpak van MDD niet meer aanwezig zijn in de gegenereerde code, althans dat is het idee. Component testen zijn dus in principe overbodig voor gegenereerde code. Eventuele black box aspecten van component testen zijn overigens nog wel waardevol. MDD heeft dus grote invloed op de testen van de ontwikkelaars. Blijven de overige test activiteiten dan exact hetzelfde? Nee, zeker niet.

Gedurende de functionele verificaties zijn we de nodige problemen tegengekomen. Deze problemen waren terug te voeren op bijvoorbeeld onduidelijke requirements of voortschrijdend inzicht. Functionele testen zijn dus nog steeds zeer nuttig. Daarnaast hebben we uitgebreide reliability testen op systeem niveau uitgevoerd. Dus zowel de software als alle hardware werden met het testen meegenomen. Deze testen waren gericht op de wijzigingen in het system (het redesign). Al vrij snel kwamen we problemen in de hardware tegen, zoals slijtage van oudere onderdelen en onverwacht grote variatie in mechanische onderdelen. In vergelijkbare voorgaande projecten waarbij geen gebruik was gemaakt van MDD duurde het vele malen langer voordat dergelijke hardware problemen werden


nu wordt gerealiseerd met behulp van model driven development, dan zal er op de x-as van de impact niets veranderen. De impact van mogelijke fouten in component 1 blijft uiteraard exact gelijk. De likelihood daarentegen zal kleiner worden als component 1 met MDD wordt ontwikkeld en niet op de traditionele manier. Zo is het mogelijk dat component 1 in een ander kwadrant komt en op een andere manier getest kan worden.

De kwaliteit van componenten ontwikkeld met MDD zullen naar verwachting (veel) minder programmeerfouten bevatten. Dit was in het hier beschreven project direct zichtbaar. De test engineers kunnen hun aandacht en tijd vervolgens

gevonden door reliability testen. Eerst werden talloze software problemen gevonden die allemaal geanalyseerd en opgelost moesten worden voordat het testen verder kon gaan. Pas in een veel later stadium, als de belangrijkste software problemen op het gebied van reliability opgelost waren kon er ook iets over hardware gezegd worden.

Met de nieuwe aanpak zijn we dus in staat veel eerder de reliability daadwerkelijk te meten, in plaats van weken lang testen uit te voeren, problemen te vinden, te analyseren en op te lossen.Sterker nog: er is geen enkel reliability issue in de gegeneerde code gevonden tijdens deze testen.

Een opmerkelijk resultaat. Want juist dit soort reliability issues, zoals deadlocks en/of race-conditions, veroorzaken vaak grote problemen gedurende projecten. Zeker als dergelijke problemen pas laat naar boven komen. Het redesign in deze case was onderdeel van een veel groter project, maar heeft dit project niet verstoord. Ook al betrof het een zeer grote wijziging.

Zoals gezegd zijn de meeste testactiviteiten nog steeds noodzakelijk, maar MDD heeft ook op deze activiteiten invloed. Dit is mooi te zien met behulp van de Product Risico Analyse (PRA), bekend van TMap en ISTQB. In onderstand figuur is een voorbeeld van een PRA te zien. Als component 1

MDD heeft grote invloed op het test traject, testen blijft echter nog steeds noodzakelijk.

Could test Must test

¨Won´t test¨ Should testImpact

Like

lihoo

d

15

9

33 9 15

Comp1

MD

D

Comp2 Comp3


[1] Voor meer informatie over ASD, Analytical Software Design, zie www.verum.com.

beter op andere testactiviteiten richten, gekoppeld aan hogere risico klassen.

Door voortschrijdend inzicht zijn er toch wijzigingen aangebracht aan het ontwerp van het vacuüm subsysteem. Het model stelde de ontwikkelaars in staat deze wijzigingen snel aan te brengen met behoud van de kwaliteit. De modellen worden immers meteen (automatisch) geverifieerd op (programmeer) fouten. MDD past dan ook uitstekend in projecten die op een Agile manier worden uitgevoerd.

MDD heeft grote invloed op het testtraject. Testen blijft echter nog steeds noodzakelijk. De ontwikkelaarstesten kunnen drastisch worden ingekort. Testen op integratie niveau en hoger blijven belangrijk, maar kunnen op een andere manier worden ingevuld. Dit past uitstekend in de aanpak van risk based testen (PRA). Daarnaast is in deze case duidelijk geworden dat MDD een zeer positieve invloed heeft op de reliability van de (gegenereerde) software. Alleen dit voordeel is voor systemen die een hoge reliability eisen al reden genoeg om MDD serieus te overwegen.

Als gevolg van deze positieve ervaring met MDD worden op dit moment bij de klant meerdere redesigns op dezelfde manier uitgevoerd.

Bryan Bakker is werkzaam bij Bij Sioux Embedded Systems (www.sioux.eu). In 1998 is hij afgestuurd aan de TU Eindhoven (Technische Informatica).

Bryan heeft enkele jaren gewerkt als software engineer, en heeft zich daarna gespecialiseerd op het testen van embedded software in multidisciplinaire omgevingen (software, mechanica, elektronica, optica) bij hightech bedrijven in bijvoorbeeld de medische sector, professionele beveiligingssystemen, semi-industrie en nano technologie.

Daarnaast geeft Bryan regelmatig cursussen en lezingen op (internationale) congressen.

Drie uitdagende games vormen de basis voor de Test 4 Gold competitie. Allemaal

vragen ze verschillende skills die de basis vormen voor een succesvolle carrière als

software tester. Ben je snel van begrip, analytisch en heb je een goed geheugen?

Test jezelf en kijk of jij bij de nummer 1 in testen past.

www.test4 gold.nl

Laat zien hoe goed jij bent in testen Win een reis naar de Olympische Spelen 2012 in Londen

DOE MEE!www.test4gold.nl

De wereld verandert en dat brengt andere eisen aan testers met zich mee. Vooral het technische aspect van testen komt steeds meer naar voren. De snelle opkomst van cloud computing zorgt ervoor dat veel functionaliteit uit de cloud kan worden afgenomen. Naast het testen bij de business of deze functionaliteit de processen goed ondersteunt, is ook technisch testen nodig. Om de functionaliteit te integreren met bestaande systemen, zal namelijk een technische koppeling nodig zijn. Daarnaast zal voor het monitoren van de correcte werking in productie testautomatisering ingericht moeten worden, waar ook weer technische testers voor nodig zijn.

Groeiende vraag naar technische testers

Door Jeroen Mengerink



De andere grote “hype” die meespeelt bij de vraag naar technische kennis is Agile. Door het inzetten van multidisciplinaire teams,

Het is belangrijk om mee te kunnen discussiëren

komt de tester dichter tegen de ontwikkelaar aan te zitten. De communicatie tussen deze partijen, die voorheen vooral via uitgebreide documentatie liep, zal nu direct plaatsvinden. Om deze communicatie soepel te laten verlopen, zullen de ontwikkelaars wat van testen moeten weten, maar zullen de testers dus ook kennis van ontwikkelen nodig hebben. Het iteratieve en incrementele karakter dat Agile heeft, vraagt ook om het steeds vaker uitvoeren van een regressietest. De noodzaak voor testautomatisering neemt hierdoor ook toe.

In dit artikel beschrijf ik voor cloud, Agile en testautomatisering enkele situaties die aangeven waar de vraag naar technische testers vandaan komt

CloudMeer en meer bedrijven nemen diensten af uit de cloud, denk hierbij aan e-mail, CRM of zelfs hele omgevingen. Al deze diensten worden via het internet benaderd en moeten geïntegreerd worden in de huidige bedrijfsprocessen. Het testen of de communicatie met deze cloud services goed gaat is een technische bezigheid. Er zal goed gekeken moeten worden naar het berichtenverkeer, wat zonder GUI vaak beter bekeken kan worden.

Het gebruik van cloud services heeft ook grote invloed op interne ontwikkeltrajecten. Wanneer ketens getest moeten worden vanwege interne aanpassingen, is het veelal ongewenst om dit te doen terwijl de koppeling met de (live) cloud service actief is. In deze gevallen zal dus een stub of mock gemaakt moeten worden, zodat de cloud service gesimuleerd kan worden en de processen getest kunnen worden zonder de productieversie van de cloud service te raken.

In het geval van afspraken of contracten met de leverancier over de prestaties van de cloud service zal in productie gekeken moeten worden of de leverancier zich wel aan zijn afspraken houdt. Er ontstaat dus vraag naar frequente (of zelfs continue) tests die het gedrag van de service kunnen monitoren.

Hiervoor is goede testautomatisering nodig, waar ik later in dit artikel op terugkom.

AgileBij Agile wordt uitgegaan van vier simpele basisprincipes:

• Mensen en hun onderlinge interactie boven processen en tools• Werkende software boven allesomvattende documentatie• Samenwerking met de klant boven contract-onderhandelingen• Inspelen op verandering boven het volgen van een plan

Dat onderlinge interactie belangrijk is, is te merken in de multidisciplinaire teams. De minder uitgebreide documentatie vereist dat de mensen in de teams goed met elkaar communiceren over wat ze aan het doen zijn. Om te kunnen begrijpen wat andere teamleden doen, zal enige kennis van de aanwezige vakgebieden nodig zijn. Vandaar dat van de testers verwacht wordt dat zij in ieder geval basis programmeerkennis en -vaardigheden bezitten. Het is belangrijk om mee te kunnen discussiëren over software architectuur en mogelijke oplossingen. De oplossingsrichting kan namelijk door de teams bepaald worden.

Door het kort-cyclische karakter zullen ook vaak tests uitgevoerd worden op producten die nog niet volledig af zijn. Hiervoor zal de tester vaak technische voorzieningen in moeten zetten. Denk, net als bij cloud, aan het gebruik van drivers, stubs of mocks. Het maken of inrichten van deze testondersteunende voorzieningen zal door de testers aangegeven (en bij voorkeur ook gerealiseerd) moeten worden.

In korte iteraties moet werkende software opgeleverd worden, die voortborduurt op opleveringen in eerdere iteraties. Elke iteratie komt er nieuwe functionaliteit bij, die in de volgende iteratie nog steeds moet werken. Ofwel, de regressietestset groeit gestaag en de tijd om de

tests uit te voeren is beperkt. Het regelmatig uit moeten voeren, samen met de tijdsdruk, levert een goede business case voor testautomatisering. Het goed nadenken over en inzetten van testautomatisering zijn vereisten voor een goed Agile traject.

Gezien de regelmatige opleveringen is het belangrijk om goed versie- en configuratie- management te hebben. Ook de testers zullen hier aan moeten bijdragen. Wanneer en hoe moet geïntegreerd worden en welke eisen worden aan de verschillende ontwikkelomgevingen gesteld? Technische kennis zal hier helpen om een beter en duidelijker beeld te krijgen van wat zal moeten gebeuren.

TestautomatiseringDat aan testautomatisering technische aspecten zitten is niet te ontkennen. Aangezien zowel bij cloud als bij Agile testautomatisering naar voren komt, is voldoende aanleiding om hier specifieke aandacht aan te besteden. Zeker gezien het feit dat ook in andere trajecten steeds meer vraag is naar testautomatisering.

Testautomatisering kan plaatsvinden op verschillende niveaus. De basis wordt gelegd in unit testen. Hoewel de unit tests over het algemeen door de ontwikkelaars gemaakt worden, betekent dit niet dat we hier als testers niets mee te maken hebben. De ontwikkelaars kunnen geholpen worden door het toepassen van structurele technieken, waar de testers over het algemeen meer kennis van hebben. Door middel van pair programming kan een tester hier ondersteuning bieden, door tijdens het maken van unit tests naast de programmeur te zitten om zo aan te geven welke testgevallen gemaakt moeten worden. Naast het helpen bij het opstellen, kunnen de unit tests natuurlijk ook gereviewd worden. Ook hier is weer kennis van en vaardigheden met programmeren nodig.

Functionele testautomatisering ligt meer bij de testers. In de Agile trajecten is te zien dat de grafische interface regelmatig aangepast wordt, om de automatisering robuust te houden zal deze moeten plaatsvinden op de laag eronder. Het aanroepen van functies zonder de grafische interface te gebruiken, vereist kennis van de manier waarop geprogrammeerd is. Wanneer toch automatisering gemaakt wordt die de grafische


interface gebruikt, zal deze op enige manier aangeroepen moeten worden. Hoewel het weinig technisch werk lijkt doordat bijvoorbeeld Fitnesse [1] of Cucumber [2] gebruikt kan worden door de testers, zal toch enig programmeerwerk nodig zijn. Het aanspreken van het testobject kan namelijk alleen maar wanneer voor Fitnesse en Cucumber een interpretatielaag aanwezig is. Meestal voldoen de standaard meegeleverde mogelijkheden niet en moet aanvullende functionaliteit geprogrammeerd worden. Vaak zal van de tester verwacht worden dat ook deze laag ingericht wordt.


Jeroen Mengerink werkt sinds 2008 bij Polteq en is testconsultant. Naast zijn werkzaamheden voor klanten is hij betrokken bij diverse testinnovaties. Jeroen is het eerste aanspreekpunt bij Agile--vraagstukken voor collega’s en klanten. Hij is docent van een gevarieerd pakket aan testtrainingen, onder meer met onderwerpen als Agile, SOA en Cloud. Daarnaast ligt zijn persoonlijke interesse op het gebied van testautomatisering.

Hij is een van de auteurs van het boek Cloutest® over het testen van cloudservices. Ook is Jeroen regelmatig te zien als spreker op conferenties zoals onder andere Testnet, EuroStar en ChinaTest.

In meerdere contexten is vraag naar continue testen. Bij Agile om te zien of regressie optreedt naar aanleiding van nieuwe opleveringen, bij cloud om te monitoren of de leverancier zich aan zijn afspraken houdt, etc. De enige manier om continue (of in ieder geval frequente) testen goed uit te voeren, is door deze te automatiseren. Het nadenken over hoe dit te realiseren en het daadwerkelijk inrichten vraagt om kennis van architectuur, programmeren en testen.

ConclusieDe software die gemaakt wordt is steeds complexer. Dit vraagt niet alleen om meer technische kennis van ontwikkelaars, maar ook vantesters. Van testers wordt steeds vaker verwacht dat zij kunnen programmeren (bij voorkeur in verschillende programmeertalen) en dat ze mee kunnen denken en discussiëren over de architectuur van de software. Bij het gebruik van de cloud is integratie met verschillende systemen nodig, waarbij het kunnen lezen van technische logging en het gebruik van drivers, stubs en mocks van de tester geëist wordt. Doordat bij Agile de tester dichter tegen de ontwikkelaar aanzit, zal ook de communicatie op een technischer niveau plaatsvinden.

Daarnaast moet de tester bijblijven in de snel veranderende wereld, waar zowel Agile als cloud steeds vaker de standaard is. De enige manier om niet achter te raken, is het inzetten van testautomatisering. Hiervoor zullen ondersteunende tools niet alleen gebruikt, maar ook begrepen en ingericht moeten worden. Niet vreemd dus dat de vraag naar technische testers groeit.

Blijf dus leren en verbreed je kennis, dan kunnen wij als test community voldoen aan deze vraag!

[1] Meer info over Fitnesse kun je vinden op http://fitnesse.org/

[2] Meer info over Cucumber kun je vinden op https://github.com/cucumber/cucumber/wiki/

Met bijna 250.000 certificaten is ISTQB veruit het meest succesvolle testopleidings- en certificatietraject in de wereld. Opvallend genoeg staat het kleine Nederland op de vijfde plaats betreffende het aantal certificaten. ISTQB is derhalve een de facto standaard geworden in onze testmarkt. Als we specifiek kijken naar Advanced level certificaten staat Nederland zelfs op de vierde plaats! Wij zijn derhalve mede koploper en veelal ’early adaptor’, een goede reden om eens stil te staan bij de laatste nieuwe ontwikkeling: het derde ISTQB level c.q. het ISTQB Expert level en specifiek de syllabus ’Improving the Testing Process’. In dit artikel een volledig overzicht van deze ISTQB syllabus, door sommige al het ISTQB kroonjuweel genoemd, en informatie over diverse gerelateerde zaken.

ISTQB Expert Level ‘Verbeteren van het Testproces’

Door Erik van Veenendaal



betekent beschikken over en kunnen toepassen van gespecialiseerde kennis en vaardigheden verkregen tijdens opleidingen en vanuit praktijkervaring. Een testexpert is iemand die gedegen kennis en kunde heeft van testen in het algemeen, en diepgaande kennis en kunde in een specifiek testdomein, bijvoorbeeld testproces verbeteren. Diepgaande kennis en kunde betekent voldoende theoretische en praktijk bagage en daarmee in staat te zijn de richting een organisatie en/of project te beïnvloeden als het gaat om het ontwikkelen, implementeren of uitvoeren van activiteiten in het specifieke testdomein. Het is van belang te benadrukken dat, volgens ISTQB, een expert beschikt over zowel de theoretische kennis en de noodzakelijke vaardigheden om deze kennis toe te passen in praktijksituaties.

Testers die volharden in de discussie of ’expert‘ nu de juiste term is of niet, zijn veelal degene die theoretische beschouwingen leuk vinden en blijven hangen in de theorie. Praktijkmensen hebben het liever over de echte inhoud en de toegevoegde waarde die een syllabus voor hun werkzaamheden kan opleveren. Aan de lezer om te bepalen tot welke groep hij of zij behoort. Voor testers is van belang dat het derde niveau in het ISTQB opleidings- en certificatieschema is ontwikkeld en geïmplementeerd. Veel (test) certificatieschema’s hebben drie niveau’s beloofd in het verleden, maar nog nooit zijn deze beloften werkelijkheid geworden. ISTQB heeft het gedaan!

De vraag of ‘expert’ nu echt de beste term is, laat ik open en onbeantwoord. Echter, iemand die aan alle exit criteria van het Expert level voldoet zal een gedetailleerd en diepgaand begrip en grote praktische vaardigheden hebben op het gebied van testproces verbeteren. De exit criteria hebben niet slechts te maken met het slagen voor het examen (wat grotendeels zal bestaan uit open vragen),

ISTQB Expert Level statusLaten we beginnen met het vaststellen van de huidige status van het ISTQB Expert level. Er

Kortom testers van Nederland, het ISTQB Expert level komt er aan!

schijnt nogal wat verwarring hieromtrent te bestaan in de (test-)markt. De ISTQB Expert level (EL) syllabus ’Improving the Testing Process’ is reeds volledig beschikbaar sinds oktober 2010. Ook de EL syllabus Test Manager is onlangs beschikbaar gekomen, inclusief een volledig proefexamen (beiden EL syllabi en het proefexamen zijn te downloaden van www.istqb.org). De Expert level syllabi Testautomatisering (verwacht najaar 2013) en Security Testen zijn momenteel in ontwikkeling. Ter ondersteuning van de syllabi zijn tevens diverse richtlijnen beschikbaar zoals bijvoorbeeld de EL examenrichtlijnen. Een aantal opleidingsbedrijven is momenteel druk bezig met het ontwikkelen van cursusmateriaal op basis van de nieuwe Expert level syllabus ’Improving the Testing Process’, en exameninstituten zijn bezig met de ontwikkeling van EL examens. Ik verwacht dat de eerste EL ’Improving the Testing Process’ opleidingen aan het einde van dit jaar zullen worden geaccrediteerd. Om de implementatie van de syllabus en de deelnemers aan de opleiding te ondersteunen zijn Graham Bath en ik momenteel druk doende met het schrijven van een nieuw testboek op basis van deze syllabus. Kortom testers van Nederland, het ISTQB Expert level komt er aan!

Wat is een expert?Ik weet dat veel testers, die het derde niveau bekijken en bestuderen, problemen hebben met het woord ’expert’. Veel discussies gaan vervolgens over de vraag ’Wat is een expert?’, en niet meer over de daadwerkelijke inhoud die wordt beschreven in de syllabus. Deze nieuwe syllabus heeft niet wereldwijd erkende testexperts zoals Martin Pol, Rex Black en Lee Copeland als doelgroep. Het heeft de testprofessionals, die veelal worden aangeduid als de ’lokale helden’, als doelgroep. De medewerker in een organisatie waar je altijd terecht kunt als je een vraag hebt over testproces verbeteren; de persoon die het verbeterproces leidt in de organisatie of het project; de consultant die wordt ingehuurd voor het uitvoeren van het testproces assessment. Dat zijn voorbeelden van personen die veel meer behoren tot de doelgroep van de ISTQB EL syllabus. ISTQB definieert een expert als ’ a person with special skills and knowledge representing mastery of a particular testing subject’. [1] Een expert zijn

maar ook dient men minimaal vijf jaar testervaring te hebben en minimaal twee jaar ervaring op het gebied van testproces verbeteren. Er is zelfs een continu opleidingsproces gedefinieerd, implicerend dat degene die zichzelf op een gegeven moment ‘expert’ mag noemen, dit niet automatisch mag doen voor de rest van zijn of haar leven. [2]

Syllabus inhoudWellicht goed om in het kort aan te geven wat nu echt aan bod komt in de syllabus en derhalve in de opleiding. In tegenstelling tot wat sommige denken, gaat het niet alleen over de testverbetermodellen zoals TPI-Next en TMMi. Uiteraard zijn deze modellen belangrijk maar is er veel meer te behandelen, leren en te bediscussiëren. In feite vind ik, dat (bijna) alles wat zou kunnen of dient te worden behandeld in de context van testverbeteren daadwerkelijk wordt behandeld. De syllabus geeft een nagenoeg volledig beeld van de state-of-the-practice ten aanzien van testproces verbeteren. Tezamen met Graham Bath, Isabel Evans en een groot aantal reviewers heb ik gewerkt aan wat volgens mij een zeer goede en gedegen syllabus is geworden.

• Context van verbeteren; een introductie waarin de deelnemer leert de noodzaak voor verbeteringen in het testproces te relateren aan de bedrijfsdoelstelling. Tevens wordt ingegaan op fundamentele concepten die veelal impliciet worden gebruikt bij verbetertrajecten zoals de visies van Garvin op productkwaliteit, de Deming cyclus en het EFQM raamwerk.

• Model gebaseerd verbeteren; een groot gedeelte van de opleiding wordt besteed aan de beschikbare modellen (o.a. CMMI, ISO 15504, TPI-Next, TMMi). Niet slechts vanuit het theoretisch perspectief, maar met name gericht op het toepassen van de modellen (zie ook ’werkplek opdrachten’ hierna). Ook de sterke en zwakke punten van de verschillende modellen worden behandeld.

• Analytisch gebaseerd verbeteren; veelal vergeten maar in aanvulling op de raamwerk modellen (vaak toegepast in een top-down benadering), kunnen bottom-up benaderingen wordt gebruikt. Vaak zijn deze in hoge mate



• Aanpassen aan verschillende ontwikkelmodellen; testverbeteren in agile en iteratieve ontwikkel-omgevingen wordt besproken en gepresenteerd. Middels voorbeelden wordt aangegeven hoe testverbetermodellen dienen te worden aangepast en toegepast om bruikbaar te zijn voor agile en/of interatieve ontwikkel-omgevingen.

Werkplekopdrachten Zoals mag worden verwacht van een opleiding op dit niveau, is de primaire focus gericht op praktische oefeningen. Tijdens de Expert level opleiding, die op basis van deze syllabus 6 dagen duurt, wordt meer dan 60% besteed aan oefeningen en meningsvormende discussiesessies. Een heel interessant concept dat wordt toepast om er voor te zorgen dat deelnemers daadwerkelijk praktijkgerichte kunde verkrijgen, en niet slechts hebben geoefend met niet praktijk representatieve oefeningen, zijn de werkplekopdrachten. Van deelnemers wordt verwacht dat ze opdrachten uitvoeren in hun organisatie en daarover terugrapporteren in de opleiding. Als gevolg hiervan zal er ook communicatie tussen de docent en de deelnemer zijn buiten de opleidingsdagen, om vragen te beantwoorden en voortgang te bespreken. Dit betekent uiteraard mede dat de opleidingsdagen typisch zullen worden uitgespreid over een langere periode en niet aansluitend kunnen plaatsvinden. Voorbeelden van opdrachten op de werkplak zijn o.a.:

• Beoordelen van een testorganisatie ten opzichte van het TPI-Next of TMMi model

• Plannen en uitvoeren van assessment interviews

• Opstellen en presenteren van de samenvattende conclusie en bevindingen op basis van een uitgevoerd assessment

• Formuleren van aanbevelingen en actiepunten op het gebied van testprocesverbeteren op basis van de assessment resultaten en de uitgevoerde analyse

• Opstellen van een testverbeterplan (inclusief relevante stappen en acties) met in achtneming van veranderingsmanagement aspecten

• Evalueren van de kritische succes factoren bij een testverbeterproject

effectief en efficiënt. Causale analyse, inspecties, foutpreventieprogramma’s en GQM gebaseerde meetprogramma’s worden in detail behandeld als onderdeel van analytisch gebaseerd verbeteren.

• Selecteren verbeteraanpak; het is van het grootste belang dat de deelnemers in staat zijn de verschillende aanpakken en benaderingen te vergelijken en diegene te kunnen selecteren die het beste past en de meeste toegevoegde waarde heeft binnen zijn/haar organisatie. • Verbeterproces; veel aandacht wordt gegeven aan het verbeterproces zelf. Persoonlijk denk ik dat het verbeterproces plus aandacht voor veranderingsmanagement minstens zo belangrijk is als de keuze voor het ‘juiste' model. Het verbeterproces dat wordt behandeld is gebaseerd op het door het Software Engineering Institute (SEI) ontwikkelde IDEAL verbeterproces. Uitvoerig wordt stil gestaan bij het analyseren van de huidige situatie en het uitvoeren van testproces assessments.

• Organisatie, rollen, kennis en kunde; de rol, voor- en nadelen en opzet van een Test Proces Groep (TPG) worden besproken, evenals hoe om te gaan met testverbeteren in een situatie waarin testen remote, off-shore of zelfs outsourced plaats vindt. Een groot gedeelte binnen dit onderwerp gaat echter over die communicatieve en sociale vaardigheden die nodig zijn om een testverbeterprogramma te kunnen leiden en om succesvol een assessment uit te kunnen voeren.

• Veranderingsmanagement; testproces verbeteren gaat feitelijk om het veranderen van het gedrag van mensen en gaat dus ook over veranderingsmanagement. Alhoewel dit een onderwerp is dat op zich al genoeg omvat om te leiden tot een afzonderlijke Expert level module, komt dit belangrijke onderwerp ook ruimschoots aan bod in deze syllabus.

• Kritische succes factoren; het niet maken van de fouten die anderen reeds hebben gemaakt. Een lijst van kritische succes factoren wordt behandeld, gebaseerd op de praktijkervaringen van de auteurs en reviewers. Daarnaast wordt stil gestaan bij het ‘test proces verbeter manifesto’ [3] als een mogelijke wijze om de verschillende kritische succes factoren in context te kunnen plaatsen.


[1] Expert Level Modules Overview, V1.0 (2011), International Software Testing Qualifications Board

[2] ISTQB Certified Tester Expert Level – Certification Extension Policy, V1.0 (2008), International Software Testing Qualifications Board

[3] E. van Veenendaal, Test Improvement Manifesto, in: Testing Experience, Issue 04/08, December 2008

Ik ben er persoonlijk van overtuigd dat het ISTQB Expert level in ruime mate van toegevoegde waarde zal zijn voor het testvak. Lokale helden met een interesse in testprocesverbeteren zullen in de opleiding op basis van deze nieuwe ISTQB syllabus hun kennis en kunde verder ontwikkelen. Het gaat om de praktijk, het ontwikkelen van praktische vaardigheden en niet slechts over theorie. Dit is hopelijk door middel van dit artikel in voldoende mate duidelijk gemaakt. De eerste Expert level syllabi zijn beschikbaar, dit is niet het einde, maar slechts een begin maar een mooie volgende stap. Het testvak neemt een volgende stap op weg naar volwassenheid.

Erik van Veenendaal is de oprichter van Improve Quality Services BV, een gespecialiseerde organisatie op het gebied van testen en kwaliteitsmanagement. Hij is internationaal erkend testexpert en auteur van diverse boeken en een groot aantal artikelen binnen het vakgebied. Hij is tevens één van de ontwikkelaars van de TMap testmethodiek en het TMMi test improvement model. Erik was vice-president van de International Software Testing Qualifications Board (ISTQB) van 2005 – 2009, één van de auteur van de Expert level syllabus “Improving the Testing Process” en is momenteel vice-chair van de TMMi Foundation. Hij is regelmatig keynote en tutorial spreker op internationale (test)conferenties en ontving in 2007 de ‘European Testing Excellence Award’ voor zijn bijzondere bijdrage aan de ontwikkeling van het testvakgebied.

Erik is bereikbaar via e-mail [email protected], twitter #erikvveenendaal en via zijn website www.erikvanveenendaal.nl.

TESTKRANTDisclaimer

Niets uit deze uitgave mag op enigerlei wijze worden overgenomen zonder uitdrukkelijke toestemming van de uitgever van de TestKrant, te weten www.testnieuws.nl. Hoewel aan de TestKrant uiterste zorg is besteed, aanvaarden de TestKrant nog TestNieuws.nl enige aansprakelijkheid voor schade onstaan door eventuele fouten en/of onvolkomenheden in het blad en/of de website. De uitspraken en meningen van de schrijvers van de artikelen zijn niet ook noodzakelijkerwijs die van de TestKrant. Alleen de schrijvers zijn verantwoordelijk voor de inhoud van hun artikelen. De TestKrant behoudt zich het recht om, tenzij anders overeengekomen met de auteur, ingezonden materiaal in te korten en/of aan te passen.

website: www.testkrant.nle-mail: [email protected]

MAGAZINE VOOR DE NEDERLANDSE TESTER

Documents

Transcript of MAGAZINE VOOR DE NEDERLANDSE TESTER