VAN DE REDACTIE. In dit nummer

Maart 2011 • Jaargang 15 • Nummer 1 Vereniging TestNet p/a Diadeemstraat 91 1336 TT Almere

www.testnet.org [email protected]

VAN DE REDACTIE

In dit nummer

Door Hans van Loenhoud • [email protected]

We leven in een woelige en onrustige tijd. De economische crisis in Europa zit nog steeds bij velen in het hoofd; er is revolutie in het Midden-Oosten; we zien Belgische toestanden in het landsbestuur; het Journaal toont ons ongekende

Van de redactie

1

Van de voorzitter

2

Riks column

3

De dag van Sander Stevens

3

Vijf vragen aan Rob van Steenbergen

5

De Dutch Testing Conference 2011

7

The Little TMMi, the making of

8

Model-based Testing User Conference

10

natuurrampen: aan alle kanten worden we belaagd door

Test Driven Development, de bijsluiter

10

problemen en onzekerheden. Nu zijn we als testers na-

Boekrecensie: Testwoordenboek

13

tuurlijk bij uitstek tegen onzekerheid bestand. Het omzet-

Software Testers Benchmark een succes

13

ten van onzekerheden in waarheden is de essentie van ons

ISTQB Certified Tester Expert Level

14

professionele bestaan.

Pubertijd of midlife crisis

16

In al dat gewoel is TestNet Nieuws een rots in de branding.

SQS: Testing, the near future

19

Onverstoorbaar brengen wij het voorjaarsnummer uit.

mijnpensioenoverzicht.nl

22

Onze vaste rubrieken zijn gevuld, werkgroepen laten van

Bruggen bouwen met Visual Studio (1)

24

zich horen, verschillende leden hebben vakinhoudelijke

Evenementen en thema-avonden

30

artikelen ingestuurd. En – last but not least – onze redactie is weer op volle sterkte door de toetreding van Kees Blokland. Wij zijn blij en trots dat we met de hulp van vele penvaardige leden weer een nieuw, superdik nummer hebben kunnen uitbrengen, het levende bewijs van de groei en bloei van TestNet. We wensen jullie veel leesplezier en blijven rekenen op jullie bijdragen in de toekomst.

TestNet Nieuws verschijnt eenmaal per kwartaal. Kopij aanleveren per e-mail aan de redactie. Het is niet toegestaan om de nieuwsbrief of delen eruit zonder bronvermelding over te nemen.

COLOFON Redactie Paul Beving Hylke ten Cate Hans van Loenhoud Kees Blokland Johan Vink [email protected]

Bestuur Michiel Vroon Rob Baarda Rik Marselis Kees Blokland Huib Schoots Bart W atertor

Voorzitter Penningmeester Evenementen & Thema-avonden Informatievoorziening & Beheer Marktverkenning & W erkgroepen Secretaris, 2e penningmeester

Pagina 2

VAN DE VOORZITTER Door Michiel Vroon • [email protected]

Vanaf mijn balkon dat uitkijkt op de Reschenpass, onder een strakblauwe hemel, tik ik dit stukje op mijn laptop. Via een draadloze verbinding die door het hotel aan alle gasten ter beschikking wordt gesteld, mail ik het dan naar de redactie van TestNet. Op de piste controleer ik via mijn mobiele telefoon of alles goed is aangekomen en scan ik snel mijn andere mails. Op de plaats van vertrek voeren we onze bestemming in en geheel blind voor de omgeving stormen we af op ons doel. Daar aangekomen hebben we 24 uur per etmaal de beschikking over ons geld op onze bankrekening. Deze verregaande integratie van computers in ons dagelijkse leven is voor velen de normaalste zaak van de wereld geworden. Maar als dat hapert, worden we teruggeworpen op voor ons al zeer ouderwets aanvoelende handelingen, zoals kaartlezen of geld halen bij een bank. Nu is dit op zich allemaal niet zo heel erg, alleen waar ik me dan over verwonder, zijn de foutmeldingen, die deze haperende systemen opleveren. Tenenkrommend taalgebruik, waar verder geen bruikbare informatie uit te halen valt.

Ook zelfs nu met vakantie besef ik weer dat er genoeg werk voor ons testers is en dat het alleen maar meer zal worden. Ook met de vereniging gaat het goed. We hebben de ALV achter de rug, waarin we als bestuur inzicht hebben gegeven in de zaken die afgelopen jaren hebben gespeeld en de plannen die we hebben voor het komende jaar. Met het vertrek van Meile Posthuma als bestuurslid kwam een plaats vrij en ik ben blij te kunnen melden dat we Kees Blokland bereid hebben gevonden deze plek in te nemen. Daarnaast stevenen we af op het voorjaarsevenement. Dit belooft een mooie dag te worden met naast vele nieuwe sprekers met vernieuwende verhalen ook aansprekende tutorials en keynotes van BJ Rollison, Clive Bates en Michael Bolton. Geheel nieuw dit jaar is de TestNet summer school, waar we samen met onze sponsors een dag- en avondvullend programma zullen samenstellen voor de vaak rustige zomermaanden. Ook aan de kant van de werkgroepen gebeurt veel. Dat zal door henzelf, wanneer de tijd daar rijp voor is, worden aangekondigd. Ik wens iedereen veel leesplezier met deze nieuwe TNN. Graag tot ziens op één van de thema-avonden of evenementen.

Pagina 3

RIKS COLUMN Door Rik Marselis • [email protected]

Wat is een expert? Lang geleden werd een keer een Charlie Chaplin look-alike wedstrijd gehouden. De echte Charlie Chaplin was in de buurt en deed mee. Hij werd derde. Charlie overwoog om les te gaan geven in het Charlie-Chaplin-loopje omdat het volgens hem zo slecht werd geïmiteerd. Of dit echt is gebeurd of slechts een legende, is niet duidelijk. Maar aan deze anekdote moest ik denken na afloop van de thema-avond over het ISTQB Expert level op 9 februari. Ik vroeg me af: ’Wanneer is iemand een expert?’ Charlie Chaplin heeft de ’tramp’ bedacht en tot een succes gemaakt en is dus volgens mij de onbetwiste expert. Toch waren er blijkbaar andere mensen die beter het Charlie Chaplin gevoel konden overbrengen. Ofwel, de bedenker is niet altijd de beste vertolker. Hoe zit dat met testexperts? Een snelle telling op mijn boekenplank thuis leert me dat er meer dan dertig Nederlanders als schrijver op de kaft van een testboek genoemd staan. Als een testexpert iemand is die het vak verrijkt heeft, dan komen deze dertig in aanmerking voor de titel. Het aantal testers dat de afgelopen jaren in bladen als de testing experience, de professional tester enzovoort heeft geschreven, komt zeker boven de honderd. En dan rekenen we de TestNet Nieuws nog niet eens mee. Meer dan honderd testexperts in Nederland dus? ISTQB is een organisatie die het testvak verder wil brengen. Maar er zijn ook veel mensen die met de ISTQBtrainingen en examens hun brood verdienen. En tja, die hebben niet veel aan dertig experts voor hun trainingen. En meer dan honderd klinkt leuk, maar dat is twee klasjes per trainingprovider en dan is de koek op. Je kunt expert ook definiëren als ’degene die binnen een organisatie het testvak verder brengt’. Voor de goede orde: dit is een definitie die ik ter plekke heb verzonnen. Van dit type expert heb je er laten we zeggen twee per organisatie nodig. Uitgaande van 250 grote(re) organisaties met een aparte testafdeling komen we dan op 500 mensen. Dan kom je op een doelgroep waarvoor met een gezonde businesscase trainingen en examens georganiseerd kunnen worden. Tja, ik snap dat Nathalie in haar blog schrijft dat ze teleurgesteld is over het niveau van ’de expert’. En ik zal hier geen oordeel vellen wanneer we nou iemand echt een testexpert moeten noemen. Maar het bovenstaande geeft wel weer waarom ik denk dat het ISTQB-expert-niveau is geworden wat er nu gelanceerd is. Is de naam ’expert’ dan goed gekozen? Ach, ik denk dat het goed is dat mensen hun vakkennis nog verder kunnen verbreden en verdiepen. Of jij je aangetrokken voelt tot dit expert-level, moet je zelf bepalen.

DE DAG VAN … Door Sander Stevens • [email protected]

Het is vandaag dinsdag. Dinsdagochtend heel vroeg om precies te zijn. Als ik op mijn wekker kijk, is het eerste cijfer nog een vijf. En dan weet ik: eigenlijk heb ik nog niet genoeg geslapen. Maar ja, om de files een beetje voor te zijn moet je wel vroeg weg. Dus snel het bed uit, onder de douche, aankleden, een boterham klaarmaken (opeten doe ik wel in de auto), tas pakken en rond kwart voor zeven richting klant.

Pagina 4

Audioboeken Om de tijd een beetje te doden en mezelf niet te veel te ergeren aan de drukte (kwart voor zeven vertrekken is geen garantie voor een filevrije rit) luister ik naar audioboeken in de auto. Dat helpt! Vandaag staat eerst Deventer op het programma. Bij de klant in Deventer ben ik bezig met een Quality Maturity Scan. Dat is een assessment voor het verkrijgen van 'grip en controle' over de kwaliteit van het IT-proces en het eindproduct. Het bestaat onder andere uit het interviewen van diverse projectleden. Vandaag begin ik met de tweede ronde. Het is altijd interessant om een kijkje in de keuken te nemen.

Assessment De ochtend begint met een gesprek met de testmanager van het project. Hij vertelt me zijn achtergrond en geeft aan, dat dit zijn eerste echte testmanagement klus is. Eigenlijk is hij een junior projectmanager, maar hij is naar voren geschoven om deze rol inhoud te geven. Na een aantal vragen blijkt dat hij wel weet wat er moet gebeuren om een gestructureerd proces op te zetten, maar dat hij de praktische ervaring mist om er invulling aan te geven. Het is een interessant gesprek met iemand die graag wil, maar continu tegen ‘muren’ aanloopt. Uit alles blijkt dat hij een zware taak heeft. Dit zijn wel de situaties waar je een bedrijf echt kunt helpen en dat maakt een assessment altijd zo boeiend.

Dingen loslaten Het tweede gesprek van de ochtend is met de programmamanager. De programmamanager is een ervaren man, werkt al zeventien jaar in de IT en is extern aangetrokken door de klant om het project tot een goed einde te brengen. De programmamanager is ook degene, die de testmanager naar voren heeft geschoven om de uitdaging op het gebied van testen aan te gaan. Het gesprek begint wat algemeen en informeel over het project, de deadlines, de rollen en de samenwerking met de business. Wanneer we op het onderwerp testen aankomen, verandert de uitdrukking op zijn gezicht. Hij kijkt wat nors en begint zachter te praten. Alsof de muren oren hebben. Ik zal niet te veel in detail treden, maar kort gezegd komt het erop neer dat de programmamanager niet tevreden is, meer actie verwacht van de testmanager en het liefst zelf inspringt om de problemen rondom het testen op te lossen. Prachtig om te zien hoe betrokken deze man is. Maar aan de andere kant moet hij dingen ook kunnen loslaten en anderen het vertrouwen geven. Ik denk dat ik in ieder geval één aanbeveling voor het adviesrapport al te pakken heb. Na deze twee gesprekken is de ochtend alweer voorbij. De tijd vliegt tijdens dit soort interviews. Omdat ik vanmiddag nog een afspraak heb bij een klant in Amstelveen, heb ik de resterende interviews aan het einde van de week gezet. Na de interviews zet ik de resultaten naast elkaar en kan ik aan het adviesrapport beginnen.

Parttime opdracht Maar eerst dus richting Amstelveen. Bij die klant vervul ik een parttime rol als testmanager. Het testteam bestaat uit een testcoördinator, vijf testers en een wisselend aantal gebruikers. Omdat de testcoördinator de dagelijkse werkzaamheden coördineert, is het voor mij mogelijk om deze opdracht parttime op te pakken. We zijn druk bezig met de testuitvoering en de release van afgelopen vrijdag is blijkbaar nog steeds niet geïnstalleerd op de acceptatieomgeving. Van de afdeling Unix Beheer krijgen we te horen dat een aantal scripts niet meer werkt in combinatie met de nieuwe release. Pffff, het is ook altijd wat. Waarom is het toch zo moeilijk? Het testtraject kun je nog zo goed op orde hebben, maar vaak blijkt dat de valkuilen juist in de afhankelijkheden zitten. De releases installeren op een test- of acceptatieomgeving, de kwaliteit van de documentatie, het gebrek

Pagina 5

aan uitvoerende handjes: ergens loopt het spaak. Maar dat maakt het nu juist zo boeiend! Als alles zonder problemen zou verlopen, dan was de lol er snel vanaf.

Wachten Het feit is wel dat we nu inmiddels twee dagen zitten te wachten op de nieuwe oplevering en de verwachting is dat het probleem niet voor morgen einde dag is opgelost. Drie dagen verliezen op een testperiode van twee weken is best veel. En natuurlijk is de deadline keihard en moeten we alles uit de kast halen om toch eind volgende week met goed vertrouwen het go/nogo-overleg in te gaan. Dat wordt nog spannend. Samen met de testcoördinator en een senior tester kijken we naar de huidige planning en proberen we oplossingen te bedenken voor de verloren dagen. Meer testers inzetten? Aanstaand weekend werken? Langere dagen maken? Toch maar even gaan praten met de programmamanager om te kijken of de deadline te verschuiven is? We besluiten om in ieder geval een extra tester in te zetten en langere dagen te maken. Eigenlijk alles om te voorkomen dat er in het weekend moet worden gewerkt. Die extra tester op zeer korte termijn is een uitdaging. Maar met een paar telefoontjes naar de achterban moet dat te regelen zijn. En die langere dagen … Tja, dat kan nou eenmaal gebeuren. Overwerken is op zich niet erg, maar het moet wel nuttig zijn. En niet structureel! Anders is er iets mis met de projectplanning.

Openstaande bevindingen Aan het einde van de middag nog snel even een blik werpen op de openstaande bevindingen, even langs de afdeling Unix Beheer om het belang van deze installatie te benadrukken en dan richting huis. Het eerste cijfer van de klok is inmiddels weer een vijf en dus hoogste tijd om onderweg een boek te beluisteren.

VIJF VRAGEN AAN … Door Rob van Steenbergen • [email protected]

Ik vind testen een leuk vak want … … ooit was ik nog bezig met het testen van een datumveld. Daarbij moesten we goed rekening houden met schrikkeljaren en specifiek opletten op de afwijkingen van een schrikkeljaar. Als een jaartal deelbaar is door vier, dan is het een schrikkeljaar, met uitzondering van eeuwjaren. Dat zijn alleen schrikkeljaren als ze deelbaar zijn door vierhonderd. De wereld ging over van MS-DOS naar Windows applicaties en er ontstonden veel migratieprojecten. Vervolgens de migratie van 16 bits naar 32 bits applicaties en de ’millennium bug’. Gevolgd door het omtoveren van de gulden naar de euro. Software wordt ingebed in hardware. Afstandsbedieningen en telefoons zijn niet meer wat ze tien jaar geleden waren, we werken steeds meer via een internet browser en de software draait niet meer op de pc. Nu zijn we onze servers en werkplekken aan het virtualiseren. Je werk doe je achter je werkplek, maar de software kan overal op de wereld draaien. En om dat allemaal vanuit de positie van de tester te zien, te analyseren en te onderzoeken is een privilege. Want de tester ziet vaak het begin, het midden en het einde van een ontwikkeltraject en kan (in principe) aan alle onderdelen ‘meedoen’. En de uitdagingen zijn er. Het vakgebied lijkt vaak nog steeds op pionieren, zoals het vijftien jaar geleden, toen ik begon, ook aanvoelde. We gaan van watervalmethoden naar kleinere teams waar samenwerking en communicatie

Pagina 6

het belangrijkste aspect is. Automatisering van de IT, testautomatisering, model based testing, nieuwe ideeën en andere paradigma's ontstaan over testen. Het testvak kan af en toe ’oude wijn in nieuwe zakken’ lijken, maar de IT verandert zo snel en daarmee ook het testvak, dat je als tester jezelf constant moet ontwikkelen. De nodige creativiteit is dan ook vereist om je constant aan te passen aan dit veranderende werkveld. Dit bij elkaar maakt het testvak interessant, des te meer omdat je als tester in het hart van de ontwikkeling zit. Je wilt goede documentatie, je bent betrokken bij de eindgebruiker, je komt veel techniek tegen. Communicatie wordt vaak als een zeer belangrijke vaardigheid genoemd voor een tester, maar programmeren zal je ook moeten leren. Uitdagingen genoeg voor een tester in de huidige tijd.

Het grootste misverstanden over testen is ... ’Het is getest, dus is het goed.’ Er wordt vaak gezegd dat een product is getest om een manager of klant gerust te stellen. Een manager of klant die hier niet meer in trapt, zal een vraag stellen in de trant van: ’Wat zijn de risico’s die nog overblijven als we dit product gaan gebruiken?’

Over vijf jaar zie ik mijzelf in de functie van ... Ik heb al aardig wat rollen gehad in het testgebied, van junior tester voor een MKB-databaseleverancier, testautomatiseerder, tester van gevirtualiseerde werkplekken, teamleider, testcoördinator, testmanager en configuratiebeheerder. De verscheidenheid aan taken die ik de afgelopen jaren heb gehad, smaakt naar meer en daardoor blijft voor mij de rol van tester dé baan in de IT. Of de naam van de rol ’testcoördinator’ is of ’embedded audit medewerker’, dat maakt niet uit. Tester dus. Verder ben ik geïnteresseerd geraakt in het feit dat andere disciplines steeds vaker wat meer willen weten over testen. Ik kan mij voorstellen dat ik meer ga doen op het gebied van trainingen geven, coachen en het promoten van het testen in combinatie met andere disciplines.

Een tester moet zeker beschikken over de vaardigheid of kennis om ... De rol van de tester en de eisen die aan hem of haar worden gesteld, worden steeds uitgebreider. Soms zou je als tester diep in de techniek kunnen duiken, wat steeds meer voorkomt bij embedded software testen, testen van infrastructuur en testautomatisering. Tegenwoordig in agile projecten moet je zeker verstand hebben van zowel testen als de techniek. Een andere kant van het vak vormen de zachte vaardigheden: hoe leg je testen uit, hoe begeleidt je andere disciplines binnen de IT op het testvakgebied. En verder heel belangrijk voor een tester: nieuwsgierigheid hoe techniek werkt, kritische blik houden, creativiteit en zaken in het juiste perspectief plaatsen. Dat laatste is vooral om frustraties te voorkomen bij het ’overruled’ worden door management. Dus: technische kennis up-to-date houden, communicatieve vaardigheden en relativering.

In de toekomst hoop ik, dat binnen het testvakgebied ... is veranderd, omdat... Totale kwaliteit, niet alleen van het product, maar ook hoe marketing en management hiermee omgaan, hoe maak je ontwerpen, hoe vertaal je deze naar technische uitwerkingen, hoe bewaar je de consistentie van de verschillen-

Pagina 7

de fasen in een project. Niet iets waar een tester zich drukt over hoeft te maken, maar wie doet dat dan wel in een organisatie? Testen hobbelt vaak nog achter een project aan; hierdoor zijn testers afhankelijk van de kwaliteit van het gehele voortraject. Als we daar geen invloed op hebben, zijn de testen die we uitvoeren ook van mindere kwaliteit. Ik kan me voorstellen dat een bepaalde groep testers zich meer gaat ontwikkelen naar een totaal kwaliteitsmanagement, wat dit keer niet gebaseerd is op dikke boeken vol met procedures en processen, maar praktisch gericht is op hoe je in alle fasen kwaliteit kan meten en daar de juiste acties uit kunt afleiden. Iedereen in een team test zijn werk en dat wordt overkoepelend bewaakt, tot aan de communicatie naar de eindgebruiker toe. Er is overigens een discussie gaande in de testwereld of een tester zich wel moet bemoeien met dit soort zaken: ’tester, wordt geen QA’. Maar ik zie wel die behoefte bij organisaties. Of het goed te combineren is binnen één rol, is een andere vraag.

De vijf vragen gaan volgende keer naar ... Gabriël Felten, omdat ik zeer prettig met hem heb samengewerkt in een vorige opdracht. Maar ook omdat hij graag artikelen wil schrijven over testen en daar al mee is begonnen. Dus hierbij, Gabriël, je volgende schrijfopdracht! ☺

DE DUTCH TESTING CONFERENCE 2011 Interview met Diederick Dekker door Kees Blokland • [email protected]

Op 13 april aanstaande is de tweede editie van de Dutch Testing Conference (DTC). Diederick Dekker is ICTmanager Lean IT binnen de Belastingdienst en zit in de Conference Board van DTC 2011. Kees Blokland blikt samen met Diederick vooruit.

Wat is het thema van de DTC 2011? ’De focus van de Dutch Testing Conference ligt op het delen van ervaring van mensen betrokken bij het testen, waarbij er speciale aandacht is voor het perspectief van de klant en de opdrachtgever. Het gaat om ervaringen, trends, management en best practices. Kortom, een conferentie ontworpen om het leven van de tester van nu en daarna makkelijker te maken! De Conference Board en de organisatie van de Dutch Testing Conference hebben zich ten doel gesteld om een 'andere' conferentie neer te zetten. Deze conferentie gaat over testen, maar is niet alleen bedoeld voor testprofessionals. De Dutch Testing Conference richt zich ook op projectmanagers, systeemeigenaren, business analisten, enzovoorts. Gesteund door verschillende klantorganisaties en marktpartijen, zoals ABN Amro, Avans Hogeschool, Belasting-dienst, Air France/KLM, Rabobank, IBM, KPN, Capgemini, Polteq en Sogeti, biedt de Dutch Testing Conference 2011 een uitstekend podium voor iedereen die zich met testen bezighoudt of op andere wijze met testen en kwaliteitszorg te maken heeft. De conferentie biedt kwalitatief hoogwaardige presentaties, een grote expo met alle kleine en grote spelers uit de software testing markt en een moderne en frisse manier van organiseren van conferenties.’

Pagina 8

Kun je iets zeggen over de verwachte deelname van bezoekers? ’In DTC 2010 waren er meer dan 400 deelnemers. Deze conferentie is door het overgrote deel van de deelnemers als goed tot zeer goed beoordeeld. Onze verwachting is, dat het aantal deelnemers dit jaar een stuk hoger komt te liggen, omdat gebleken is dat de conferentie duidelijk in een behoefte voorziet. Daarnaast hebben wij goed geluisterd naar de verbeterpunten, aangedragen door de deelnemers. Wij doen ons best om beter te worden, zodat de deelnemers waardevolle informatie krijgen en daarnaast de mogelijkheid vinden om te netwerken en van elkaar te leren.’

Wat vind je van de omvang en kwaliteit van de submissions? ’Ik vind het erg sterk dat de sprekers en de presentatie in de eerste drie niet commerciële tracks geselecteerd zijn door de klantorganisaties (zie hiervoor het programma op http://www.dutchtestingconference.nl). Hierdoor garandeer je onafhankelijkheid van leveranciers en focus op toegevoegde waarde voor klantorganisaties. Wij hebben rond de zeventig goede inzendingen gehad en hebben daaruit de beste twaalf presentaties geselecteerd. Wij als Conference Board zijn ervan overtuigd dat inhoud en wijze van presentatie zullen bijdrage aan een dialoog tussen de deelnemers en daarbij bijdragen aan het succes van de DTC 2011. Daarnaast geven wij een blik in de toekomst. Tien leden van de expertgroep is gevraagd kort hun persoonlijke visie te presenteren op de toekomst van testen. Deze zogeheten Lightning Talks in de ochtend gaan in op het proces van 'wie' en 'wanneer', terwijl de Lightning Talks in de middag over de mensen en infrastructuur gaan, het 'wie' en 'waar'. Interessant, informatief en een goede manier om met elkaar in gesprek te komen. Natuurlijk hebben we ook ruimte voor onze sponsoren in een speciale sponsor track.’

Hoe kijk je tegen het programma aan? ’Het programma heeft een breed aanbod en biedt voldoende aanknopingspunten om mee terug te nemen naar het werk. Sommige punten om direct toe te passen en andere om op te reflecteren voor de toekomst.’

Hoe is dat eigenlijk tot stand gekomen? ’Het programma is tot stand gekomen door goed te luisteren naar de ervaringen van vorig jaar en naar de doelgroep van de DTC 2011. Dus niet alleen naar testers, maar ook naar projectmanagers, systeemeigenaren, business analisten, ICT-managers en andere betrokkenen.’

Hoe kijk jij tegen de toekomst van testen aan? ’Ik vind het persoonlijk van belang, dat bij het testen de klantresultaten centraal staat en vraag me daarbij regelmatig af of wij niet zonder testen kunnen? Risicoanalyses en testen dienen veel meer dan nu onderdeel te zijn van het ontwerp van systemen. Binnen het V-model moeten we steeds meer opschuiven naar linksboven, naar klantontwerpen en klantbeleving. Testen en kwaliteit moeten onderdeel zijn van het ontwerp. De eerste stappen in die richting zijn al gezet, maar in een wereld waar meer op kosten gelet gaat worden, valt hier nog veel te winnen. Natuurlijk kan de techniek ons daarbij ondersteunen, maar dat is geen vervanging van gezond verstand en lef om eigenaarschap te nemen van het uiteindelijke resultaat.’

Pagina 9

Wat wil je verder nog kwijt? ’Check out http://www.dutchtestingconference.nl! Ik hoop je te ontmoeten op 13 april 2011 in ‘t Spant! in Bussum om van elkaar te leren en elkaar te stimuleren betere producten en resultaten neer te zetten. Niet alleen, maar samen, in verbinding met alle nodige disciplines.’

THE LITTLE TMMI, THE MAKING OF Door Jan-Jaap Cannegieter • [email protected]

In 2010 kwam ‘De kleine TMMi’ uit, een Nederlandstalig boek over het testvolwassenheidsmodel TMMi. Onlangs is daar ‘The little TMMi’ bij gekomen, de Engelse vertaling van ‘De kleine TMMi’. Eigenlijk is het heel curieus dat eerst een Nederlandse versie is gepubliceerd. TMMi is een Engelstalig model en de TMMi Foundation zit in een Engelstalig land. Daarnaast zie je bij andere modellen dat juist de trend is om meer in het Engels te publiceren. Een voorbeeld is TPI Next dat bij mijn weten primair in het Engels is uitgebracht. Een aantal bestuursleden van de TMMi Foundation is er echter niet verbaasd over dat het eerste TMMi-boek in het Nederlands is en het eerste TMMi-boek in het Engels uit Nederland komt. Zoals Geoff Thompson het in het voorwoord formuleerde ’ … the new TMMi models’ first book should be published in Holland, where most often in recent years step changes in software testing have originated.’ Trouwens, er zijn ook behoorlijk wat Nederlanders actief binnen de TMMi Foundation. Curieus of niet, op een dag zit je met een Nederlandstalig boekje dat je in het Engels wilt uitgeven. Het vertalen van de goals en practices was niet aan de orde, want die konden we vanuit het originele model kopiëren. Maar de rest van de tekst, hoe doen we dat? Mijn co-auteur Erik en ik verdeelden de tekst en we zouden allebei ons deel vertalen. Nu was ik van mening dat mijn Engels behoorlijk was. Dus vol enthousiasme ging ik aan de slag. Na één A4 was ik in eerste instantie tevreden. Toch legde ik, onder het motto ’je kunt maar beter zo vroeg mogelijk de kwaliteit vaststellen’, de tekst voor aan de vrouw van een collega, die lerares Engels is. Uiteindelijk heb ik haar ingehuurd om het voor mij te vertalen. En het stuk dat ik al had vertaald hebben we maar weggegooid, opnieuw beginnen kostte haar minder tijd dan corrigeren … Erik heeft zijn deel zelf vertaald en ik moet dus toegeven dat zijn Engels beter is dan het mijne. Goed, ik wil het er niet meer over hebben, OK? De vertaalde tekst hebben we wel door een aantal personen, die het Engels als eerste taal hebben, laten lezen. Daarnaast heeft een technical writer met testachtergrond de tekst gereviewd. Kwaliteit staat voorop! Dan krijg je het zetten, drukproeven, enzovoorts. Daar zat behoorlijke haast achter, omdat er al bestellingen voor het boek lagen vanuit Korea en Brazilië. En binnenkort mag ik op uitnodiging aan de andere kant van de wereld iets over TMMi vertellen en boeken signeren. Toen het boek net uit was, heb ik het even opgezocht op Amazon. En even simpel gezegd: het is best kicken als je daar je eigen naam intypt en je boek wordt gevonden! Kortom, het valt nog best tegen een Nederlandstalig boek in het Engels uit te brengen, maar we kunnen er met z’n allen best trots op zijn dat het eerste boek over TMMi zijn oorsprong vindt in Nederland. Het boek is te bestellen bij alle boekensites of via www.utn.nl.

Pagina 10

MODEL-BASED TESTING USER CONFERENCE Door Jan Tretmans • [email protected]

Model-based testen is voorzichtig begonnen aan een opmars in testland: veelbelovend, maar nog volop in de kinderschoenen. De grote belangstelling binnen TestNet voor de gelijknamige werkgroep is daar een voorbeeld van. Een volgende stap op het groeipad zou een spraakmakende conferentie kunnen zijn. En die staat nu op stapel. Van 18 tot en met 20 oktober 2011 wordt in Berlijn door het European Telecommunications Standards Institute (ETSI) en het Fraunhofer instituut een eerste grote conferentie aan dit onderwerp gewijd. Als je daar meer over wilt weten – en dat wil je vast wel – kijk dan op http://www.model-based-testing.de/mbtuc11/. En voor de echte model-beesten onder ons: tot 22 mei aanstaande kun je nog een proposal voor een presentatie indienen.

TEST DRIVEN DEVELOPMENT, DE BIJSLUITER Door Rik Teuben • [email protected]

Er zijn vele pogingen geweest om het aantal fouten in software te reduceren en software op te leveren die klanten willen. Volgens een rapport van de Standish Group zijn agile werkmethoden daar succesvoller in dan watervalmethoden. Van de agile projecten slaagt ongeveer veertig procent, terwijl de projecten die met een watervalmethode werken, slechts in zestien procent van de gevallen succesvol zijn. Je zou toch zeggen dat deze cijfers tot groot enthousiasme voor agile werkmethoden leiden bij iedereen die de laatste jaren aan een project heeft gewerkt dat na jaren ploeteren en overwerken toch nét weer niet de eindstreep haalde en een stille dood stierf. Er is hoop en agile geeft die hoop.

Agile werkmethode Test Driven Development (TDD) is een methode die als agile werkmethode overschaduwt wordt door SCRUM, maar zeker niet in het rijtje mag ontbreken. De methode is juist voor ons als testers interessant, omdat testen er een prominente rol in speelt. De naam 'Test Driven Development' komt van Kent Beck, die deze techniek in 2003 op papier heeft gezet. Daarmee is TDD in ieder geval een methode die is geïntroduceerd toen het testvak en de testprofessionals de kinderschoenen waren ontgroeid. Dit in tegenstelling tot methoden zoals Scrum en XP, die beide als gedachtegoed zijn gebaseerd op praktijken uit de jaren tachtig en halverwege de jaren negentig van de vorige eeuw als ontwikkelmethode werden uitgewerkt. Lang vóórdat het agile manifesto – dat ik niet wéér zal citeren – werd gepubliceerd.

Pagina 11

De regels van het spel De ideeën van TDD zijn, zoals bij de meeste agile werkmethoden, eenvoudig samen te vatten, maar moeilijk toe te passen. Wat dat betreft is TDD vergelijkbaar met het spelletje schaak, dat weliswaar eenvoudige regels heeft, maar tot kasten vol boeken heeft geleid over de strategie die daarbij moet worden gevolgd. Binnen TDD worden vijf fasen onderscheiden en qua regelgeving is dat het wel zo’n beetje. Test maken Bij Test Driven Development wordt eerst een test geschreven. Pas dan begint men code te schrijven. De test is gebaseerd op een requirement. Deze (geautomatiseerde) test zal initieel waarschijnlijk falen. Wij testers weten natuurlijk dat het later ook nog wel eens zal gebeuren, aangezien het stuk code waarop deze test van toepassing is, nog niet is geschreven. Alle tests draaien en kijken of de nieuwe test faalt Het laten falen van de nieuwe test is bedoeld om te kijken of de requirement niet toevallig al is geïmplementeerd en of de test zelf fouten bevat. Code schrijven In deze stap wordt de daadwerkelijke code geschreven om de zojuist gemaakte test te laten slagen. Deze code mag alleen de functionaliteit bevatten die nodig is om de test te laten slagen. De code hoeft niet perfect geschreven te zijn, zolang deze maar werkt. In een latere stap zal de code nog worden herschreven en wellicht ook geoptimaliseerd. Tests draaien en kijken of deze slagen In deze stap worden alle tests nogmaals gedraaid en wordt gekeken of alle tests slagen. Is dit het geval, dan is dit een goed uitgangspunt om aan de volgende stap te beginnen. Code herschrijven (refactoring) In deze stap wordt de code opgeschoond en volgens de standaard herschreven. Ook zal eventuele dubbele code, nodig om de onderlinge afhankelijkheid van de componenten te minimaliseren, worden verwijderd.

TDD, kans of niet? Kijkend naar de stappen in TDD ontstaat er bij de gemiddelde tester meteen een tevreden gevoel. Eindelijk sta je ingeroosterd bij aanvang van een project en zit niet jíj maar zitten ‘zullie’ op het kritieke pad. En dat is zonder meer een voordeel! Ook kun je met jouw vakmanschap de kwaliteit van software nu eens écht positief beïnvloeden. Hoe beter, completer de test, hoe beter, completer de software, want bij TDD wordt een directe relatie gelegd tussen beide. ‘Geen test, geen software’, ‘Slechte test, slechte software’. Zo simpel is het bij TDD en dat klinkt ons testers fris in de oren. Maar dat is niet het enige voordeel. TDD is een fantastische specificatiemethode. Ontwerpen aan de hand van requirements is vaak lastig. Het specificeren van testen is makkelijker, concreter. Ook testers die werken in een ‘waterval omgeving’ weten dat tegen het einde van een project je rol als tester verandert. Je wordt de spin in het web. Je kent de werkelijke aard en werking van het systeem en weet dát en wáár deze afwijkt van wat bedacht en de bedoeling was. De rol van ‘vraagbaak’ wordt als vanzelf aan je takenpakket toegevoegd. Specificeren, uitvoeren en waarnemen van een test blijkt meer dan eens een uitstekende methode om systeemgedrag te specificeren, te analyseren en verder uit te werken. Je kunt er niet vroeg genoeg mee beginnen!

Pagina 12

Alleen succesvol als er professioneel wordt getest Als testers gaan we er natuurlijk van uit dat de testen worden opgesteld door professionele testers en niet door personen die ontwikkelen als hoofdvak hebben gekozen. Maar dat is niet altijd – vaak niet – het geval bij TDD. Bij TDD wordt de test vaak door ongetrainde testers opgesteld en uitgevoerd. Veel bouwers zijn prima bouwers, maar beroerde testers. Dat was zo en dat zal ook nog wel even zo blijven. Bij TDD is de hoeveelheid testgevallen die wordt opgeleverd indrukwekkend. Een belangrijk deel van het succes ervan is afhankelijk of ‘Den test in den nacht zonder ingrijpen van den menschelijken hand kan runnen’. Dan wordt nog wel eens vergeten om na te denken over dekkingsgraad, efficiency en de maat waarlangs men meet. De relatie tussen een (keten)test en de hoeken en gaten die een requirement in zich heeft, kan zoekraken. De test is dan geen valide instrument om de kwaliteit vast te stellen en de software gaat onterecht door naar de volgende ronde … Het lijkt erop dat TDD ervan uitgaat dat opgeleverde requirements altijd voldoende basis zijn om een goede test te schrijven. Wij testers weten dat dat lang niet altijd het geval is en zijn getraind om ook gaten in de requirements bloot te leggen. Dat is een belangrijk onderdeel van onze toegevoegde waarde, bij het begin van een project. Dat kost tijd en een bouwer en de projectleider zal die tijd misschien ervaren als ‘waste’ (zinloos), omdat het in hun ogen niet direct leidt tot het uitpoepen van softwarecode. Als de ‘T’ in TDD niet door een testprofessional, maar door een ontwikkelaar wordt uitgevoerd, dan kan het zomaar gebeuren, dat TDD onterecht de indruk geeft dat een applicatie ‘cool’ is (‘hippe’ developerstaal voor ‘ik vind het mooi zo’), maar in wezen bezaaid is met bugs die alleen nog niet zijn gevonden.

Enorme impuls TDD biedt in potentie een enorme impuls door testen als een belangrijke kwaliteitsborgende (niet alleen controlerende) maatregel te zien meteen vanaf het begin van een project. In de uitvoering kan het eenvoudig tekortschieten – zoals vaker bij agile werkmethoden – als testen niet door getrainde testprofessionals worden opgezet en uitgevoerd. Maar is die professionaliteit geborgd, dan is het voor een testprofessional een sublieme mogelijkheid om kennis en vaardigheid in te zetten. Twijfel niet lang als je de mogelijkheid krijgt om mee te draaien in ieder agile project, en een TDD project in het bijzonder. Doen! Doen! Doen! Want los van het bewezen succes, dat agile methoden nu

Belangrijke kenmerken van TDD

hebben, is het vooral de fun, het krijgen van directe feedback en

Geen requirement, geen test, geen code …

respons, kort cyclisch werken en de ongekende mogelijkheden die

Alle testen worden geautomatiseerd

multidisciplinaire teams bieden, gewoon ‘chill’ (straattaal voor iets

Refactoring (optimaliseren van de code)

dat ‘best wel OK’ is ).

Pagina 13

BOEKRECENSIE: TESTWOORDENBOEK Door Rudi Niemeijer • [email protected]

Uitgeverij: Tutein Noltenius ISBN: 9789490986018 Auteurs: Erik van Veenendaal, Meile Posthuma Er zijn situaties denkbaar waarin een tester een beroep wil doen op een vaktechnisch woordenboek, zoals bij een communicatief conflict, nieuwsgierigheid naar de oorsprong van een woord, het zoeken naar synoniemen of het vertalen van of naar het Engels. Voor die situaties hebben Van Veenendaal en Posthuma hun Testwoordenboek gepubliceerd. Het is een compact boekje geworden dat in beginsel Engelstalig is opgezet met voor ieder woord een Nederlandse vertaling. De auteurs hebben bij het samenstellen van dit boek gebruikgemaakt van de ISTQB syllabi en woordenlijsten en dat maakt het testwoordenboek in beginsel een autoritief werk. Het lijkt er echter op dat er niet al te ver buiten het ISTQB-domein is gezocht. Veelvoorkomende TMap®- en TestFrame-termen vind je niet in dit boek terug. 'Datacombinatietest', 'testvorm' en 'uitgangssituatie' zoek je bijvoorbeeld tevergeefs. Ieder Engelstalig woord is met zijn Nederlandse vertaling opgenomen. Die vertaling doet echter bij tijd en wijle nogal krampachtig aan. Zo is 'installation wizzard' vertaald in 'installatie wizzard' (in plaats van 'installatieassistent') en 'failure mode' in 'foutmode' (in plaats van 'faalwijze'). Deze twee voorbeelden behoren nog tot de minder opvallende, Nederlandse vertalingen als 'arc testen', 'foutzaaien' en 'debugging' zijn heel schrijnend. Bij veel woorden is een verwijzing opgenomen naar andere, bijbehorende woorden zoals synoniemen of alternatieven. Een gemis is het ontbreken van paginanummers bij de verwijzingen. Als je zoekt naar een Nederlandse term, moet eerst in de bijlage de Engelse term worden opgezocht en dan zonder hulp van paginanummers gebladerd worden naar de Engelse term. Een groot aandeel van ons werkgebied valt binnen de (technische) communicatie en een gemeenschappelijk idioom is hierbij onontbeerlijk. Dit testwoordenboek hoort dan ook op het bureau van iedere testprofessional. Wel kijken we uit naar een tweede herziene druk, waarin de kritieken zijn verwerkt.

SOFTWARE TESTERS BENCHMARK EEN SUCCES! Door Ard Kramer • [email protected]

Op het najaarsevenement van TestNet vorig jaar is het startschot gegeven voor de eerste Software Testers Benchmark. Het doel van de benchmark is inzicht te krijgen in de werkzaamheden van testers, hun kwalificaties en in wat voor organisaties testers actief zijn. Dit hebben we de tester @ work genoemd.

Pagina 14

De benchmark is een onderzoek, zoals dat nog nooit in Nederland op een dergelijke schaal is uitgevoerd. Een half jaar na de start kunnen we constateren dat de belangstelling voor de benchmark groot genoeg is om te spreken van een representatieve steekproef. Op het moment van schrijven hadden ruim driehonderd testers de benchmark ingevuld. En natuurlijk kan de benchmark nog steeds worden ingevuld op www.softwaretesten.nl. Ga dat vooral doen, omdat het de kwaliteit van het onderzoek verder verbetert! En de resultaten? Tja, daar moeten we nog even op wachten. De resultaten zullen in het juninummer van TestNetNieuws worden gepresenteerd, nadat ze eerst door de betreffende werkgroep van TestNet zijn geanalyseerd. En dat er interessante uitkomsten tussen zitten, is nu al een feit. Waar zou jij trouwens op inzetten, als je iets mocht verbeteren in jouw testtraject? Meer budget? Beter proces? Hogere kwaliteit testers? Naast het invullen van de benchmark op www.softwaretesten.nl kun je er ook je e-mailadres achterlaten om direct geïnformeerd te worden over de uitkomsten. Heb je vragen over de benchmark, neem dan contact op met Ard Kramer via [email protected] of telefonisch via nummer 06 1478 1268.

THEMA-AVOND 9 FEBRUARI 2011 - ISTQB CERTIFIED TESTER EXPERT LEVEL Door Arthur van Rossum • [email protected]

Na het tamelijk rustige diner stroomde NBC zaal 11 toch bijna helemaal vol. De belangstelling voor ISTQB, en dan in het bijzonder het Expert Level, mag je dus gerust hoog noemen. Rik Marselis, BNTQB bestuurslid, maar vanavond in de functie van TestNet evenementencommissievoorzitter, leidde de presentaties in.

BNTQB Chris van Bael, secretaris van de Belgium and Netherlands Testing Qualifications Board (BNTQB), gaf een korte inleiding over de organisaties ISTQB, BNTQB, ISEB en ISQi en welke rollen zij in het certificatiespectrum spelen. Eigenlijk waren alle bezoekers al gecertificeerd op ISTQB Foundation Level, dus heel veel woorden behoefde deze introductie niet. Bij het voorstellen van het bestuur bleek dat nagenoeg het hele BNTQB bestuur in de zaal aanwezig was, zodat we meer dan alleen de pasfoto’s te zien kregen.

Doelgroep Expert Level Een interessant onderdeel van de presentatie betrof het totaal aantal ISTQB certificaten dat inmiddels is uitgereikt. Wereldwijd betreft het zo’n 155.000 certificaten. Daarvan vallen er 7336 onder de BNTQB. Hiervan zijn 6880 op Foundation level. Op Advanced level zijn er 208 Test Manager, 177 Test Analyst en 71 Technical Test Analyst certificaten uitgereikt. De doelgroep voor ISTQB Expert Level bestaat uit de Advanced Level gecertificeerden en de ISEB Practitioners.

Wat is een Expert? Hoe wordt een Expert dan omschreven? Het gaat om iemand die de kennis en vaardigheden heeft om een autoriteit te zijn in een specifiek testonderwerp. Daartoe staat de expert op een gevorderd punt in de carrière, heeft naast een brede algemene kennis van het testvak ook een diepgaand begrip van een specialisme en is in staat op

Pagina 15

dat gebied de richting binnen een organisatie te beïnvloeden. Een expert kan zijn testspecialisme in ieder geval ‘propageren’ en ‘advoceren’, zeg maar bevorderen en ervoor op de bres springen.

Credits Vooralsnog zijn de volgende onderwerpen voor Expert Level vastgesteld: ‘Improving the Test Process’, ‘Test Management’, ‘Tools’ en ‘Security’. Een belangrijk verschil met de Foundation en Advanced Levels zit hem in de houdbaarheid van de certificaten. Het Expert Level certificaat blijft namelijk maar vijf jaar geldig. Binnen deze periode kunnen ‘Extension Credits’ worden verdiend. Je hebt er tweehonderd nodig om de geldigheid van het certificaat te verlengen met weer vijf jaar. De credits worden gegeven voor bezigheden binnen het vakgebied. Alleen je dagelijkse werk doen levert in ieder geval niet de benodigde tweehonderd credits op. Er wordt dus meer van je verwacht, van het volgen van cursussen tot het schrijven van boeken. Lukt het niet om deze credits bij elkaar te sprokkelen, dan mag je altijd nog opnieuw examen doen. Voor de precieze uitleg van deze Certification Extension Policy verwijs ik graag naar: http://istqb.org/download/attachments/2326645/ISTQB_EL_Cert_Ext_Policy_v10.pdf?version=1&modificationDate=1276699526000 .

Syllabus Als eerste is de Expert Level syllabus ‘Improving the Test Process‘ nu officieel vrijgegeven. Om aan het examen te mogen deelnemen moet je al een beetje een expert zijn: ISTQB Advanced Test Manager certificaat plus vijf jaar testervaring waarvan twee jaar in het expertisegebied en een publicatie of presentatie in het expertiseonderwerp. De onderwerpen van de syllabus zijn een uitbreiding op de Test Manager versie. Daar waar TM testprocesverbetering op het niveau van ‘begrijpen en kunnen toepassen’ behandelt, gaat het bij dit Expert level om ‘kunnen adviseren en implementeren’. Daartoe zijn ook de Knowledge levels K5 (evaluate) en K6 (create) geïntroduceerd. Je moet in staat zijn om voor een probleem methoden te evalueren en nieuwe oplossingen te creëren waar de gebaande wegen geen soelaas bieden. In grote lijnen komt het erop neer dat een Advanced Test Manager ‘practical management’ toepast, terwijl een Expert Test Manager zich vooral bezighoudt met ‘strategic management’.

Cursusopbouw en examen Om de benodigde kennis te vergaren zal de cursus bestaan uit zes dagen theorie en twee dagen huiswerk en praktijk. Het examen omvat één uur multiple choice (K2-K4) en een essay van twee uur met de K5 en K6 cases. Voor de koffiepauze heeft Chris nog wat vragen beantwoord met betrekking tot verwachte aantallen examenkandidaten, noodzakelijke samenwerking van trainingproviders en opzet van de examens. Na de pauze presenteerde Marcel Kwakernaak, lid van de werkgroep syllabi, ons in vage termen iets over de expert module ‘Test Management’. Niet dat Marcel op enige manier vaag was, maar de syllabus is nog niet klaar en dus niet vrijgegeven. Al te specifieke uitspraken zouden in dit stadium dus niet verstandig zijn. De release van de syllabus wordt verwacht in juni 2011 op de conferentie in Rome. Na de sprekers hartelijk te hebben bedankt met een presentje en een hartelijk applaus hebben we ons natuurlijk met overgave aan de netwerkborrel gewijd. Het aangename geroezemoes daarvan is op zich al voldoende reden om TestNet lid te zijn.

Pagina 16

PUBERTIJD OF MIDLIFE CRISIS? Door Maarten Beks • [email protected]

Soms heb je van die nachten, dat je de slaap niet kunt vatten en dat de wil om te slapen het verliest van ongewenste gedachtespinsels in je hoofd. Gelukkig heb ik niet vaak last van dit verschijnsel, maar een tijdje geleden werd ik midden in de nachtelijke uurtjes toch gegrepen door de vraag ‘Hoe volwassen is het vakgebied testen eigenlijk?’. Voor de duidelijkheid: de nachtelijke reis ging niet over de testvolwassenheid van een project of een organisatie, maar over de volwassenheid van ons vakgebied. Het uiteindelijke resultaat van dit soort overpeinzingen is, dat je geen eenduidig antwoord op zo’n vraag kunt geven, maar dat je je ‘s ochtends wel gelukkig mag prijzen met wallen onder de ogen. Omdat de nachtelijke vraag me toch is blijven intrigeren, ben ik beetje bij beetje een mening gaan vormen over het antwoord. Dit artikel geeft een viertal voorbeelden, waaruit blijkt dat het vakgebied testen nog een aantal stappen moet doormaken om het predicaat ‘volwassen’ te mogen dragen. Deze voorbeelden gaan achtereenvolgens over eenduidige definities, de verantwoordelijkheid voor het maken van een productrisicoanalyse, de positie van testen ten opzichte van het gekozen ontwikkelmodel en over de positionering van testen door ICT media.

Definities Het eerste voorbeeld komt voort uit het feit dat mensen zich veilig voelen bij zekerheden. Daar wij als testers (geloof het of niet) ook tot het menselijke ras behoren, willen wij een aantal zekerheden borgen. Dit doen we bijvoorbeeld door gebruik te maken van heldere, eenduidige definities. De onderstaande definities proberen dit tevergeefs te bewerkstelligen. Test type (ISTQB Testwoordenboek - pagina 111, van Veenendaal / Posthuma, 2010): ‘A group of test activities aimed at testing a component or system focused on a specific test objective, i.e. functional test, usability test, regression test, etc. A test type may take place on one or more test levels or test phases. [After TMAP]’ Testvorm (TMap Next® - pagina 51, Koomen, van der Aalst, Broekman, Vroon): ‘Een testvorm is een groep testactiviteiten met het oogmerk het informatiesysteem op een aantal samenhangende (deelaspecten van) kwaliteitsattributen te controleren.’ Op pagina 175 van hetzelfde boek wordt het begrip testvorm verder verduidelijkt door de volgende zinsneden: ‘… Op zijn simpelst is dit een test van een kwaliteitsattribuut, bijvoorbeeld functionaliteittest of performancetest, maar vaak kan en moet er al meer inzicht gegeven worden. Zo zijn andere testvormen horend bij het kwaliteitsattribuut functionaliteit, bijvoorbeeld multi-user test, regressietest of ketentest …’ Test type (TestFrame - pagina 9, Schotanus): ‘Test types cover specific test objectives, for example, reliability, conversion, safety, performance, regression, stress and user-friendliness. The test types cover both functional and non-functional requirements.’

Pagina 17

Onze jeugd Laten we deze definities eens in ons achterhoofd houden en een uitstapje maken terug naar onze jeugd. Wie heeft er namelijk niet gespeeld met een blokkenkar met daarin blokken van verschillende vormen, kleuren en materialen: Vormen: kubus, bol, cilinder Kleuren: rood, geel, blauw Materialen: hout, plastic, aluminium Zo’n blokje is een object dat zich laat omschrijven door de eigenschappen vorm, kleur en materiaal. Zo zijn er bijvoorbeeld ‘aluminium’ cilinders met de kleur ‘rood’. Maar wat er bijvoorbeeld niet is, is een kubus met de kleur ’hout’, want we vinden het niet logisch om aan de eigenschap kleur de waarde ’hout’ toe te kennen. Is het dan niet vreemd, dat in de definities van testtype (ISTQB en TestFrame) en testvorm (TMap Next) wel zo’n gedachtekronkel gemaakt wordt door regressietesten in één adem te noemen met de welbekende kwaliteitsattributen? Is het in deze niet logischer om een onderscheid te maken tussen (initiële) test, regressietest en hertest enerzijds en de kwaliteitsattributen anderzijds?

Objectgeoriënteerde benadering Laten we het object ‘test’ eens eenduidig proberen te beschrijven aan de hand van verschillende kenmerken, zoals test level, test kwaliteitsattribuut, testtype, test soort, test trigger en testvorm: Test level:

Levels uit het V-model

Test kwaliteitsattribuut: Kwaliteitsattributen gebaseerd op ISO 9126 Testsoort:

Initiële test, hertest, regressietest

Testtype:

Dynamisch, statisch

Test trigger:

Nieuwbouw, incident

Testvorm:

Positief, negatief

Door dit voorbeeld van een objectgeoriënteerde benadering van ‘test’ kunnen definities, zonder het maken van een categoriefout, eenduidig vastgelegd worden, zodat ook de eeuwige spraakverwarringen binnen ‘testland’ voorkomen kunnen worden. Het eenduidig vastleggen van definities is in de perceptie van de auteur dan ook één van de randvoorwaarden om door te groeien naar een echt volwassen vakgebied.

Productrisicoanalyse Een ander aspect waarbij we als testers niet uitblinken in volwassenheid is gerelateerd aan de productrisicoanalyse. Laat ik vooropstellen dat ik het principe van risk based testing onderschrijf, waarmee ik me impliciet conformeer aan het idee dat een productrisicoanalyse hier een belangrijk hulpmiddel voor is. Echter, het is zo dat kwaliteit niet alleen de verantwoordelijkheid van de tester is, maar een gezamenlijke doelstelling van alle vakgebieden binnen een project moet zijn. Voorbeelden hiervan zijn softwareontwikkeling, infrastructuur, security, architectuur en natuurlijk business afdelingen zoals marketing, binnendienst en debiteurenbeheer. Al deze verschillende vakgebieden en afdelingen hebben daarom ook baat bij een productrisicoanalyse. Zo kan de ontwikkelteamleider bijvoorbeeld de beste programmeurs inzetten op de gebieden met het hoogste risico en kan infrastructuur de servers die deze gebieden ontsluiten redundant uitvoeren.

Pagina 18

Geen testproduct De uiteindelijke kwaliteit van een informatiesysteem is dus een gezamenlijke inspanning van de verschillende vakgebieden binnen een project, waarbij de tester objectief probeert vast te stellen of de gewenste kwaliteit al dan niet behaald is. Omdat we uiteindelijk maar een klein radertje in het geheel zijn, zet ik vraagtekens bij de testmethodieken die stellen dat een productrisicoanalyse een product van testen moet zijn. Juist omdat alle vakgebieden gebruik kunnen maken van een productrisicoanalyse, zal het de (ICT-)projectmanager moeten zijn, die het belang hiervan inziet en daarom het voortouw zal moeten nemen in de uitvoering ervan. Dat testers hierbij een belangrijke rol kunnen spelen, behoeft geen nadere uitleg, maar dat het de verantwoordelijkheid en daarmee een primair product van de tester is, gaat echt een brug te ver. Laten we nu eens een keer met de vuist op tafel slaan (hetgeen alleen mag als je volwassen bent) en de aanwezigheid van een productrisicoanalyse als entry criteria in onze testplannen opnemen. Als er nog geen requirements zijn, dan gaan we deze toch ook niet vanuit test opstellen …

De wereld op zijn kop Het derde voorbeeld waaruit, vanuit mijn belevingswereld, blijkt dat testen nog niet gezien kan worden als een oude man met de nodige levenservaring heeft te maken met ‘fitting’. Vaak wordt gesteld dat testen zich moet aanpassen aan het gekozen ontwikkelmodel. Voorbeelden hiervan zijn het V-model en iteratieve modellen inclusief de moderne varianten daarvan zoals Agile en scrum. Dat het ontwikkelmodel en het testmodel bij elkaar moeten aansluiten of, nog beter, elkaar moeten versterken, zal ik niet in twijfel trekken. Wat ik echter wel in twijfel trek, is dat het gekozen ontwikkelmodel daarbij leidend is. Het lijkt er in dat geval op dat softwareontwikkeling als belangrijker gezien wordt dan testen en daarom de leidende rol op zich kan nemen. Maar waarom wordt dit niet omgedraaid en geven we de tester de leidende rol door hem te laten bepalen hoe hij het testproces optimaal kan inrichten, zodat objectief vastgesteld kan worden of de door de klant gewenste kwaliteit behaald wordt. Door deze benadering zullen de andere betrokken vakgebieden zich moeten conformeren aan de uitgangspunten die een testafdeling voorschrijft. Is dit nu de wereld op zijn kop, een utopie, of is dit een statement waaruit de echte volwassenheid van testen zal moeten blijken?

De buitenwereld De mening van een auteur over testen is één, maar wat vindt de buitenwereld nu eigenlijk van testen? Laten we hiertoe de beeldvorming op de website van Computable eens onder de loep nemen. Waar op de website kunnen we logischerwijs het vakgebied testen verwachten? Mijn eerste zoekactie betrof het openen van het menu-item ‘ICT Topics’, hetgeen in alle bescheidenheid toch niet zo’n vreemde keuze is. Helaas, u gaat niet door voor de cruise naar de Caribean. Binnen dit menu-item staat testen namelijk niet vernoemd. Na enig speurwerk bleek testen gefragmenteerd ondergebracht te zijn onder de vlag van al de verschillende ‘ICT Topics’. Blijkbaar wordt testen door de internetredactie van Computable niet gezien als een hoofd-item binnen de ICT. Wie heeft er nu niets van begrepen: ik, de redactie van Computable.nl, of is dit de gangbare positionering binnen de ICT?

Lang niet volwassen Hoe dan ook, met de vier bovenstaande voorbeelden heb ik proberen aan te geven dat het vakgebied testen naar mijn idee nog niet als volgroeid gezien kan worden. Omdat iedere, dus ook mijn waarheid, een vorm van perceptie is, zal ieder voor zich moeten uitmaken in welke fase van volwassenheid testen zich bevindt.

Pagina 19

VISIE OP TESTEN VOLGENS… Onder redactie van Kees Blokland • [email protected]

Een nieuw terugkerend onderdeel van TestNetNieuws is: ‘Visie op testen volgens …’. Iedere editie geeft een testleverancier een actuele visie op de ontwikkelingen in het testvak. Op die manier willen we de lezer graag trakteren op verrassende insteken en prikkelende visies. Kortom, we rekenen op veel leesplezier! Het spits wordt hieronder afgebeten door drie testprofessionals van SQS.

TESTING, THE NEAR FUTURE Door Mischa Maliepaard, Jan van der Hoeven en Asad van Gelderen - SQS Nederland BV

Als we naar de huidige testmarkt kijken, dan zien we een aantal interessante ontwikkelingen. Projecten gaan steeds meer werken volgens Agile en ook Cloud computing vindt steeds meer haar weg naar organisaties. In ons testvak is het belangrijk om hierin mee te gaan en onze testmethodieken en visie hierop aan te passen. Daarnaast zien we bij organisaties wederom een beweging om testactiviteiten uit te besteden. Hierbij onderkennen we wel een verschil met de situatie van een aantal jaren geleden, die we kunnen onderbrengen in vier trends: 1. het groeipad om tot outsourcing en/of offshoring te komen; 2. de beweging van offshoring naar nearshoring; 3. de rol van de testmanager; 4. tooling.

Het groeipad We zien bij organisaties wederom een beweging om testactiviteiten uit te besteden. Met de nadruk op wederom, omdat we deze beweging ook al een aantal jaren geleden zagen. Er is nu echter een verschil met de vraag van toen. Organisaties vragen in deze markt om een oplossing waarbij een geleidelijk en realistisch groeipad wordt ingezet om testactiviteiten uit te besteden. Hierbij hebben ze geleerd van ervaringen uit het verleden. Denk hierbij aan de uitbesteding van testactiviteiten zonder te borgen dat de organisatiespecifieke ontwikkel- en testprocessen goed aansluiten op de testprocessen van de testleverancier. De hedendaagse vraag is dan ook om een realistisch groeipad te definiëren. Dit groeipad bestaat uit enkele voorgedefinieerde mijlpalen die we hebben vertaald naar zogeheten Maturity Levels. Kortweg houden deze niveaus in: 1. Non-Structured Testing: testen is onvoldoende belegd binnen de organisatie. Geen inzicht in de kwaliteit van het testobject op basis van testresultaten. Testactiviteiten worden ad hoc uitgevoerd. 2. Structured Testing: het testproces is ingericht waarbij inzicht ontstaat in en controle over het testobject en testproces ten aanzien van tijd, geld en kwaliteit. 3. Professional Testing: in deze fase verschaft het testproces inzicht in en stuurt op de kwaliteit van aanleverende (ontwikkel)processen richting test. Daarnaast zijn producten en meetinstrumenten ingericht die het mogelijk maken om testactiviteiten in het volgende niveau vanuit een resultaatverplichting af te nemen. 4. Outsourced Test Services: de klant neemt testactiviteiten af bij de testleverancier waarbij de testleverancier een resultaatverplichting heeft.

Pagina 20

5. Offshored Test Services: gelijk aan niveau 4 met het verschil dat de testleverancier de testactiviteiten uitvoert buiten de klantlocatie. We gebruiken deze niveaus als basis voor onderstaand (verbeter)proces. Het proces dat we met de organisatie doorlopen bestaat uit de volgende stappen: 1. Het bepalen van de langetermijndoelstelling van de klant op het gebied van testen. 2. Het uitvoeren van een assessment op de huidige situatie, waarin de volwassenheid wordt afgezet tegen bovengenoemde Maturity Levels. 3. Het opstellen van een testrapport waarin de resultaten van het assessment zijn uitgewerkt. 4. Het definiëren van een specifiek groeipad. Dit groeipad wordt gezamenlijk met de klant opgesteld en hiervoor worden de resultaten van het assessment en de langetermijndoelstelling gebruikt. 5. Het uitvoeren van het specifieke groeipad waarin (een aantal van) de Maturity Levels worden doorlopen. Samenvattend kunnen we gerust zeggen dat het groeipad naar uitbesteding van testactiviteiten een maatwerkoplossing is.

Nearshoring In de marktbeweging van testactiviteiten uitbesteden zien we een tweede trend ontstaan die deze testactiviteiten in de buurt van de klantlocatie behoudt. Kortweg de trend van offshoring naar nearshoring. Onder nearshoring verstaan wij dat de testactiviteiten (of delen daarvan) uitbesteed worden naar een locatie binnen eigen land of binnen Europa. Dit in tegenstelling tot Offshoring waarbij de testactiviteiten overgeplaatst worden naar overzeese locaties, zoals India. In onze analyse zien wij vier redenen van deze trend: 1. Europese eenwording: de laatste jaren zijn er meer en meer landen toegevoegd aan de Europese Unie, waaronder enkele voormalige Oostbloklanden. Het overbrengen van werkzaamheden naar deze locaties is eenvoudiger vergeleken met niet-Europese landen door bijvoorbeeld de (Europese) wetgeving die gelijkgetrokken is. 2. Culturele verschillen: ook binnen Europa zijn er culturele verschillen tussen landen die gebrekkige communicatie kan veroorzaken. Deze verschillen zijn echter minder groot dan die tussen Europese en niet-Europese landen. 3. Kosten: in landen zoals India zijn de lonen de laatste jaren aanzienlijk gestegen. Hierdoor is het verschil met de testkosten op de klantlocaties kleiner geworden en in sommige gevallen is uitbesteding niet meer rendabel. In de lagelonenlanden binnen Europa zijn de testkosten nog wel aanzienlijk lager dan de kosten op de klantlocatie, zodat uitbesteding een kostenbesparing oplevert. 4. Taal: veel mensen spreken tegenwoordig meerdere talen. Toch blijft het lastig om je uit te drukken in een andere taal dan je moedertaal. In het geval van nearshoring kan de klant kiezen voor een locatie waarbij de moedertaal gelijk is.

De rol van de testmanager In de beweging van testactiviteiten uitbesteden zien we een derde trend ontstaan in de rol van de testmanager. Deze rol wordt uitgebreid met aandachtsgebieden voor project- en contractmanagement en leidinggeven aan teams op meerdere (internationale) locaties.

Pagina 21

Reden hiervoor is dat opdrachten met off- of nearshoring als component veelal worden uitgevoerd in de vorm van een resultaatverplichting die is vastgelegd in een onderliggend contract. Een testmanager zal in zijn werkzaamheden dan niet alleen bezig zijn met het inrichten en managen van een testaanpak, maar ook project- en contractmanagement uitvoeren op de resultaatverplichte opdracht. Hierbij stuurt hij bijvoorbeeld op de afbakening van het contract (in plaats van het testplan) en de marges die in het contract zijn opgenomen. Daarnaast geeft hij leiding aan testteams in een internationaal speelveld waarbij een team bijvoorbeeld deels op de klantlocatie is gevestigd en deels op de near- of offshore locatie(s).

Tooling Ook de kennis van en kunde met tooling is de laatste jaren enorm toegenomen bij de off- en nearshore partijen. Met name ten aanzien van automatisch testen is dit een kans die benut moet worden. Zoals bekend is het geautomatiseerd testen uitermate geschikt voor regressietesten. Een kostbare en vaak saaie taak die we graag uitbesteden. De vraag is enkel nog om het uitbesteden tot een succes te maken. Hierbij moet naar een goede samenwerking worden gezocht tussen de functionele- en businesskennis van de klant en de technische kennis bij de dienstverleners. Het off- en nearshore produceren van kleine geautomatiseerde modules kunnen hier, onsite, tot zinvolle regressiesets worden opgebouwd. Voor uitvoering van deze automatische tests kiest men vervolgens weer voor off- en nearshore. Deze methode is tevens een manier die redelijk kleinschalig en tegen overzichtelijke kosten geïmplementeerd kan worden. Vervolgens breidt men na fine-tuning steeds uit. Samenvattend kunnen we concluderen dat klanten selectiever zijn geworden en lering getrokken hebben uit ervaringen uit het verleden. Klanten

SQS bestaat sinds 1982 en is met ruim 1800 medewerkers wereldwijd de groot-

willen groeien, maar wel op een manier die bij hun organisatie past

ste onafhankelijke leverancier van kwali-

(maatwerk). Organisaties zijn (nog) steeds geïnteresseerd in het uitbeste-

teitsmanagement en testservices. SQS

den van testactiviteiten, maar wel op een dusdanige manier dat het de

heeft met meer dan 5000 succesvolle

dagelijkse gang van zaken zo min mogelijk stoort. Geautomatiseerd testen

afgeronde projecten een sterke klanten-

blijft ook de komende jaren een geliefd onderwerp wanneer het in staat is

portfolio en aansprekende referenties.

om de klantwensen zo goed(koop) mogelijk in te vullen. Kortom, testen blijft in ’the near future’ zeker uitdagend!

Pagina 22

MIJNPENSIOENOVERZICHT.NL Door Aäron Post • [email protected]

In januari van dit jaar is de website www.mijnpensioenoverzicht.nl gelanceerd. Deze nieuwe website heeft als doel om AOW- en pensioeninformatie te verschaffen zodat burgers weten waar ze aan toe zijn. Concreet wordt er informatie verstrekt over wát iemand in het verleden bij zijn verschillende pensioenuitvoerders heeft opgebouwd, welke pensioenuitvoerders dat zijn en wat hij tot zijn pensioenleeftijd kan opbouwen op basis van een ongewijzigde situatie. Ook de AOW-aanspraken worden getoond. Het is geen doel om mensen pensioenbewustzijn bij te brengen, maar dat is wel een verwacht neveneffect. Mijnpensioenoverzicht.nl is als gratis publieke dienstverlening beschikbaar en de functie is puur informatief en niet adviserend.

Applicatie in hoofdlijnen Om gelijk een eventueel misverstand uit de wereld te helpen: mijnpensioenoverzicht.nl is geen database. Het Pensioenregister registreert alleen bij welke pensioenadministrateur(s) en welke pensioenuitvoerder(s) voor een burger pensioengegevens aanwezig zijn. Dit wordt de verwijsindex genoemd. De website maakt van verschillende webservices gebruik om gegevens van een persoon te verzamelen nadat deze is ingelogd. Het ophalen van de AOW– en pensioengegevens gebeurt realtime bij de betreffende pensioenuitvoerder (fonds of verzekeraar) of pensioenadministrateur. Welke partijen dat voor de ingelogde burger zijn, wordt geverifieerd aan de hand van de verwijsindex (zie figuur 1). Onderstaand schema is een vereenvoudigde weergave van de applicatie en zijn omgeving.

Figuur 1: De context tussen mijnpensioenoverzicht.nl en haar omgeving

Pagina 23

Toelichting bij figuur 1: 1. Burger De burger heeft toegang tot mijnpensioenoverzicht.nl, het digitaal loket. Dit bestaat uit een publiek gedeelte en een besloten deel. Hij kan, na aanmelding door middel van DigiD op het besloten deel inzage krijgen in zijn pensioenaanspraken. 2. DigiD DigiD draagt zorg voor het aanmelden en daarmee bevestigen van de authenticiteit van de burger die zich aanmeldt, 3. Sociale Verzekeringsbank (SVB) De SVB verstrekt de naam en de leeftijd van de burger en de AOW bedragen. 4. Pensioenadministrateur De pensioenadministrateur geeft namens de pensioenuitvoerder(s) de pensioenaanspraken door bij bevraging vanuit het Pensioenregister. De pensioenadministrateur geeft via de verwijsindex aan bij welk pensioenfonds pensioengegevens voor de burger aanwezig zijn. Daarnaast meldt de pensioenadministrateur periodiek wijzigingen op de verwijsindex (bijvoorbeeld als gevolg van wisseling van werkgever).

Proces van testen De meeste aandacht in het testen van de webapplicatie is uitgegaan naar de koppelvlakken ofwel de verschillende webservices zoals weergegeven in figuur 1. Dat is begrijpelijk, want hier liggen ook de meeste risico’s. Een niet werkende koppeling betekent immers dat de burger geen, of onjuiste gegevens ziet. De eerste zorg was dan ook het inrichten van de testomgeving met gesimuleerde koppelvlakken en de bijbehorende testdata. Omdat er bij het testen van deze webservices geen fysieke koppelingen beschikbaar waren, is gebruikgemaakt van stubs, die met behulp van Parasoft SOAtest zijn ingericht. Met deze werkwijze zijn alle mogelijke interacties die via de webservices verlopen gevirtualiseerd in de testomgeving. De interacties die daaronder vallen, zijn het creëren en muteren van records in de verwijsindex (zie figuur 1, punt 4), het opvragen en juist weergeven van de AOW-aanspraken (zie figuur 1, punt 3) en het opvragen en juist weergeven van pensioenaanspraken (zie figuur 1, punt 4). Ondanks de redelijk eenvoudige transacties kom je al gauw tot een grote verscheidenheid aan situaties in zowel de positieve als negatieve testgevallen. Het merendeel van het testtraject heeft zich gefocust op functionaliteit, maar er zijn natuurlijk ook andere kwaliteitsattributen van de website en de koppelvlakken getest. Dat zijn onder andere gebruikersvriendelijkheid, portabiliteit, performance en beveiliging. Bijna alle kwaliteitsattributen zijn door onafhankelijke (externe) partijen getest.

Aansluittraject Al in april 2010 is begonnen met het fysiek tot stand brengen van de benodigde koppelingen met de pensioenuitvoerders en -administrateurs. Daarvóór werden al initiële keten (integratie)testen met enkele van de grotere aansluitende partijen uitgevoerd om het proces van aansluiten en de aansluitingen zelf te testen. De aansluitende partijen hebben een gestandaardiseerd proces moeten doorlopen voordat hun aansluiting gereed was. Na het intern realiseren van de voorzieningen die nodig waren om aan te sluiten op mijnpensioenoverzicht.nl was de eerste activiteit binnen dit proces een zelftest, met behulp van een webapplicatie die was ontwikkeld door de programmaorganisatie van het Pensioenregister. Hiermee konden partijen hun interactie met de applicatie op technisch

Pagina 24

niveau testen. Na afronding van deze zelftest werd door het Pensioenregister nog een toets gedaan op de werking van de aansluiting om na te gaan of aan alle eisen was voldaan. Pas na succesvolle afronding van deze zogenoemde conformiteitstoets, uitgevoerd door de programmaorganisatie van het Pensioenregister met een gestandaardiseerde testset, kregen partijen toegang tot de productieomgeving. De eerste activiteit in de productieomgeving was het aanleveren van de gegevens voor de verwijsindex. Als de verwijsindex correct ontvangen en verwerkt was voerde de betrokken partij nog een zogenoemde deelnemerstoets uit. Deze toets behelsde het inloggen door een of meer ’echte deelnemers’ van het betrokken pensioenfonds om zo vast te stellen of hun pensioenaanspraken volledig en correct werden weergegeven. Na succesvolle afronding hiervan werd de betrokken partij formeel gedechargeerd voor de aansluiting. Het testteam bij het Pensioenregister had naast de uitvoerende ook een ondersteunende rol in het aansluitproces, met name in het beantwoorden van vragen over de technische en functionele aspecten, maar ook rondom het analyseren van problemen in de aansluiting. Hierbij trad het testteam vaak op als intermediair tussen technisch beheer (aan Pensioenregister zijde) en de aansluitende partij. Persoonlijk vond ik het overigens een leuke rol om als schakel tussen de partijen op te treden.

Massale test In november 2010 heeft er in samenwerking met de aangesloten pensioenuitvoerders en de SVB een massale test (vergelijkbaar met een real-life test) plaatsgevonden. Het doel van de test was het gedrag van de applicatie te testen bij realistisch gebruik. Voor de test zijn medewerkers van de verschillende aangesloten partijen uitgenodigd om deel te nemen. Op een vastgesteld tijdstip was de website beschikbaar voor alle deelnemers. Hiermee hadden zij de mogelijkheid in te loggen en hun pensioengegevens in te zien. De response op de uitnodiging voor de massale test was zeer groot. Er hebben ongeveer duizend personen deelgenomen aan de test. De resultaten uit de test waren zeer bruikbaar in die zin dat we de nodige optimalisaties in de infrastructuur en resource gebruik van het systeem hebben kunnen doorvoeren.

Lancering Ondanks alle voorbereidingen is het natuurlijk een spannende dag op het moment dat de website publiek toegankelijk is. Op 6 januari 2011 was het zover. Op deze lanceringsdag hebben meer dan één miljoen pageviews door burgers plaatsgevonden. Inmiddels kijken we terug op een zeer geslaagde lancering en zijn we al weer volop bezig met het doorontwikkelen van mijnpensioenoverzicht.nl met aanvullende functionaliteit.

BRUGGEN BOUWEN MET VISUAL STUDIO (1) Door Marcel de Vries • [email protected]

Hoe kunnen testers en ontwikkelaars beter met elkaar samenwerken?. Dat ga ik proberen te laten zien in een serie van twee artikelen over Visual studio 2010 Ultimate edition. Unit testen is vandaag de dag een volledig ingeburgerd principe als het gaat om de kwaliteit en onderhoudbaarheid van software te verbeteren. Wat echter vaak onderbelicht blijft, is het herhaalbaar en gestructureerd functioneel testen of de software wel voldoet aan de requirements die vooraf of gedurende het project zijn opgesteld in samenwerking met de klant.

Pagina 25

Meestal is in een projectplan wel voorzien dat de eindgebruikers de applicatie uiteindelijk moeten accepteren door middel van een acceptatietest, maar helaas is dit maar al te vaak een sluitpost van de begroting. Laat staan dat er wordt geïnvesteerd in het herhaalbaar vastleggen van dit soort testen op een dusdanige manier dat deze direct weer herhaald kunnen worden zodra men in een later stadium nog een aanpassing maakt aan het systeem.

Forse investering Eigenlijk is dit is ook wel te verklaren, want als je dit goed wilt inregelen, moet je eigenlijk een forse investering maken in een testspecialist en bijbehorende tooling. Deze testspecialist moet je vanaf dag één laten meelopen in je project en betrekken bij het opschrijven en afspreken van de specificaties. Hierdoor worden de specificaties ook goed getest en zijn de specificaties veel beter te testen. In de dagelijkse praktijk kom ik echter maar zeer weinig een testspecialist tegen die al vanaf de allereerste dag betrokken is bij het ontwikkeltraject. Een gevleugelde uitspraak die je vaak hoort is: ‘we hebben wel testers, namelijk de eindgebruikers nadat we hebben opgeleverd.’ Verder zie je ook dat projectleiders vaak worstelen aan het eind van het project om goed inzicht te krijgen wat nu de kwaliteit is van het systeem. Natuurlijk is dit herleidbaar op het weinig gestructureerd testen en het niet meten van de kwaliteit gedurende de realisatie van het project en dit wel achteraf willen weten. Als een projectleider wel vanaf de allereerste dag gestructureerd testen wil oppakken, dan wordt die vervolgens helaas maar al te vaak geconfronteerd met het feit dat de tooling vandaag de dag, nog maar weinig ondersteuning biedt voor testen. Alleen bij de realisatie van zeer grote of bedrijfskritische systemen zie je dat er nog wel wordt geïnvesteerd in de aanschaf van tooling ter ondersteuning van de testers, maar voor de kleinere software projecten is dit toch meestal niet weggelegd.

In één oogopslag Zou het niet mooi zijn als de requirements op papier op een dusdanige alternatieve manier konden worden vastgelegd dat we gedurende het project continu inzicht houden in de voortgang en kwaliteit die wordt gerealiseerd in het ontwikkelteam. Hierbij zou je dan willen dat de testspecialist en de ontwikkelaar op een efficiënte en effectieve manier kunnen samenwerken om, naast snel bugs te vinden in requirements en de software, deze ook snel te kunnen reproduceren en oplossen. Hoe probeert Microsoft met de nieuwe Visual Studio Ultimate Edition juist het gat tussen testers en ontwikkelaars te dichten en ervoor te zorgen dat een team op een effectieve manier aan de slag kan met functioneel testen en daarbij planmatig het testen kan inrichten? En hoe slaat Microsoft de brug tussen de niet technische tester (ook wel de generalist tester genoemd) en de ontwikkelaars, zodat ontwikkelaars in één oogopslag kunnen zien wat de tester heeft gevonden en testers kunnen zien welke testen nodig zijn de code aanpassingen te verifiëren? Aan de hand van een zeer eenvoudige applicatie zal ik proberen te laten zien hoe de dagelijkse praktijk van de testers en de ontwikkelaars drastisch kan verbeteren met de komst van deze nieuwe toolset.

Functioneel testen van requirements Om op een juiste manier te kunnen testen is het allereerst van belang dat de eisen en wensen van de klant helder worden opgeschreven. Dit opschrijven kan iedereen natuurlijk doen op de manier die hij zelf het prettigst vindt. Echter, door de requirements voortaan vast te leggen in de Team Foundation Server wordt het mogelijk deze requirements ook daadwerkelijk te gebruiken voor traceerbaarheid van bug, testen en change requests. Dit vastleggen in de Team Foundation Server is mogelijk met behulp van work items. Work items zijn bedoeld voor het vast-

Pagina 26

leggen van werk wat moet worden uitgevoerd of voor meta-informatie over het te realiseren product of project. Een work item kan dus bijvoorbeeld een taak zijn voor het uitvoeren van bepaalde werkzaamheden(task work item), maar ook een user story of test case, die respectievelijk de beschrijving bevat van een requirement of een test case. Op zichzelf is het vastleggen van dit soort informatie niets nieuws in Visual Studio 2010. Dat was al mogelijk in de eerdere versies van het product, maar niet vanuit een omgeving die specifiek voor een testspecialist is ingericht. In Visual studio 2010 tools familie heeft men namelijk een nieuwe set aan test tools beschikbaar gemaakt voor de testspecialist. Deze tools zijn te vinden onder de naam Visual Studio Test Professional en zijn ook inbegrepen in de Visual Studio Ultimate Edition. Binnen dit product is een specifiek tool aanwezig onder de naam Microsoft Test Manager (MTM). Met dit tool kun je testen plannen, beschrijven, uitvoeren en rapporteren op basis van work items. In figuur 1 is een schermafdruk te zien van MTM, waarbij het formulier openstaat waarin je begint met het samenstellen van een testplan. In een testplan wordt feitelijk bepaald welke requirements we in een bepaalde periode willen gaan testen. Het uitgangspunt hierbij is dat alle requirements in de vorm van User Stories worden vastgelegd in de team foundation server. Vervolgens worden aan requirements test cases gekoppeld die de requirements op verschillende manieren testen. Het is ook mogelijk dit op basis van

Figuur 1: MTLM Testplan

eigen work item typen te doen. In dit artikel ga ik er echter vanuit dat we werken met de MSF agile proces template waarin user story work items standaard beschikbaar zijn. De applicatie die ik in dit artikel gebruikt, is bijzonder simpel. In figuur 2 is een schermafdruk te zien van de applicatie. De applicatie is een zogeheten tip calculator die je kunt gebruiken voor het berekenen van de fooi afhankelijk van in welk land je op dat moment in een restaurant aanwezig bent. De requirements zijn hiervoor opgeschreven in een aantal user stories. Deze stories zijn vervolgens opgenomen in het testplan als de requirements en daarna worden hier test cases aan gekoppeld. In figuur 3 is te zien dat het mogelijk is test cases aan te maken en waarin in detail wordt beschreven welke stappen moeten worden genomen bij het uitvoeren van de testen. Bij iedere stap is het mogelijk een verwacht resultaat op te geven. Hiermee wordt ook aangegeven dat de tester hier dan een ‘ok’ of ‘niet ok’ moet aangeven tijdens de testrun.

Figuur 2: Voorbeeld applicatie

Pagina 27

Bij iedere stap is het mogelijk gebruik te maken van parameters. Deze worden automatisch gedetecteerd zodra je een woord in de test action van een @ teken voorziet. Door het gebruik van parameters in de stappen wordt het mogelijk ook de fysieke testgevallen in te vullen door verschillende variaties in waarden van de parameters in te geven. Als je meerdere rijen met testenwaarden invult, zullen bij het uitvoeren van de testen ook extra iteraties worden geïntroduceerd. Figuur 3: Testcase beschrijving Iedere afzonderlijke rij is dan een iteratie die als goed of fout kan worden gemarkeerd na de testrun. Ook is het mogelijk een set stappen op te slaan als een Shared Test Step en deze kun je dan in andere testen hergebruiken. Als een test case beschreven is en opgeslagen, dan kan deze in het testplan worden toegewezen aan een tester, die dan in het MTM test center kan zien welke testen voor hem klaar staan om te worden uitgevoerd. Zodra een tester een test wil uitvoeren, dan kiest hij voor de optie ‘Run test’ en vervolgens zal de MTLM omgeving zichzelf minimaliseren en wordt het test center actief in de linker hoek van het scherm. Zie figuur 4.

Figuur 4: MTM in actie Hierna wordt de vraag gesteld of je ook wilt dat er een ‘Action recording’ van deze test wordt gemaakt. Als je hier het vinkje aanzet, dan zal van alle acties die worden uitgevoerd op het systeem worden vastgelegd in een action log, die vervolgens kan worden gebruikt om in een volgende testrun weer te gebruiken om de test geautomatiseerd te laten lopen. Ook is een action log te gebruiken voor het maken van een codedUItest, waar ik later op terugkom. Nadat de test is gestart, worden alle stappen getoond die waren beschreven in de test case. Je voert dan iedere stap uit en je geeft aan of deze stap een ‘pass’ of ‘fail’ was.

Pagina 28

In het geval dat de stap niet het verwachte resultaat oplevert, kan dit worden aangemerkt in de testrunner en ook worden vastgelegd door middel van een work item. Hiervoor wordt het work item type Bug gebruikt. Microsoft heeft vooral veel energie gestopt in het vastleggen van een goed reproduceerbare bug in de testomgeving. Want iedere ontwikkelaar maakt het geregeld mee dat er een bug is ingelegd in work item tracking waarbij het uren duurt om het probleem te reproduceren. In heel veel gevallen is dit zelfs zo ingewikkeld dat het niet mogelijk is de fout opnieuw aan het licht te brengen. Al met al kunnen dit soort Test, Analyseer, Reproduceer en fix cycli zeer veel tijd in beslag nemen. Om vooral dit probleem op te lossen heeft Microsoft een nieuwe innovatie beschikbaar onder de naam IntelliTrace™ . Intellitrace™ is een zogeheten trace collector die tijdens de uitvoering van een test op de achtergrond alle informatie vastlegt in een logfile over hetgeen de applicatie onder test uitvoert. Microsoft heeft dit gerealiseerd door zogeheten IL rewriting toe te passen vlak voordat de JIT compiler de code omzet naar machine code. Hierbij wordt ervoor gezorgd dat er bij iedere aanroep van een functie en het resultaat van de functie, extra informatie wordt weggeschreven. De intellitrace collector is in staat ook voor specifieke .Net technologieën zoals: ADO.NET, ASP.NET, WCF, enzovoort events te rapporteren met specifieke informatie die voor die technologie waardevolle informatie oplevert bij het opsporen van problemen. Denk bij ADO.NET aan een query string of bijvoorbeeld ASP.NET aan een BeginProcessRequest event. De events die standaard worden opgenomen zijn onder andere zaken als registry toegang, File IO, ADO.NET database operaties, ASP.NET page cycle events, Windows gestures (button click), Handled en Unhandled exceptions enzovoort. Naast al deze events kan intellitrace™ ook alle parameters die tussen methode calls inspecteren en daarvan de data wegschrijven in de logfile. Let wel op als je dit aanzet, omdat er daardoor een potentieel zeer grote file van enkele Gigabites groot kan ontstaan. Je kunt instellen wat Intellitrace™ aan standaard events en methode call logging moet uitvoeren. Dit kan in het options menu van Visual Studio en de testplan properties in MTM, bij het instellen van de omgeving. Figuur 5 laat zien dat er zeer veel informatie wordt opgeslagen zodra een Bug in MTLM wordt aangemaakt. De Intellitrace log file (*.itrace) is de uiteindelijke logfile, die alle detailinformatie bevat om direct zichtbaar te maken in de Visual studio IDE. De actionlog file is het bestand dat de automation stappen heeft weggeschreven zodat de test opnieuw geautomatiseerd kan worden uitgevoerd.

Figuur 5: Standaard attachment bij aanmaken bug

Pagina 29

De tester heeft nu zijn werk erop zitten en sluit de MTM omgeving af. Vervolgens kan hij zien in zijn testplan of er nog meer testen voor hem klaarstaan om uit te voeren. Verder kan hij ook een overzicht krijgen van de resultaten van het testplan. Dit overzicht is weergegeven in figuur 6.

Figuur 6: Inzage in de status van het testplan In de volgende TNN ga ik over naar de ontwikkelaar en zullen we zien hoe hij verder kan met een zojuist door de tester geconstateerde bug.

Pagina 30

EVENEMENTEN EN THEMA-AVONDEN Al onze evenementen en thema-avonden in 2011 worden gehouden in het NBC. Plaats:

Informatie:

Blokhoeve 1

Aanmelden kan tot uiterlijk drie werkdagen van tevoren via onze website www.testnet.org

3438 LC Nieuwegein

onder ’Evenementen’ > ’Aanmelden evenement’.

Thema-avond Usability Maandag 11 april 2011 18.00-21.00 uur Velen van jullie hebben de enquête Usability Testing ingevuld. Dank hiervoor! 186 IT-professionals en 36 usability professionals hebben hun mening gegeven. Op deze thema-avond presenteren we de resultaten. Het doel van de enquête van de kennisgroep Usability Testen van TestNet is om een beeld te krijgen van het gebruik van usability testen in IT-projecten en de kennis, meningen en mogelijkheden op het gebied van usability en usability testing te achterhalen. We delen deze kennis graag met je. Marcel Nahapiet spreekt voor de pauze over de interessante verschillen en overeenkomsten in de werelden van IT-testen en Usabilitytesten. Na de pauze kun je zelf usability tests uitvoeren in de workshop.

Voorjaarsevenement Dinsdag 10 mei 2011 9.00-21.30 uur Het voorjaarsevenement begint met drie tutorials in de ochtend van 9.00 – 13.00 uur. Tutorial 1: Bj Rollison ‘Combinatorial Testing Practices’ Tutorial 2: Clive Bates ‘Who said people issues were simple?’ Tutorial 3: Michael Bolton ‘Test Framing’ Er zijn maximaal 50 plaatsen per tutorial. Wees er dus snel bij, aanmelden kan vanaf 4 april. Deze tutorial is ALLEEN toegankelijk voor TestNet leden In de middag en avond komen de nieuwe helden aan het woord. Mensen die we nog niet eerder op grote podia hebben gezien maar die wel degelijk wat te vertellen hebben over het testvak.

Thema-avond Woensdag 22 juni 2011 18.00-21.00 uur Thema nog niet bepaald.

TestNet Summer School Woensdag 13 juli 2011 9.00-21.00 uur Op woensdag 13 juli organiseert TestNet iets nieuws. Aan het begin van de zomer, als iedereen iets meer tijd heeft en nog net niet op vakantie is, kun je je testkennis verrijken bij de TestNet Summer School. Alle sponsoren van TestNet krijgen de gelegenheid om een tutorial/workshop van drie uur te verzorgen. Wij verwachten zoveel inzendingen van de sponsoren dat we een ochtend-, een middag- en een avondprogramma hebben. Elke TestNetter kan dus op deze dag maar liefst drie tutorials naar keuze bijwonen. Op dit moment loopt de aanmelding van onderwerpen door de sponsoren nog. Zodra het programma bekend is zal het uiteraard via de website bekendgemaakt worden. Voor verdere details zie http://www.testnet.org/evenementen.html.

E v en em en te n & T hem a - a v o n de n E-mail: [email protected] Cees Dulfer Erik Hendrikx Jan-Kees Glijnis Ine Lutterman-Baars Rik Marselis Huib Schoots W illem van Strik Peter van Tulder