VAN DE REDACTIE In dit nummer

Juni 2011 • Jaargang 15 • Nummer 2 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]

Van de redactie

1

Als tester beoefen ik mijn vak bij

Van de voorzitter

2

een gerenommeerde externe

Glossy Testspecial

2

dienstverlener en raak nogal eens

Riks column

3

verzeild in projecten met nieuwe

Vijf vragen aan… Gabriel Felten

4

collega‟s, vaak op hun beurt ook

Even voorstellen… Kees Blokland

5

weer in dienst bij andere externe

Bevindingen tellen

6

dienstverleners. Ik leer dus heel

Experts gezocht!

7

wat testers van verschillend pluimage kennen. Bij ieder

Boekrecensie: grip op IT

8

nieuw project valt mij op dat testers, ongeacht hun her-

De dag van… Jolanda Habben Jansen

9

komst, samen gaan voor één gezamenlijk doel, bijdragen

Dutch Testing Conference

11

aan goede systemen met minimale risico‟s. Samenwerken

Eurostar in Manchester

13

zit ons in het bloed, evenals delen van kennis en uitwisse-

BJ Rollison at the testnet Spring event

16

Succesvolle aansturing van offshore testteams

17

Het profiel van de softwaretester

21

Thema-avond 11 april - Usability testen

22

Bruggen bouwen met visual studio (2)

23

The grand question debated: KZA

28

Nieuwe helden: the final

31

Evenementen en thema-avonden

32

len van ervaring. Dat is precies waar mijn echte en mijn papieren (tegenwoordig pdf) wereld elkaar raken. Delen van kennis, uitwisselen van ervaring, dat is de bestaansgrond van TNN. Door TNN gaat ons testvak leven, wordt het méér dan een bundel methoden en technieken. Ik constateer tevreden dat dit ook bij dit nummer is gelukt, met dank aan alle TestNetters die spontaan een bijdrage instuurden. Veel leesplezier!

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]

Het is komkommertijd en, flauw gezegd, dit jaar heeft dat wel een heel formeel tintje gekregen. Bij TestNet is het daarentegen verre van komkommertijd. We kunnen terugkijken op wederom een mooi voorjaarsevenement. Met het thema „nieuwe helden‟ heeft een aantal van onze leden een voetstuk beklommen en zijn anderen er misschien die dag vanaf gevallen. Zij hebben kunnen ervaren hoe het is om voor een altijd kritisch publiek hun eigen verhaal te vertellen. Het algemene geluid dat we trouwens hebben gehoord, is dat dit enorm is gewaardeerd door de bezoekers. Vooruitkijkend staan onze leden nog meer mooie dingen te verwachten en dat begint al met de TestNet Summerschool. Die wordt georganiseerd in de zomerperiode, op woensdag 13 juli 2011, wanneer wij testers het vaak wat minder druk hebben. Op deze dag organiseert TestNet in samenwerking met onze sponsors de gehele dag workshops voor de leden. Elke workshop duurt drie uur en biedt iedereen de gelegenheid om zijn of haar kennis en ervaring uit te breiden. Daarnaast zullen alle TestNetters in aanloop naar het najaarsevenement twee edities thuisgestuurd krijgen van het vakblad Release. Dat is het resultaat van een nieuw initiatief. Release gaat de komende edities zeer veel redactionele ruimte reserveren voor testen. De invulling van deze artikelen gaat in nauwe samenwerking met de redactie van TestNetNieuws. Houd je ouderwetse brievenbus dus in de goed in de gaten! Ik wens iedereen weer veel plezier met deze nieuwe TNN. Tot ziens op één van de thema-avonden of evenementen.

GLOSSY TESTSPECIAL Door Kees Blokland • [email protected]

Bijzonder dit jaar is dat het tijdschrift Release een speciale editie uitbrengt die geheel in het teken staat van testen en ons najaarsevenement. Alle TestNet-leden krijgen in juni en eind september een gratis exemplaar van Release thuisgestuurd. De inzenders voor het najaarsevenement krijgen de unieke kans om niet alleen op de bühne van het najaarsevenement te staan, maar tevens een artikel over hun onderwerp te publiceren in Release. Op het moment dat deze TNN15-2 uitkomt, is de sluitingsdatum voor de inzendingen voorbij. De redactie van TestNetNieuws bepaalt onafhankelijk van de selectiecommissie wie van de inzenders voor het najaarsevenement zullen worden gevraagd te publiceren in deze bijzondere versie van TestNetNieuws. De eerstvolgende ‟gewone‟ versie van TestNetNieuws komt rond kerst uit.

Meer informatie over Release vind je op www.release.nl.

Pagina 3

RIKS COLUMN Door Rik Marselis • [email protected]

Een system-of-systems of een procesketen? Op de Dutch Testing Conference 2011 lanceerde het auteursteam van Capgemini de vernieuwde versie van het ketentestboek „The Complexity of Chain Testing‟. Belangrijk element in hun definitie is „a chain test is about processes and systems‟. Dit is een punt waar naar mijn ervaring veel mensen mee worstelen. De ISTQB Advanced syllabus heeft het over „Systems of Systems‟ en benadert dit naar mijn smaak puur vanuit de systeeminvalshoek. Het testen van bedrijfsprocessen wordt niet genoemd. Het boek „Testen van ketens met TMap Next‟ richt zich vooral op het testen van een keten van systemen die gezamenlijk het bedrijfsproces ondersteunen. Dit gaat dus meer naar procesgericht denken. Als ik aan de „stakeholder‟ vraag wanneer zij/hij tevreden is, dan blijkt steevast dat zij/hij wil dat het bedrijfsproces werkt. Of de onderliggende systemen al of niet goed werken, is niet relevant. Ik illustreer dit graag met een voorbeeld. Stel dat het bedrijfsproces voor het kopen van een OV-saldo op je OV-chipkaart bestaat uit de automaat op het station, de verbinding met jouw bank en de verbinding met het OV-backoffice systeem. Als we een performancetest van elk van deze individuele systemen doen en de performance is bij allemaal minder dan twee seconden, dan is de totale verwerking sneller dan zes seconden. Of niet? Vaak gaat het mis, omdat in de testinsteek niet naar het bedrijfsproces als geheel wordt gekeken. Een aspect daarbij zijn de „operational profiles‟, ofwel het typische gedrag van de gebruikers van het proces. Ik kom nogal eens op een groot station met treinen en metro‟s. Als ik tijdens de middagpauze een rondje wandel, dan staat er bij minder dan de helft van de automaten een persoon om zijn OV-chipkaart op te laden en wordt vast een snelle performance gehaald. Maar als ik zelf mijn kaart wil opladen, doe ik dat altijd ‟s morgens, gelijk na aankomst op het station, zodat ik ‟s middags snel naar het perron kan hollen als mijn metro er aan komt. Maar dan sta ik dus altijd achter vijf andere mensen en is het bij de andere automaten net zo druk. Kortom, een gemiddelde performance helpt niet, want om tevreden klanten te krijgen moet het bedrijfsproces de drukte in de spits aan kunnen. En dat soort zaken wordt bij een systeemgerichte benadering vaak vergeten, terwijl je het bij de procesgerichte benadering als vanzelf bedenkt. Oh ja, ik heb de auteurs gevraagd of zij „chain testing‟ niet een beetje kromme vertaling van het Nederlandse „ketentesten‟ vinden. De Engelstalige testwereld praat namelijk over „end-to-end testing‟. Zij vertelden mij echter juist bewust deze vertaling te hebben gekozen om aan te sluiten bij zaken als „supply chain management‟. Ach, what‟s in a name, zolang we er maar hetzelfde mee bedoelen. Ik roep iedereen op om bij ketentesten eerst even goed na te denken wat je nu precies wilt bereiken en dan bewust te kiezen voor een systeeminsteek, een procesinsteek, of beide.

Pagina 4

VIJF VRAGEN AAN … Gabriël Felten • [email protected]

@GabrielFelten

Ik vind testen een leuk vak, want … Ik ben ooit begonnen als systeemanalist bij een grote luchtvaartmaatschappij. Ik werkte met een passagiersincheck- en bagagesysteem dat was aangesloten op de systemen van diverse andere luchtvaartmaatschappijen. In die tijd testte ik het gerealiseerde zelf, zonder testvoorbereiding en met de focus op het eigen functionele ontwerp. Niet verwonderlijk dat in productie regelmatig fouten optraden met betrekking tot ketenintegratie en regressie. Toch vond ik testen toen al een van de leukste aspecten van het vak en ik zag het als een uitdaging om manieren te vinden hoe de grootste risico‟s zo vroeg mogelijk af te dekken. Begin 2000 rolde ik het testvak in als „testprofessional‟ en ik ben me er vanaf die tijd in blijven ontwikkelen. Het mooie van testen nu vind ik de diversiteit van het vak. Het is niet alleen het kennen van een of meer methoden en technieken. Het is ook het effectief toepassen ervan in de context van het project. Ook leer ik als tester continu bij om aangesloten te blijven met de nieuwste ontwikkelmethodieken en technologieën.

Het grootste misverstand over testen is … dat een methode waarvoor een organisatie als standaard heeft gekozen, de passende aanpak is voor alle projectsituaties. Het komt regelmatig voor dat testers een bepaalde methode of werkwijze aangeleerd hebben en dat ze daarmee bij eerdere projecten goede ervaringen hebben opgedaan, dat het hun stokpaardje is geworden en dat ze vervolgens deze star proberen toe te passen in alle projectsituaties, ook waar deze werkwijze zeer inefficiënt blijkt te zijn.

Over vijf jaar zie ik mijzelf in de functie van … testprofessional. Ik heb me in projecten met veel plezier beziggehouden met taken als het opzetten van testprocessen, het bedenken van teststrategieën, het opleiden van testers, het coördineren van testen en de testuitvoering zelf. Deze diversiteit aan taken spreekt mij naar verwachting over vijf jaar nog steeds aan. Welk label er aan gehangen wordt (testmanager, testcoördinator, testadviseur of testanalist) maakt me niet uit. „Testprofessional‟ dus.

Een tester moet zeker beschikken over de vaardigheid en kennis om … zich te kunnen aanpassen aan de context van het project. Naast het beschikken over gedegen analytische vaardigheden, springt dat er voor mij uit. Ik vind het belangrijk dat een tester praktische kennis heeft van verschillende methoden, technieken en technologieën en dat hij/zij daarbij het vermogen heeft om daaruit te kiezen om tot de beste werkwijze te komen voor een specifieke projectsituatie. Daarbij is het belangrijk dat hij/zij over voldoende communicatieve vaardigheden en overtuigingskracht beschikt om dit ook op de andere projectleden over te brengen.

Pagina 5

In de toekomst hoop ik dat binnen het testvakgebied … is veranderd, omdat … Het testvak is inmiddels flink volwassen geworden en toch zijn er natuurlijk nog genoeg dingen voor verbetering vatbaar. Dit is mijn top drie: Ik hoop dat het testen een volwaardig onderdeel gaat worden van het ontwikkelproces. Dat testers standaard vroeg in het project betrokken worden, al vanaf de totstandkoming van de requirements. Nog steeds wordt in veel organisaties het testen als een „ik-doe-het-er-wel-even-bij‟-activiteit gezien. En als professionele testers worden ingezet, worden deze nog vaak te laat ingezet, op het moment dat de software opgeleverd wordt, want dan is er volgens de perceptie van velen pas „iets‟ te testen. Verder hoop ik dat de testers zelf meer in staat zijn de geijkte werkwijze of methode los te laten en een werkwijze toe te passen in de context van het project. Bijvoorbeeld niet standaard wachten totdat er een testbasis (waaronder requirements) aanwezig is, voordat testactiviteiten gestart worden. Ik hoop dat er meer en meer integrale ontwikkel- en testsuites komen waarin het mogelijk is regelrecht vanuit gewijzigde requirements de aan te passen stukken code en vervolgens de daarmee geraakte testgevallen te traceren. Hierdoor worden de risico's steeds beter beheersbaar en kan het ontwikkel- en testproces steeds efficiënter verlopen.

Ik geef de vraag door aan Rene Lak, omdat … ik altijd prettig met hem samengewerkt heb in diverse projecten, cursussen en leergangen. Hij heeft me in die samenwerking geïnspireerd door zijn doortastendheid en verfrissende kijk op het testvak. Nu ben ik erg benieuwd hoe hij die kijk op het testvak verwoord in de volgende „vijf vragen aan …‟

EVEN VOORSTELLEN Door: Kees Blokland • [email protected]

Sinds begin dit jaar ben ik actief in de redactie van TestNetNieuws. Daarnaast ben ik tijdens de ALV van TestNet verkozen tot lid van het bestuur van TestNet. Op beide plaatsen vulde ik vacatures in die waren ontstaan na het terugtreden van Meile Posthuma. Een goede aanleiding om mezelf even voor te stellen. Voordat ik in 2003 bij Pol-teq kwam werken hield ik me bezig met het ontwikkelen van hardware en het testen van telecomsystemen bij Lucent Technologies. Bij Polteq vervul ik diverse rollen. Ik combineer de verantwoordelijkheid voor de afdeling R&D met werk voor klanten. Daarnaast werk ik geregeld als docent voor testtrainingen. Mijn betrokkenheid bij TestNet bestond tot nu toe uit het bezoeken van de evenementen, waar ik af en toe op het podium mocht staan. Ik vind het leuk om een bijdrage te leveren aan het goed functioneren van deze unieke, levendige vereniging van testers!

Pagina 6

BEVINDINGEN TELLEN Door Bert Wijgers • [email protected]

Aantallen bevindingen worden vaak beschouwd als metingen van productkwaliteit. Echter, de meest belangrijke telling in dat opzicht is per definitie onbekend, namelijk het aantal onontdekte fouten. Aantallen bevindingen kun-nen, op hun best, gebruikt worden als indicatoren van de kwaliteit van het softwareontwikkelproces. Een bevindingentelling is een getal. Om te worden opgenomen in een telling moet een bevinding worden geregi-streerd en geclassificeerd. Maar wat meten we eigenlijk met een bevindingentelling? De ontwikkeling van software is een sociale activiteit en dat betekent dat veel variabelen invloed hebben op bevindingentellingen.

Focus Laten we het voorbeeld nemen van het aantal geconstateerde bevindingen per week. Hierin is een trend zichtbaar. In de eerste weken van een softwareontwikkelproject worden maar enkele bevindingen gedaan. Vaak komt dit omdat de testomgeving nog niet up and running is en het testteam zich nog voorbereidt. Vervolgens komt het testteam op gang en worden er iedere week veel bevindingen gedaan. Na een tijdje neemt het aantal nieuwe bevindingen per week af. Vaak wordt dit laatste opgevat als bewijs dat er nog maar weinig fouten in de software verborgen zitten en dat het product dus klaar is voor release. Dit is niet valide. Net zoals er andere oorzaken waren voor de lage aantallen bevindingen in de eerste weken, zo zijn er ook andere oorzaken voor het feit dat de tellingen dalen in de laatste weken. Vlak voor een deadline verschuift de focus van het testteam van het zoeken naar fouten in de richting van andere taken. De testers moeten hun rapporten schrijven en hun testscripts archiveren. Ze helpen ontwikkelaars om oude bevindingen op te lossen. In feite moeten ze hun focus verschuiven, omdat verwacht wordt dat bevindingentellingen dalen wanneer de deadline nadert. Het zoeken naar fouten wordt ontmoedigd in deze fase van het softwareontwikkelproces. Het aantal bevindingen per week wordt op zijn minst sterk beïnvloed door de focus van het testteam.

Productkwaliteit Het tellen van bevindingen is niet hetzelfde als het meten van productkwaliteit. Er zijn veel definities van kwaliteit, maar om Cem Kaner (2000) aan te halen: ‟De essentie van ”kwaliteit” is ”kwalitatief”.‟ Kwaliteit kan nooit worden gevangen in objectieve en kwantitatieve metingen. Kwaliteit gaat over de tevredenheid van de gebruiker. Dit is iets anders dan de afwezigheid van fouten. Zelfs als we kwaliteit van software definiëren als de afwezigheid van bevindingen na release, dan kunnen het aantal en de aard van de bevindingen die optreden tijdens de productiefase alleen indicatief zijn. De fouten die nog steeds verborgen zitten in de software kunnen na release wel of niet aan het licht komen. Op het moment van release is hun aantal onbekend en dat zal altijd zo blijven. Het enige dat bevindingentellingen direct meten is de hoeveelheid van bevindingen in de bevindingentool. Als de gebruiker in aanmerking wordt genomen, is de meting van kwaliteit altijd subjectief van aard. Daarom is het niet raadzaam om acceptatiecriteria te formuleren in termen van aantallen bevindingen. Uiteraard kan een stuk software kan niet live gaan met een of meer showstoppers. Maar het aantal toegestane, minder ernstige bevindingen kan vooraf niet worden bepaald, aangezien er geen manier is om te voorspellen hoe de onopgeloste bevindingen het systeemgedrag zullen beïnvloeden in interactie met de uiteindelijke gebruikers.

Pagina 7

Causale verbanden Aantallen bevindingen zeggen dus niet veel over productkwaliteit, maar kunnen wel gebruikt worden als indicatoren van proceskwaliteit. Hierbij moeten we voorzichtig zijn met het leggen van causale verbanden. Een lage bevindingentelling bijvoorbeeld kan veroorzaakt worden door goed programmeerwerk of door slecht testwerk. Waarschijnlijk spelen beide factoren in meer of mindere mate een rol, naast eventueel nog andere factoren zoals de mate van detaillering van de requirements, problemen met de testomgeving of tijdsdruk. Door al deze factoren tijdens de planning en het beheer van het softwareontwikkelproces mee te laten wegen kunnen we onszelf en het management behoeden voor incorrecte en te simplistische gevolgtrekkingen. Referentie: Kaner, C., 2000. Rethinking software metrics. Software Testing & Quality Engineering, Volume 2, Issue 2.

EXPERTS GEZOCHT! Door BNTQB • [email protected]

Zoals velen van jullie inmiddels zullen weten, wordt er door werkgroepen van ISTQB en de diverse landen-boards, waaronder BNTQB, gewerkt aan het Expert level. Voor de module „Improving the test process‟ is de syllabus nu beschikbaar, aan de modules „Test Management‟ en „Test Automation‟ wordt op dit moment gewerkt. Voor BNTQB betekent dit dat er regelmatig verzoeken voor reviews binnenkomen en dat zal snel meer worden. Voor Foundation en Advanced level is de Syllabus Werkgroep binnen BNTQB hier verantwoordelijk voor. Voor het Expert level - de naam zegt het eigenlijk al - gaat een vergaande specialisatie plaatsvinden. En dat geldt uiteraard ook, of zelfs nog meer, voor het reviewwerk. Tot en met Advanced level kan dat nog prima met allround ervaren en deskundige testers, voor Expert level zoeken we juist gespecialiseerde deskundigen. Ben je gespecialiseerd in één van de drie bovengenoemde expertgebieden - op termijn volgen nog meer nieuwe modules - én ben je ISTQB Advanced gecertificeerd of van plan dat binnenkort te worden, dan is dit je kans om betrokken te raken bij de ontwikkeling van het Expert level en vanuit jouw expertise bij te dragen aan de inhoud van dit programma. Stuur snel een mailtje naar [email protected] om ons te laten weten dat je mee wilt doen. Alvast bedankt voor je reactie!

Pagina 8

BOEKRECENSIE: GRIP OP IT Door Hans van Loenhoud • [email protected]

@HansvanLoenhoud

Uitgeverij: Academic Service ISBN: 978 90 125 8259 9 Auteur(s): Derk-Jan de Grood „De held die voor mijn nachtrust zorgt‟ is de pakkende ondertitel van een handzaam boekje van Derk-Jan de Grood, die daarin zijn licht laat schijnen op „Grip op IT‟. Dit is een fenomeen waar onze maatschappij al jarenlang en in toenemende mate mee worstelt. Derk-Jan constateert dat IT-projecten, ondanks alle vakinhoudelijke handvaten die onze boekenkasten vullen, nog altijd bij velen voor slapeloze nachten zorgen. Daarom nu eens geen naslagwerk met methoden, technieken en best practices, die de vakinhoudelijke weg door het IT-bos wijzen; hij gooit het over een compleet andere boeg, die van de psychologie. Want het zijn niet de systemen of projecten die wakker liggen, maar de mensen die eraan of ermee werken. Die mensen hebben persoonlijke drijfveren: ze zijn naarstig op zoek naar succes en tegelijkertijd bang om te falen. Tussen de euforie van het ultieme succes en de paniek van een volledige afgang ligt een zone waarin wij allen graag vertoeven: onze comfortzone. Wij ervaren comfort in een combinatie van uitdaging en grip op de situatie. Derk-Jan werkt vier randvoorwaarden uit om grip te hebben: overzicht, inzicht, invloed en draagvlak. Als deze in een project onvoldoende zijn ingevuld, dan slaat comfort om in angst, en angst, zo zegt hij, is een van de hoofdredenen waarom projecten mislukken. Om een project te laten slagen, moet je er dus voor zorgen dat jij, en zeker ook je manager of opdrachtgever, in hun comfort-zone blijven. Het boek presenteert een vijfstappenplan om dat te bereiken: (1) inventarisatie van doelen, (2) inventarisatie van de persoonlijke behoefte, (3) vaststellen hoe dit comfort bereikt kan worden, (4) invullen van de maatregel en (5) uitvoeren van de geplande maatregel. Derk-Jan merkt daarbij fijntjes (en terecht) op dat testen bij uitstek een comfort biedende activiteit is. De gepresenteerde vijf stappen zijn dan ook regelmatig voorzien van praktijkvoorbeelden uit de testwereld. Het is een dun boekje dat niet de pretentie heeft om een naslagwerk voor een nieuwe projectaanpak te worden. De waarde van dit boek ligt in de visie, in de aansporing om afstand te nemen en projecten eens door een heel andere bril te bekijken. Om te kijken naar de mensen achter het project, elk met hun eigen motieven, persoonlijkheden en angsten. Als je dit boekje hebt gelezen, besef je dat er meer nodig is dan vakinhoudelijkheid om een project te laten slagen. De beperkte omvang en de verhalende schrijfstijl van het boek nodigen uit om het in één keer uit te lezen. Dat heb ik althans gedaan en toen was het ineens best wel laat. Dus, dat van die nachtrust, dat klopt niet helemaal …

Pagina 9

DE DAG VAN … Door Jolanda Habben Jansen • [email protected] Het is maandagmorgen, half zeven als de wekker gaat. Opstaan, douchen, aankleden, opmaken, zo: klaar om de dag te beginnen. Het is vijf voor zeven; over vijf minuten gaat de wekker voor mijn man. Ik begin voor mezelf ontbijt te maken en een kopje espresso. Omdat ik vrijdag aan een nieuwe opdracht begonnen ben, kan ik niet te vroeg op het project verschijnen. Dus eerst maar even tijd nemen door op Syfy naar Startrek te kijken. Mijn man is opgestaan en wordt pissig omdat hij vindt dat ik te veel tv kijk. Tja, een beetje gelijk heeft hij wel, maar morgen kan ik gewoon om half acht beginnen en zal ik, in plaats van naar Startrek te kijken, mijn fiets bestijgen.

Dedicated persoon Om tien over half acht op de fiets naar Atos Origin. Ik probeer vele kilo‟s kwijt te raken, dus als ik kan fietsen, doe ik dat. Het project waar ik op ingezet ben, is een project voor de WestlandUtrecht bank. Die bank moet ontvlochten worden uit de infrastructuur van de ING. Atos heeft een aanbod gedaan voor deze infrastructuur, inclusief services en processen, backend (file servers, enzovoort) en frontend op een standaard Atos Werkplek. Dat alles moet natuurlijk worden getest en geaccepteerd. Het projectteam schat in dat het wel handig is om een dedicated persoon aan te wijzen om alles rond acceptatie te regelen. Deze persoon krijgt daarvoor zes weken de tijd. En die persoon, dat ben ik geworden. Een leuk maar wel een heel technische project, met heel veel techneuten, die toch anders zijn dan de functionele mensen, waar ik normaal mee werk. Maar erg kort tijd. Om kwart over acht kom ik aan bij Atos. Eerst laptop ophalen in gebouw D waar ik een locker heb, dan naar gebouw C lopen, waar op de eerste verdieping een projectkamer is voor het project van de bank. Ik heb vandaag maar één echte afspraak en dat is met de architect. Ik hoop van hem iets te horen over acceptatiecriteria die zijn vastgelegd. Er zitten al drie mensen te praten in de kamer: Jaap de projectleider, Cor de projectleider processen en Alister van de processen-track met als aandachtsgebied security. Later komt daar Arthur bij. Hij is van de WestlandUtrecht bank en ook specifiek voor security. Hij komt de richtlijnen bekijken hoe Atos security regelt.

Acceptatiecriteria Arthur en ik raken in gesprek en ik benadruk dat richtlijnen goed zijn, maar hoe vindt straks de acceptatie plaats? Ja, zegt Arthur, de acceptatiecriteria moeten we nog vaststellen. Hiervoor heeft Arthur deze week bij de bank contact met twee collega‟s om dit ook nog deze week op te leveren. Ik bedenk dat dit wel onderdeel zou moeten zijn van mijn plan. Alles lijkt kort dag en dat binnen mijn zes weken! Hoe ga ik dat doen? Het is vandaag een komen en gaan van mensen, die de kamer opkomen en direct weer weggaan omdat de kamer vol lijkt. Cor stelt mij nog voor aan Ronald. Dat is het hoofd van CDC ING, de belangrijkste acceptant van het project en verantwoordelijk voor het beheer. Hij wordt dus een belangrijk persoon voor mij binnen het project. Ik breng de dag door met lezen: het projectplan, de TOP-lijst (requirements van de beheerafdeling) en ander leesvoer dat ik op livelink vind. Tevens eet ik mijn meegenomen boterhammen.

Pagina 10

Requirements Om twee uur heb ik een afspraak met Dick, de architect van het project. We gaan even apart zitten om met elkaar te praten. Zijn standplaats is Eindhoven en hij wil tijdig in de auto zitten om weer terug te rijden. Hij vertelt over het project, over waarop testen gebaseerd zouden moeten zijn, over zijn requirements zoals hij ze van de klant heeft gekregen en hoe requirements omgezet worden in een High Level Design en Detail Designs. Afspraken met de klant zijn nog niet helemaal af, want nergens is beschreven hoe de klant zal gaan accepteren. Accepteren ze door zelf te testen of accepteren ze door controle op test reports van ons? Maar … wij gaan de detail designs testen. Hoe controleren we dan dat de requirements één op één overgenomen zijn in de detail designs? De klant gaat dat niet doen. Zij krijgen de detail designs ter kennisgeving. En wat te doen met afwijkingen, doordat we zowel de requirements van de klant hebben als de requirements van beheer? Daar kan verschil in zitten. Wat moet ik dan managen? Hoe krijg ik de klant zo ver dat er acceptatie gaat plaatsvinden?

Testplan Afijn, dit gesprek heeft bijgedragen aan mijn begrip voor het project. En het zet mij tot denken aan: Hoe neem ik dit allemaal op in het testplan? Pfff, niet gemakkelijk, maar kom, dat is best te doen! Het is mijn tweede dag. Testplan klaar aan het einde van de week lijkt mij niet haalbaar, maar laten we doen wat we kunnen doen. Uitwerken kan altijd in een latere fase plaatsvinden, dan schrijven we nu de aannames op. Als ik terugkom in de projectkamer is de projectleider met de deelprojectleiders aan het praten over het kloppend krijgen van de projectrapportage. Wat ben ik blij dat ik geen projectleider ben, maar slechts testmanager! Want dit gaat niet over de inhoud, maar meer over „hoeveel uren gaan mensen in juni boeken, klopt dat met het budget‟, enzovoorts, enzovoorts. Terwijl ik geïnteresseerd ben in „halen we de projectdoelen, gaan we aan de requirements voldoen, is de klant straks tevreden?‟ Ik hoop dat de projectleiders dat ook belangrijk vinden…

Al die gezichten Ik werk mijn testplan bij naar aanleiding van mijn gesprek met Dick. Raak aan de klets met projectleider Ton over alles behalve het werk. Al met al een vruchtbare dag, maar ik ben er nog niet uit hóe ik het plan moet aanpakken. En wát een namen, altijd lastig van een nieuw project: dat je al die gezichten met hun namen en hun functies moet onthouden.

Nederlander Om half zes pak ik mijn spullen in en fiets terug naar huis in Houten. Onderweg fiets ik langs de McDonald‟s, want ik zorg vandaag voor mijn eigen eten en ik koop een salade om thuis als avondmaaltijd te nuttigen. Thuisgekomen (kwart over zes) pak ik mijn tas uit en nestel me op de bank. Krant erbij en de stapel reclamefolders. Ik ben en blijf een Nederlander - altijd op zoek naar koopjes. Mijn man is inmiddels ook thuisgekomen. Hij neemt de soep van zaterdag als maaltijd. Na het eten begint mijn man te knutselen aan het zonnescherm, waarop ik besluit toch maar eens het dak van het terras schoon te maken. Na de klusjes gaat mijn man naar de buurvrouw, die naast buurvrouw ook zijn accountant is en ik doe de tv aan voor Bones. Daarna kranten opruimen en naar bed. Morgen kan ik wel vroeg beginnen en dat ga ik ook doen. In bed denk ik aan alle namen die ik nog moet onthouden. Gelukkig val ik snel in slaap!

Pagina 11

DUTCH TESTING CONFERENCE Door: Kees Blokland • [email protected]

Op 13 april j.l. werd in ‟t Spant in Bussum de Dutch Testing Conference gehouden. Hieronder een impressie van dit evenement. Rik Marselis maakte de foto‟s.

Warming up (centraal) Diederick Dekker opende de tweede editie van dit evenement met een heuse warming up! Never be afraid to try something new… Als voorzitter van de Expert Groep nam Anko Tijman het vervolgens over en startte de eerste sessie van de Lightning Talks door de groep van „perceived‟ experts, waarbij Bart Knaak het spits afbeet: „het vak van softwaretester wordt een vergeten beroep: een brug test je toch ook niet door er honderd auto's overheen te laten rijden?‟. Bob van den Burgt pleit voor „lean thinking‟, gericht op het voorkomen van afvalproductie in het testproces. Derk-Jan de Grood legde ons uit hoe je gemakkelijker doelen kunt halen met „comfort creating methods‟ Daar heeft hij ook een boekje over geschreven die tijdens de DTC werd gelanceerd, zie de boekbespreking elders in deze TNN. Vervolgens verfriste Anko onze kennis van de Agile Manifesto en drukte ons het volgende op het hart: „Agile is about values, not about process‟. Met „Nothing is more practical than a good theory‟ sloot Jurrian van der Laar af. Hij doelde hiermee op TMMi, dat geen „old school‟ is en ook past in Agile omgevingen.

Voorspelbare resultaten in onvoorspelbare tijden door Hans Somers en Jos van Rooyen (track) Hans vertelde over de invoering van een groot nieuw systeem voor de verwerking van Toeslagen bij de Belasting-dienst. Bij een veeleisend project zoals dit moet je het proces centraal stellen en niet de IT. Zeker in een omgeving met reorganisaties en nieuwe IT-leveranciers, enzovoort. Wat ook meespeelt, is de veranderende maatschappij, waarbij de burger hogere eisen stelt (zoals 24x7 beschikbaarheid). In een tweede deel van de presentatie ging Jos in op een aantal activiteiten van de business om de risico's bij de ingebruikname van het nieuwe systeem te be-heersen. Een greep uit die verzameling activiteiten: processimulaties, testmonitoring, workshops en meetesten. In de vragenronde ontstond een discussie over de rol van testmonitor versus de verantwoordelijkheid van de testmanager.

Ewald Rodenrijs - a cloud in testen (vendor track) Van de capaciteit van een typisch datacenter wordt 85 procent niet gebruikt. Een meer optimaal gebruik van infrastructuur is momenteel de belangrijkste reden waarom bedrijven „naar de Cloud‟ gaan. De focus van Cloud Computing zal in de toekomst gaan verschuiven van IT naar BT (business technology). Van capacity naar capability. Een voorbeeld van de mogelijkheden van Cloud Computing: een volledige database up & running in negen minuten! Er zijn ook aandachtspunten, zoals de wettelijke regels met betrekking tot dataopslag en de alomtegenwoordige zorgen over de veiligheid van gegevensverkeer. Binnenkort komt er een e-book uit van Sogeti met de Cloud als onderwerp.

Pagina 12

Na de lunch de tweede tranche lightning talks Ruud Teunissen zette met een strak getimede presentatie de Cloud neer met één belangrijk bericht: de Cloud is er, we horen over testen in de Cloud, maar wie heeft het over het testen ván de Cloud? Maurice Siteur steekt de testwereld een hart onder de riem met de observatie dat ondanks jaren van noeste arbeid testautomatisering vaak nog steeds aan de horizon gloort. Michiel Vroon heeft drie boodschappen. Ten eerste: stel een Holodeck manager aan voor je testomgeving. Ten tweede: de Startrek generatie van beheerders gaan eerdaags met pensioen, dus wie neemt hun positie en kennis over? En ten slotte: geniet van het leven! Rik Marselis illustreerde op heldere wijze de noodzaak tot ketentesten („O, u heeft zeker een Mac!‟) en (ook weer) de verschuiving van IT naar BT. Tim Koomen vroeg aandacht voor een interessant gevolg van de volwassenwording van de testwereld: de diversificatie van testrollen, zoals tester van non-functionals. En Agile: waar is de rol van de testmanager?

Gert Hoving - hoe kunnen we helpen? (track) Gert legde uit hoe het testmanagementproces bij DUO (Dienst Uitvoering Onderwijs) is ingevoerd. Met de invoering van RBT (Risk Based Testing) en MTP (Master Test Plan) als verplichte kost zou de kans moeten worden vergroot dat de juiste dingen worden getest en ook dat de dingen juist worden getest. Door onvoldoende draagvlak was de invoering niet succesvol. Invoering kost tijd en een MTP was ook niet altíjd nodig. Met het geleerde in gedachten werd de invoering van testmanagement opnieuw in gang gezet. Belangrijk gegeven daarbij is het risicoprofiel van het project. Het team is 50 procent beter als je sterspeler is opgesteld. Met andere woorden, je pakt volledig uit met testmanagement voor de risicovolle projecten! Andere leerpunten: elk project is uniek, dus maatwerk, schep helderheid, bewaak de teststrategie, werk aan je draagvlak. Leuk voor Gert: hij won de derde prijs in de Best Paper Award verkiezing! De andere prijzen gingen naar Iris Pinkster (2e) en Asmir Babaka, die de eerste prijs won.

Hans van Loenhoud - hoe vertel ik het mijn baas? De kunst van testrapportage (track) Beelden van partijen komen nooit overeen, zoals die van opdrachtgever en leverancier. We praten vaak over acceptatiecriteria, maar denken vaak in afwijzingscriteria. Met andere woorden, wanneer kan ik weigeren? Dit wordt versterkt door een negatieve manier van rapporteren wat een demotiverend effect heeft: „Er zitten nog fouten in, dus ik zou niet live gaan.‟ Business risk wordt vaak niet in de rapportage verwerkt. Hans presenteerde een flinke lijst van aanbevelingen. Rapporteer wekelijks en niet alleen aan het eind: dan zie je het aankomen en zijn er geen plotselinge verrassingen. Neem gerust ook subjectieve rapportage op. Verdiep je in de persoon aan wie je rapporteert en denk aan PR naar de gebruikerscommunity. Realiseer je dat acceptatiecriteria alléén schijnzekerheid bieden. En: bevindingen zijn vooral interessant voor de ontwikkelaars die ze moeten oplossen...

Afsluitende keynote: Marlene Krenn - The mental laws of allembracing winners Marlene, die bekend is als Official Motivation Coach of the Spanish National Football Team, vertelde hoe inzicht in bepaalde mentale processen nodig is voor mental training. Een aantal opmerkelijke

Pagina 13

punten: ruzie met je ouders betekent ruzie met jezelf, het onderbewustzijn maakt geen onderscheid tussen jou en mij, waardoor een compli-ment aan een ander ook goed voelt voor eigen onderbewustzijn en jaloezie werkt negatief op het zelfbewustzijn. Jaloezie is overigens een normale reactie op iets goeds van iemand anders… Bij mental training moet je het onder-bewustzijn programmeren, bijvoorbeeld met een goed voornemen op een postit met je favoriete kleur: „ik ben geduldig en voel me goed‟. Vervolgens zorg je dat je de post-it 21 dagen steeds tegenkomt. Programmeren van negatieve zaken werkt ook zo, dus haar advies: kijk niet naar het (slechte) nieuws voor het slapen gaan, want dat programmeert je gedachten voor de hele nacht... De conferentie werd afgesloten met de uitreiking van allerlei prijzen van leveranciers, variërend van chocolade paashazen tot en met een iPad bestuurbaar vliegtuig.

EUROSTAR IN MANCHESTER Door Derk-Jan de Grood • [email protected]

Sinds 1993 is de EuroSTAR conferentie de meest succesvolle en erkende verzamelplaats voor softwaretestprofes-sionals. Afgelopen jaar vond de conferentie plaats in Kopenhagen. Met meer dan 850 aanwezigen van verschillen-de nationaliteiten was Kopenhagen een week lang het internationale middelpunt van ons vakgebied. Dit jaar organiseert Qualtech de 19de editie van EuroSTAR in Manchester. Derk-Jan de Grood, testexpert bij Valori, is een van de vier leden van de programmacommissie en vertelt ons wat er achter de schermen van de conferentie gebeurt. De conferentie wordt elk jaar georganiseerd door Qualtech, gevestigd in Galway, Ierland. Ondanks dat Qualtech de organisatie op zich neemt, besteedt ze het maken van het inhoudelijke programma uit aan experts binnen het vakgebied. Daarom wordt er elk jaar een voorzitter gevraagd, die vervolgens zelf zijn commissie samenstelt. Dit zijn in de regel mensen die een aantal conferenties hebben bijgewoond, thuis zijn in de testwereld en goed kunnen inschatten wat presentaties interessant maakt.

‟Psst, Kun je een geheim bewaren?‟ Mijn deelname aan de programmacommissie is op invitatie van Geoff Thompson, de voorzitter van dit jaar. Tijdens de Expo:QA in Madrid stond hij ineens naast me. ‟Psst, Kun je een geheim bewaren?‟, vroeg hij, ‟ik ben gevraagd als program chair, maar dat mag nog niemand weten‟. De reden voor deze openbaring was dat hij mij graag in zijn team wilde hebben. Geoff en ik kennen elkaar van verschillende conferenties en de UK testing retreat waar we beiden lid van zijn. Samen met Morton Hogard en Graham Thomas hebben we het programma voor dit jaar gemaakt. De aanpak hiervoor was als volgt. Allereerst hebben we het thema bepaald. Geoff had al een idee, maar je weet hoe dat gaat met testers, we discussiëren graag. Nadat de deelonderwerpen waren vastgesteld en de call for papers De leden van de programmacommissie rusten even uit (v.l.n.r. Derk-Jan, Geoff, Morton, Graham)

Pagina 14

was geformuleerd, is deze uitgezet. We kregen meer dan 340 proposals! Een nieuw record. Zoals elk jaar leunt de programmacommissie sterk op de vrijwilligers van het reviewteam, een groep van 48 reviewers dat de zware taak had om een goede voorselectie te maken. Elke proposal werd door minimaal twee reviewers beoordeeld. Om te zorgen dat dit objectief gebeurde, werden alle gegevens die de inzender identificeren verwijderd. Ik meen mij te herinneren dat Bob van de Burgt dit heeft geïntroduceerd in het jaar dat hij program chair was. Sindsdien is dit vaste prik. Het zorgt ervoor dat je de proposals echt beoordeelt op in inhoud. Op basis van de punten die de reviewers gaven, werd een voorselectie gemaakt als input voor de Galway meeting.

Galway meeting In april ontmoetten de leden van de voltallige programmacommissie elkaar in Galway om het programma vast te stellen. De voorbereiding voor deze meeting was intensief. We dienden alle proposals uit de voorselectie te beoordelen. Daarnaast was er dit jaar een enorme lijst van ‟specials‟, proposals voor tutorials, minitracks en funsessies. Bij elkaar moesten we ieder zo‟n 200 proposals doorwerken. In het vliegtuig zaten we alle vier nog te lezen, maar iedereen had gelukkig zijn beoordelingen af voordat de meeting begon. De ruwe opzet van het programma was hierdoor snel gemaakt. De rest van de twee dagen hebben we besteed aan het optimaliseren ervan.

Slechts 10 procent Bij een evenwichtig programma is het belangrijk dat de presentaties goed verdeeld zijn over de dagen. Welke presentaties passen in dezelfde track, zijn er sprekers van dezelfde organisatie, hebben we dynamische sprekers op de juiste tijdstippen geplaatst, enzovoort. Soms moesten we hierdoor een hele goede inzending apart leggen, omdat het niet paste of omdat er anders te veel sprekers van dezelf-de organisatie op het programma zouden staan. Dat doet pijn en leidde wel eens tot een felle discussie, maar slechts tien procent van de inzendingen kon worden gehonoreerd, dus dat hoort erbij. Het ruwe programma van EuroSTAR 2011 We hebben gezorgd voor een goede balans in het programma. Hierbij zochten we natuurlijk aansluiting bij de onderwerpen die in de call for papers waren genoemd. Omgekeerd kun je ook beredeneren dat er bepaalde onderwerpen niet kunnen ontbreken op het programma. We zijn daarom erg bij dat we dit jaar naast de traditionele onderwerpen ook presentaties hebben over mobile, cloud en social media.

De Nederlandse bijdrage We mogen als Nederlanders trots zijn op onze actieve community. Op Europees niveau zijn we goed vertegenwoordigd. Dat kun je zien aan het aantal sprekers in het programma. Maar ook als je kijkt naar het aantal leden van het reviewteam, zijn we goed aanwezig. Mooi natuurlijk, maar dit heeft wel negatieve consequenties voor de slagingskans van onze inzendingen. In het programma proberen we een eerlijke verdeling te maken. We zorgen ervoor dat het een echt internationale conferentie is en daarom proberen we te voorkomen dat één land domineert. Omdat er relatief veel inzendingen uit Nederland komen, is de selectie ook zwaarder.

Pagina 15

Hoe haal je het maximale uit de conferentie? Voor de programmacommissie lijkt er even een moment van rust te zijn, nu het programma is vastgesteld. Onze grootste taak zit er op. Toch is er nog een aantal zaken die geregeld moeten worden. Als programmacommissie proberen we het totaalpakket van de conferentie zo aantrekkelijk mogelijk te maken. Momenteel zijn we bezig met de opening en de afsluiting. Er zijn op de conferentie mini-tracks, er moeten track-chairs geregeld worden die de sprekers introduceren en begeleiden. Elk jaar zijn er veel deelnemers die voor de eerste keer komen en we willen hen graag helpen om het maximale uit de conferentie te halen. Voor veel deelnemers geldt immers dat er teamgenoten en een leidinggevende zijn, die verwachten dat hun collega‟s met goede ideeën thuiskomen. We horen vaak dat deelnemers een presentatie geven voor de thuisblijvers. We denken momenteel na over hoe we hen kunnen helpen om de goede ideeën die ze opdoen, ook succesvol in praktijk te kunnen brengen.

De EuroSTAR ervaring Naarmate de conferentie dichterbij komt, zal het waarschijnlijk drukker worden. Spannend is natuurlijk welke invulling de sprekers daadwerkelijk gaan geven aan hun inzending en wat de deelnemers uiteindelijk van de conferentie vinden. Mijn ervaring is dat je wel kunt willen plannen, maar dat deelnemers en sprekers elkaar gedurende de conferentie beïnvloeden. Hierdoor krijgen bepaalde thema‟s ineens gewicht en vallen soms belangrijke boodschappen weg tegen andere gebeurtenissen. Dat maakt een conferentie als EuroSTAR misschien wel bijzonder. Het is echt een verzamelplaats voor softwaretestprofessionals. Een goed programma is noodzaak, maar er gebeurt ook een heleboel in de periferie van de presentaties. Ik kijk er alvast naar uit. Tot in Manchester!

Pagina 16

BJ ROLLISON AT THE TESTNET SPRING EVENT Door John van Veen • [email protected]

The first key-note speaker on the TestNet Sping Event was BJ Rollison. The title „Unleash Your Potential‟ was promising. Soon it became clear that choosing BJ for the first key note was not a coincidence. He gave attention to conferences, and presenting at conferences, and made the link to testing. A perfect way to switch from work mode to conference mode.

Intermezzo I remember visiting the North Sea Jazz Festival some years ago (1994). Starting work early made it possible to work full day, drive to the festival, find a parking place and be in time for the opening acts. After arriving I went directly to one of my heroes, John Scofield, who gave a performance with Pat Metheny. Wow, what a disappointment! All that terrible noise, no structure. I stayed in the concert hall for exactly two minutes and went out for something to eat, to drink and some fresh air. After twenty minutes, I went back inside. All the noise was gone, beautiful music remained and I enjoyed a perfect concert …

BJ Rollison

Switching modes can be quite useful! The overall message in the first key note „Every person has a story‟. That is one of the reasons to organize a test conference like the TestNet event. New ideas, shared passion, unique perspectives, different experiences and last but not least the desire to help others. By telling your story you will help others, even when they disagree with your message. „Get your game on! Become the “go to” guy/gal, be a central hub for questions and help to improve others‟. I really liked BJ in his observation that humans tend to make decisions based on emotions. That might be the reason that we make the same mistakes all the time. Next, BJ gave an overview on how to have a successful test talk (can be applied to non-testing talks as well). A successful test talk could be build up in: •

What is the problem?

•

What were the potential solutions?

•

What did you do to solve the problem?

•

What can the „listener‟ do with the message sitting at his/her office the next day?

The latter bullet is in my personal opinion the most essential. Therefore, I fully agree with BJ when he states: „Do not talk for an hour on an idea that cannot be reused‟. Finally getting to testing, BJ gave his view on testing challenges in the future „System on a chip‟, „The experimental Ecosystem‟, „The cloud paradigm‟, „Test automation‟ and „Retention‟. In my view an inspiring talk and a bridge to the rest of the TestNet program. Please also note the intermezzo. The key note brought me in the conference mode!

Pagina 17

SUCCESVOLLE AANSTURING VAN OFFSHORE TESTTEAMS Door Subba Ramaswamy • [email protected]

De rol van testcoördinatoren en teammanagers wordt de laatste jaren steeds complexer. Dat is deels te wijten aan de diversiteit binnen hun testteams. De testers komen uit allerlei culturen en landen, zijn divers qua leeftijd en verschillen qua opleidingsniveau. Als je bedenkt dat het leiden van een testteam sowieso al een uitdagende taak is, dan wordt deze uitdaging alleen maar groter door bovengenoemde elementen, des te meer wanneer je een testteam moet leiden, waarbij je medewerkers werken vanuit een ander land, een paar duizend kilometer bij je vandaan. We zien de laatste jaren een toegenomen belangstelling voor testen als een „uitbestede dienst‟. Testwerkzaamhe-den worden steeds vaker offshore uitgevoerd. Dit heeft alles te maken met de wens om enerzijds de kwaliteit van software te verbeteren door gebruik te maken van ervaren testers en anderzijds de wens om kosten te besparen. Het is dus goed mogelijk dat je als testprofessional op een dag wordt gevraagd om op afstand een team te leiden.In mijn rol als testmanager binnen het Test Centre of Excellence van Accenture heb ik veel ervaring opgedaan in het werken met onshore-/offshore-testteams, zowel vanuit India als ook vanuit Nederland. Die ervaring wil ik graag delen. Met de volgende tips – in willekeurige volgorde – wordt het aansturen van een offshore team een succes.

1. Leer je team kennen Om te beginnen is het niet alleen goed om de, voor Nederlanders soms ingewikkelde, namen te leren spellen, het is ook van belang om ze correct uit te spreken. Hoewel het misschien heel triviaal lijkt, is het erg belangrijk en respectvol om de offshore teamleden correct bij de naam te noemen. Om je team beter te leren kennen kun je bijvoorbeeld alle teamleden vragen om een korte presentatie van een of twee pagina‟s te maken, met een foto en wat persoonlijke informatie over hun opleiding, hobby‟s en interesses. Zo‟n simpele presentatie kan enorm helpen om een betere band te creëren tussen de mensen in Nederland en de offshore collega‟s elders en vice versa.

2. Los taalbarrières op Het werken met teams aan de andere kant van de wereld vraagt om goede communicatieve vaardigheden. Je moet er niet alleen voor zorgen dat het onshore team de collega‟s ver weg goed begrijpt, ook andersom is het belangrijk om te zorgen dat het offshore team de onshore mensen „verstaat‟. Aangezien Engels veruit de meest gebruikte „outsourcing‟-taal is in Nederland, is het niveau waarop de teamleden de Engelse taal beheersen erg belangrijk. De taalbeheersing moet zodanig goed zijn dat iedereen zich goed in het Engels kan uitdrukken en ook gewend is aan het accent dat offshore en onshore gesproken wordt. Dat geldt ook voor de geschreven taal. In Nederland worden de meeste documenten met vereisten en ook de functionele ontwerpen nog steeds in het Nederlands opgesteld. Requirements en functionele ontwerpen zijn de meest belangrijke brondocumenten voor een testspecificatie. Vergeet daarom als testmanager niet om tijd in te plannen voor een goede vertaling van deze documenten. Testscenario‟s en testscripts worden meestal in het Engels geschreven. Een goede beheersing van de Engelse taal door de onshore teamleden is daarom beslist belangrijk voor een goede evaluatie van de geleverde diensten. Een teamlid dat reviewers vanuit de „business‟ extra hulp kan bieden bij het lezen van Engelse teksten is overigens ook heel waardevol. Voor een goede interpretatie van de scripts moet je niet alleen de hoofdlijnen, maar ook de details goed kunnen beschrijven.

Pagina 18

3. Zorg voor een duidelijk proces voor issue en defect management met bijbehorende tools Voor de meeste projecten wordt gebruikgemaakt van defect management tools zoals HP Quality Centre, Rational ClearQuest, Bugzilla of Jira. Dit om defects vast te leggen en op te (laten) lossen, en voor het op afstand beheren van defects. Veel projecten beschikken echter niet over een issue managementproces voor het oplossen van functionele, technische of business gerelateerde vragen die het offshore team mogelijk heeft tijdens de verschillende testfases. De ervaring leert dat dit soort vragen vaak via losse e-mails de wereld rondgestuurd worden. Hierdoor wordt de kennis echter niet optimaal gedeeld en raken antwoorden soms zoek. Kortom, dit is een foutgevoelig en inefficiënt 'proces'. Om dit te verbeteren zijn web-based document managementsystemen of project wiki‟s een uitkomst. Daarmee wordt een goede issuelijst samengesteld, die eenvoudig gedeeld kan worden met alle teamleden. Houd er echter rekening mee dat een tool alleen een hulpmiddel is, het moet goed ingezet worden om er ook echt rendement mee te behalen. Er zijn talloze voorbeelden van projecten waar de allerbeste tools draaien, maar waar ze totaal niet effectief worden ingezet.

4. Werk met een realistische onshore/offshore verhouding Vaak droomt het projectmanagement van een honderd procent offshore testteam om maximaal financieel voordeel te behalen. Dat is niet realistisch. Projectmanagers zijn vaak zo druk bezig met het reduceren van kosten dat het offshoren van zo veel mogelijk activiteiten tot norm verheven wordt. Echter, je kunt beter kijken naar praktische haalbaarheid in plaats van de focus te leggen op percentages. Hierbij is naast toegankelijkheid van de systemen en complexiteit van de business processen ook de ondersteuning van key-users erg belangrijk. Een praktijkvoorbeeld is een project, waarbij een ketentest wordt gehouden over vier verschillende systemen. In zo‟n geval is het bij elkaar zetten van testers in één ruimte onbetaalbaar. De figuur hieronder geeft een indicatie van de taken die kunnen worden uitgevoerd door het onshore respectievelijk offshore team.

Pagina 19

5. Onderhoud documenten in een document managementsysteem Zorg voor een eenvoudig en duidelijk proces voor het opslaan van testscripts, testscenario‟s, voortgangsoverzichten en testresultaten. Het gebruik van een tool zoals HP Quality Centre maakt deze taak aanzienlijk eenvoudiger. Verder hebben veel projecten toegang tot een SharePoint omgeving. Houd rekening met de toegankelijkheid van het document managementsysteem. Die moet zowel op de onshore als op de offshore locatie gewaarborgd zijn. Ook het configuratiemanagement (versiebeheer) van de documenten die in de tool geplaatst worden, is erg belangrijk. Zorg er verder voor dat er duidelijke templates worden ingericht voor de verschillende testdeliverables en neem een checklist op. De auteur van een document kan daarmee controleren of hij het goed en volledig heeft gevuld.

6. Gebruik het tijdsverschil als voordeel Als er in de planning goed rekening mee wordt gehouden, dan kan het tijdsverschil tussen onshore en offshore als voordeel worden gebruikt. De periode waarin het team als geheel beschikbaar is gedurende de dag, is langer doordat er in India eerder gestart wordt met werken dan in Nederland. Het tijdsverschil is vier tot vijf uur. Dit betekent dat er twaalf uur per dag kan worden getest in plaats van acht uur. De bevindingen die gedaan worden door het offshore team op een tijdstip dat we in Nederland nog liggen te slapen, kunnen op het moment dat de Indiërs naar huis gaan door het onshore team gereviewed worden. Als de nieuwe versie van het systeem aan het einde van de dag in Nederland opgeleverd wordt voor hertest, dan is het in India alweer bijna tijd om te starten met de volgende werkdag. Kortom, door goed te plannen kan er maximaal voordeel behaald worden uit het tijdsverschil. Dit vereist echter wel een goede besturing want andersom gaat het ook op: als er zaken verstuurd worden naar India met open punten en onduidelijkheden, dan loop je de kans dat de offshore medewerkers enkele uren moeten wachten voordat ze deze punten kunnen laten verduidelijken door hun onshore collega‟s. Daarmee kunnen heel snel kostbare uurtjes verbrand worden. In de projectfases waarbij veel afstemming vereist is, kan het ook een keuze zijn om het offshore team wat later te laten starten met hun werkdag om juist te zorgen voor meer overlap.

7. Verbeter de coördinatie Veel projecten hebben problemen met offshore testteams doordat de testcoördinator in Nederland geen goed beeld heeft van de dagelijkse activiteiten van het offshore team. Een verminderd vertrouwen is het bijbehorende risico. Om dit te voorkomen is het van belang om goed te focussen op elkaars planningen. De offshore testers zijn vaak ervaren genoeg en ook hun domeinkennis is meestal voldoende. Echter, de projecten worden vanuit Nederland aangestuurd. Deze aansturing moet bestaan uit duidelijk omschreven taken, activiteiten en prioriteiten. Deze moeten dagelijks, bijvoorbeeld in een „morning call‟ afgestemd worden met de offshore medewerkers. Als het offshore team uit vier medewerkers of meer bestaat, dan is het aan te raden om het team te laten aansturen door een offshore testcoördinator. Deel onderling zoveel mogelijk: hoe groter het vertrouwen tussen de teams, des te beter de uiteindelijke resultaten zullen zijn. Als er twijfel is, benoem deze dan en zorg dat de twijfel wordt weggenomen.

Pagina 20

8. Vier de successen en deel de verbeterpunten Zorg ervoor dat niet alleen het onshore team, maar ook het offshore team de credits krijgt die het verdient. Dit kan soms eenvoudigweg door een e-mail of telefoontje. Doordat een offshore team niet in de buurt zit, is het vaak lastiger om hen gemotiveerd te houden. Ook het geven van commentaar is soms nodig. Doe dit op een constructieve manier zonder op de man te spelen. Geef commentaar bij voorkeur schriftelijk. Let daarbij goed op de formulering. Bij schriftelijke commentaren is dat nog belangrijker dan bij mondeling commentaar, omdat de mogelijkheden van non-verbale communicatie ontbreken. Verder kunnen schriftelijke commentaren soms rondgaan onder de offshore teamleden. Als ze erg negatief van toon zijn, dan kunnen ze veel schade aanrichten. Dus geef het offshore team positieve feedback als ze het goed doen en wees hier niet „te zuinig‟ mee. In geval van negatieve feedback, start dan altijd met het positieve gedeelte en noem pas daarna de verbeterpunten.

9. Zorg voor een back-up plan Denk hierbij met name aan situaties waarbij de systeemconnecties tussen Nederland en India tijdelijk wegvallen. Zorg ervoor dat er enerzijds voldoende lucht in de planning zit en dat er anderzijds altijd een lijstje met activiteiten ligt die het offshore team kan oppakken als de connectiviteit onverhoopt weg mocht vallen. Dit zorgt ervoor dat ook de verloren uurtjes zoveel mogelijk nuttig besteed worden en dat de planningen haalbaar blijven.

10. Voorkom het „wij-zij‟ denken maar focus op de gezamenlijke doelen Een veel voorkomend probleem in onshore/offshore testteams is het elkaar over en weer de schuld geven van problemen. Wees heel scherp op het voorkomen van dit gedrag. Zorg dat er zoveel mogelijk sprake is van één team met één gemeenschappelijk doel. Voorkom dat het ene team zich beter voelt dan het andere en verdeel de taken zo evenredig mogelijk. Deel zoveel mogelijk informatie. Stephen Covey zegt het volgende hierover: ‟Een zeer belangrijk principe van Total Quality wordt door veel managers vergeten: je kunt systemen en processen niet continu verbeteren zonder het steeds maar weer verbeteren van de interpersoonlijke en interteam relaties.‟ Zorg er dus voor dat deze relaties kunnen ontstaan en dat ze groeien. Als er conflicten ontstaan, wees dan open en bespreek ze in een conference call, of beter een 'telepresence'. Dit kan het onderlinge begrip verbeteren. Een aantal van voornoemde tips heeft specifiek betrekking op het aansturen van testteams op afstand. De rest is eigenlijk universeel als het gaat om het verbeteren van samenwerking tussen en binnen teams. De kernboodschap is hiervan bewust te zijn en er bewust mee om te gaan. Zo kun je iedere kans aangrijpen om te bouwen aan een omgeving waarin iedereen het beste uit zichzelf haalt.

Pagina 21

HET PROFIEL VAN DE SOFTWARETESTER Door Ard Kramer • [email protected]

Softwaretesten is gegroeid naar een volwaardige „tak van sport‟ in de softwareontwikkeling. Er is weinig onderzoek gedaan naar kwantitatieve gegevens: in hoeverre wordt de testkennis en kunde ook werkelijk toegepast. De soft-waretesters benchmark is een onderzoek naar de stand van zaken met betrekking tot softwaretesten in Nederland dat op deze vragen antwoorden kan geven. Het onderzoek wordt uitgevoerd door een werkgroep van TestNet on-der leiding van mijzelf. De werkgroep bestaat verder uit Huib Schoots, Tim Koomen en Henk van Merode. Wat zijn de eerste resultaten van de softwaretesters benchmark? De eerste resultaten spitsen zich toe op het profiel van de softwaretester en zijn bedoeld als voorproefje. In het volgende nummer van TestnetNieuws zullen wij meer vertellen over de resultaten van de benchmark, zoals de kenmerken van de organisaties waar testers werken en met name welke aanpak, methoden en technieken testers toepassen tijdens hun werk. De resultaten hieronder zijn deels vergeleken met de „salary survey‟ van de Automatiseringsgids van mei 2011. De resultaten van de benchmark zijn gebaseerd op een respons van 330 testers uit heel Nederland. De benchmark is gestart in oktober 2010 en kan nog steeds worden ingevuld op www.softwaretesten.nl.

Het profiel Om meteen met de deur in huis te vallen: één op de vijf testers is een vrouw. Dat is niet direct een verhouding waar we verbaasd over zijn. Als je kijkt naar de resultaten uit het onderzoek in de „salary survey‟, dan blijkt dat het aantal dames onder testers relatief hoog is. In de survey is slechts vijf procent van de respondenten vrouwe-lijk, waarbij ook het getal van elf procent wordt genoemd als gemiddelde vertegenwoordiging van vrouwen in de gehele IT-branche. De leeftijdsopbouw (zie figuur 1) laat duidelijk zien, dat testen zo‟n 15 à 20 jaar geleden een vlucht heeft geno-men. Dat is op

Figuur 1. Leeftijdsopbouw testers

zich begrijpelijk als je kijkt naar de grote groei in de IT en het wordt mede gestaafd door het aantal jaren ervaring onder testers (zie figuur 2). Als we vervolgens kijken naar het dienstverband (zie figuur 3), dan zien we dat de meerderheid van de responden-ten bij een detacheringsbedrijf werkt en dat acht procent zelfstandig als ZZP‟er actief is. Helaas geeft de survey hier geen inzicht in.

Figuur 2. Jaren ervaring testers

Pagina 22

Opleidingsniveau Ten slotte kijken we naar het opleidingsniveau van de tester en vergelijken dat met het opleidingsniveau uit de „salary survey‟. Daarover werd het volgende gezegd: ‟De meeste ICT-functies worden ingevuld door mensen met een HBO- of WO/academische achtergrond. Bijna vierenvijftig procent van de respondenten heeft een HBO-diploma op zak, ruim zesentwintig procent heeft een academische opleiding gevolgd.„ Als je dit citaat vergelijkt met figuur 4, dan blijkt dat testers

Figuur 3. Dienstverband

relatief hoger opgeleid zijn dan de gemiddeld IT‟er. Met name het aantal HBO‟ers is significant (zo‟n negen procent) hoger. In de „salary survey‟ werd hierbij opge-merkt dat de opleiding gemiddeld hoger lag bij detacheringsbedrijven. Aangezien testers ook vaker bij detache-ringsbedrijven werken, kan dit een van de verklaringen voor het hogere opleidingsniveau van de tester zijn.

Conclusie Vergeleken met de recente „salary survey‟ van de Automatiseringsgids kunnen we in ieder geval afleiden dat er

Figuur 4. Hoogste opleiding testers

meer vrouwen testen dan er gemiddeld werkzaam zijn in de IT en ook dat testers hoger opgeleid zijn dan de door-snee IT‟er. Meer resultaten in het volgende nummer van TestnetNieuws en op het najaarscongres van TestNet.

THEMA-AVOND 11 APRIL 2011 – USABILITY TESTEN Door kennisgroep Usability Testing • [email protected]

Op 11 april heeft de kennisgroep Usability Testing een thema-avond georganiseerd over usability testing. Op deze avond waren meer dan honderd leden afgekomen. Een belangrijk onderdeel van de avond was de terugkoppeling van de resultaten van een enquête die onder de leden van onder andere TestNet en CHI Nederland is gehouden. Een live demonstratie van een usability test, een levendige discussie, een quiz met de bijbehorende prijsuitreiking en het uiteindelijk mogen verwelkomen van een nieuw lid tot de werkgroep, maakte dit een geslaagde avond. Huib Schoots, lid van de evenementencommissie en bestuurslid werkgroepen, opende de avond en stelde de leden van de kennisgroep voor. Daarna werd het woord gegeven aan Marcel Nahapiet.

Inleiding Marcel Nahapiet leidde de avond in met een presentatie getiteld ‟TMap testing & Usability Testing‟. Op een wervelende manier vertelde Marcel hoe hij zich binnen het vakgebied ontwikkeld heeft in de periode 1999 – 2011. Hierbij wist hij, aangekleed met vele voorbeelden uit eigen ervaring, aan te geven waar de overeenkomsten en ver-

Pagina 23

schillen tussen TMap testen en Usability testen liggen, zie ook onderstaande slide uit zijn presentatie. Marcel sprak de hoop uit dat IT-testers het bredere aspect van usability testen zouden ontdekken naast de nu veelgebruikte checklists zoals SUMI en WAMMI. Presentatie resultaten usability enquête Vervolgens werden de resultaten van de enquête gepresenteerd die in totaal door 228 testers was ingevuld (IT-testers en usability testers). Uit de enquête blijkt dat bijna alle IT-testers ervan zijn overtuigd dat usability testen tot een kwalitatief beter product leidt. Op het gebied van kennisdeling viel op dat IT-testers zich verder willen ver-diepen in usability-testtechnieken en een behoefte hebben in de ROI van usability. IT-testers willen graag usability testen, zien dat als een verrijking van de functie en denken dat ook te kunnen doen. ‟Ik kan wat jij kunt en jij kunt wat ik kan‟ zeggen de IT-testers. Usability testers daarentegen zijn defensiever en zeggen: ‟ik kan wat jij kunt, maar jij kunt niet wat ik kan.‟ Er blijkt dus een eenrichtingsverkeer te zijn wat betreft de kennisoverdracht tussen beide vakgebieden. In Release Magazine 2 wordt nadrukkelijker ingegaan op de conclusies uit de enquête. De resultaten van de enquête zijn ook na te lezen op onze werkgroeppagina op www.testnet.org.

Workshop usability testen Na de pauze volgde een workshop actief usability testen. Als test(ontwerp)techniek werd hierbij gekozen voor „Think Aloud‟. Als website werd gekozen voor een website waarop reizen geboekt kunnen worden: http://www.connections.be. Een „gebruiker‟ werd gevraagd om in een bepaalde week een zo goedkoop mogelijke reis te boeken. De opdracht aan de zaal was om te achterhalen welke usability punten aan de hand van de gedemonstreerde usability test geformuleerd konden worden. De gebruiker bleek vrij snel tegen een aantal zaken aan te lopen in de website. Het boeken van de reis ging niet goed, wat tot gelach in de zaal leidde. Uit de nabespreking van de gedemonstreerde usability test bleek dat de zaal redelijk snel een aantal direct toepasbare quick wins kon formuleren. Saillant detail hierin is dat de site in 2010 de derde prijs heeft gewonnen bij de uitreiking van de Usability Awards in België. Aansluitend werd nog een leuke en leerzame usability quiz gehouden met een aansluitende prijsuitreiking.

Toekomstvisie Na dit leuke en leerzame intermezzo werd een blik gegeven op de toekomstvisie van de kennisgroep. De kennisgroep usability testen wil in de toekomst de kennisuitwisseling op het gebied van usability testen versterken. Dit willen ze doen door het verspreiden van praktische tips over hoe een usability testproject aangepakt moet worden en inzicht te verschaffen in de ROI van usability testen. Door kennis te delen hopen we de samenwerking tussen IT-testers en usability testers verder vorm te kunnen geven. Na een groot applaus voor de kennisgroep usability testen was de thema-avond afgerond en kon er gestart worden met de befaamde netwerkborrel.

Pagina 24

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

Hoe kunnen testers en ontwikkelaars beter met elkaar samenwerken?. In het vorige nummer van TNN heb ik laten zien hoe dat met Vision Studio 2010 kan. In dat eerste deel heb ik de testrol beschreven. In dit tweede deel gaan we over naar de ontwikkelaar en kijken naar hoe hij verder kan met een door de tester geconstateerde bug. In de Team foundation Server kunnen we de bug openen die de tester heeft aangemaakt en daarbij kunnen we de intellitrace™ logfile terugvinden. Vervolgens open je de logfile vanuit het work item. Na het openen van de logfile krijgen we een overzicht te zien zoals te zien in figuur 1. In dit overzicht is ook direct terug te zien welke stappen de tester heeft uitgevoerd en die zijn onder het kopje test Data toegevoegd.

Figuur 1: Intellitrace overview In de bug beschrijving is duidelijk terug te vinden dat we de bug hebben aangemaakt op stap nummer 3 in de test, die overeenkomt met stap 2 in de log. Vervolgens kunnen we dubbelklikken op deze stap en zal direct het intellitrace™ debug venster worden geopend waarin we de events kunnen zien die intellitrace voor ons heeft opgenomen. Zie figuur 2 en 3.

Pagina 25

Figuur 2: Intellitrace event view

Figuur 3: Intellitrace calls view

Nu je de intellitrace vensters open hebt staan, kun je zien welke events zijn afgegaan gedurende de testrun. In het meest gunstige geval, treedt de bug op doordat er ergens een Exception optreedt, bijvoorbeeld een File IO exception. Je ziet dan direct in de intellitrace event view dat er een unhandled exception is opgetreden. Verder kun je daar ook zien wat de gebeurtenissen waren die vooraf zijn gegaan aan de unhandled exception. Bijvoorbeeld zaken zoals File IO of Registry access. Als je nu denkt dat een bepaald event de oorzaak is van het probleem, dan kun je door te dubbelklikken op dat event, direct naar de source code springen. De juiste code file wordt vervolgens geopend in de debugger. Zie figuur 4. Vervolgens kun je dan in het debug window inspecteren wat de waarden van parameters waren op het moment dat de functie is aangeroepen. Intellitrace™ kan niet de lokale variabele waarden opslaan, maar de informatie over de functie aanroep inclusief zijn parameters, is normaal gesproken al meer dan voldoende Figuur 4: Intellitrace™ geïntegreerd in debuger

Pagina 26

informatie om het pro-bleem op te sporen. Als je denkt dat niet deze functie maar een aanroepende functie het probleem is geweest, dan kun je ook via het calls view window, of de dubbele pijltjes omhoog in het debugger window, verder terug in de tijd gaan naar de functies die deze functie hebben aangeroepen. Op deze manier is het dus mogelijk geworden eigenlijk als een soort video recorder heen en weer te spoelen in de tijd en te inspecteren wat er op dat moment zich heeft afgespeeld in de code. Je kunt je waarschijnlijk wel voorstellen dat intellitrace™ zeer effectief is voor het opsporen van fouten, die door een tester zijn geconstateerd. Maar er is nog meer! Naast het werken met een logfi-le vanuit een bug, kan Intellitrace™ een ontwikkelaar op nog een andere manier van dienst zijn.

Breakpoint We kennen allemaal wel het dagelijkse ritueel waarbij we een breakpoint plaatsen in de buurt van de plaats waar we verwachten dat de fout zit. Vervolgens starten we het programma, zorgen voor de input waarmee we verwachten de fout opnieuw te laten optreden, maar vervolgens zien we dat we net een regel te ver een breakpoint hebben gezet, of dat deze op een plaats staat waarna we zelf nog tien keer een „step over‟ uitvoeren om er vervolgens achter te komen dat net op die ene functie het een „step into‟ had moeten zijn. Dit soort debug sessies kosten nodeloos veel tijd en dat allemaal omdat de debugger standaard alleen kan laten zien wat er in het huidige stackframe gebeurt. Met intellitrace™ is dit probleem ook verleden tijd. Op het moment dat we een debug sessie starten zal intellitrace™ namelijk standaard direct op de achtergrond meedraaien en een logfile opslaan van alle ‟events‟ die we hebben aangegeven interessant te zijn voor onze applicatie. Als we nu zien dat we per ongeluk een stap te ver zijn gegaan, kunnen we direct via het intellitrace window de functie selecteren die we zojuist hebben overgeslagen en direct zien wat er in die functie met de input en output is gebeurd. Intellitrace kent op dit moment nog wel een aantal beperkingen. Zo is het niet mogelijk om een 64 bits applicatie direct in de IDE te debuggen met intellitrace™. Je zult de applicatie daarvoor in de Any CPU mode moeten compileren, waarna het wel mogelijk is. Het is overigens wel mogelijk een trace log te laten aanmaken voor een 64 bits applicatie. Deze log is dan ook prima te gebruiken in Visual studio, zolang je daar maar terugstapt naar de Any Cpu configuratie. Verder zijn een aantal nieuwe features van de debugger ook nog niet opgenomen in de intellitrace™. Denk hierbij aan het parallel Stacks en parallel tasks window. Deze zijn momenteel niet functioneel in intellitrace™ debug mode. Een veelgevraagd scenario is dat je intellitrace ook kunt uitleveren samen met de eigen applicatie. Deze zou je dan kunnen activeren als er een verstoring optreedt die moeilijk blijkt te reproduceren. Je kunt dan tijdelijk de trace laten meelopen en de klant de trace laten opsturen. Dit is zeker een scenario wat Microsoft in de toekomst mogelijk wil maken, maar dit is nog niet mogelijk met de huidige implementatie.

Coded UI Testen We hebben nu gezien dat we een requirement kunnen testen en dat we een gevonden bug eenvoudig kunnen reproduceren in de Visual Studio IDE. Zoals we vandaag de dag allemaal weten is het een best practice om, voordat je een bug oplost, deze eerst aan te tonen met behulp van een unit test. Maar goed, dat is niet altijd een even gemakkelijke opgave. Helaas komt het nog geregeld voor dat een ontwikkelaar toch nog een paar uur bezig is het probleem te reproduceren in een unit test, terwijl de bug fixen zelf maar een paar minuten werk zou zijn geweest. Op dit punt kan een andere nieuwe eigenschap uit Visual Studio 2010 uitkomst bieden voor dit probleem. Visual Studio 2010 biedt namelijk vanaf de Premium editie de mogelijkheid een unit test te maken van het type CodedUItest. Een CodedUItest, is een nieuw type test die gebruik kan maken van de eerder opgenomen action log uit

Pagina 27

de testsessie (zie de optie voor het opnemen van de test stappen eerder beschreven bij het uitvoeren van de test in MTM). Zoals al te zien was in figuur 5 in het eerste deel van dit artikel in TNN15-1 is ook een action log opgenomen gedurende de test. Een dergelijke action log, kan met behulp van de „Coded UI Test Builder‟ code generator die onderdeel is van de Visual Studio IDE, direct een test worden gegenereerd die exact de stappen uitvoert die de tester ook heeft uitgevoerd. In de CodedUITest wordt een map file aangemaakt die de UI automation stappen bevat voor het naspelen van een volledige action log. Het is ook mogelijk om een nieuwe recording aan te maken en het is dus niet altijd nodig dat de tester deze bestanden aanlevert. Interessant punt is alleen wel dat uitsluitend het naspelen van de acties van de tester geen informatie oplevert of de test nu wel of niet een fout aantoont. Om dit mogelijk te maken heeft men de optie toegevoegd voor het genereren van een Unit test assertion. Een assertion voor een codedUITest betreft het opzoeken van een control in de UI en vervolgens te kiezen welke conditie moet worden gecontroleerd. In figuur 5 hieronder is te zien hoe met behulp van het „Coded UI Test Builder‟ een control kan worden opgespoord en hiervoor een assertion wordt uitge-genereerd. Vervolgens kunnen we nu een coded UI test op dezelfde manier als de standaard unit testen onderdeel laten uitmaken van de set aan Figuur 5: Coded UI Test Builder

testen die we iedere dag in de build willen laten mee-draaien.

Test impact analysis Stel, je hebt uiteindelijk de applicatie van voor tot achter doorgetest en naast een groot aantal unit testen ook een groot arsenaal aan CodedUITesten en handmatige testen geschreven. Welke van deze testen moet ik dan uitvoeren om aan te tonen dat een aanpassing in code potentieel regressie bugs oplevert? Om op die vraag antwoord te krijgen heeft Microsoft een feature toegevoegd onder de naam Test Impact analysis. Test impact analysis maakt ook gebruik van een collector die gedurende de testen op de achtergrond informatie wegschrijft. Echter, in dit geval schrijft de collector alleen informatie weg die relevant is voor het bepalen van testimpact bij code aanpassingen. De weggeschreven log dient vervolgens geregistreerd te worden bij een build die voor de applicatie is gedefinieerd. Nadat dit is gebeurd, is het mogelijk om tussen twee builds van de applicatie aan de team foundation server te vragen welke testen opnieuw moeten worden uitgevoerd omdat ze op een of andere manier een relatie hebben met de aangepaste code. Naast dat test impact analysis voor de ontwikkelaar kan aangeven welke (unit)testen hij opnieuw dient uit te voeren, heeft Microsoft ook een check in policy beschikbaar gemaakt, die je kunt gebruiken om de ontwikkelaar te verplichten alle aanbevolen testen ten minste opnieuw te draaien voordat de code wordt ingecheckt in versie beheer.

Pagina 28

Ook de Generalist tester kan in de MTM omgeving bekijken welke testen worden aanbevolen. Hierbij is in het testplan aan te geven voor welke build de testrun wordt gepland. Vervolgens kan dan worden opgevraagd wat de lijst met aanbevolen testen is voor een betreffend plan. Op deze manier is dus niet alleen de ontwikkelaar, maar ook de tester voorzien van een minimale set aan testen die worden aanbevolen.

Conclusie Op basis van de features die ik in de beide delen van dit artikel de revue heb laten passeren kan wel worden gesteld dat de Visual Studio 2010 Ultimate edition en de Test Professional editie zeker veel toegevoegde waarde biedt bij het gestructureerd functioneel testen van onze applicaties. Microsoft is er goed in geslaagd op basis van integratie tussen de test- en ontwikkeldiscipline ervoor te zorgen dat de Bouw, test, Fix cycle die we dagelijks maken sterk kan worden geoptimaliseerd. Met behulp van Intellitrace™, Test Automation en Test impact analysis zijn we in staat ervoor te zorgen dat testen niet meer een sluitpost van de projectbegroting zijn, maar dat we dit effectief kunnen inzetten om de kwaliteit van onze applicaties te verbeteren. Door ook de traceerbaarheid tussen de requirements en testen direct te regelen via work item tracking is men nu in staat in een project aan te tonen welke requirements ook daadwerkelijk getest zijn voordat we opleveren. Vanaf een organisatie aan de slag gaan met Visual studio 2010 wordt het mogelijk om testen werkelijk een integraal onderdeel te maken van projecten en ervoor te zorgen dat de klanttevredenheid, zeker ten aanzien van de kwaliteit van de opgeleverde applicaties, aanzienlijk verbeterd.

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

Een 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! Hieronder een bijdrage van KZA.

„THE GRAND QUESTION DEBATED‟ Door Leon Bosma [email protected]

Grasduinend in mijn boekenkast kwam ik onlangs een echte klassieker tegen. Met een goed glas en vage herinne-ringen begon ik te lezen. Al na de eerste hoofdstukken vielen mij overeenkomsten op tussen het verhaal en ons vak. Dat beeld werd sterker naarmate ik verder las. Uiteindelijk kon ik niet om deze conclusie heen; deze auteur is een visionair voor testen. Hij heeft geen achtergrond in automatisering. Een groot deel van zijn leven werkte hij als secretaris en even was hij zelfs predikant. Geboren werd hij in Dublin, om precies te zijn op 30 november 1667. Zijn naam is Jonathan Swift.

Pagina 29

Ons vak is een stuk jonger, volgens de geboorteakte van TMap is het nu zestien jaar oud. Dus uit de kinderschoenen, de grootste veranderingen uit de pubertijd achter de rug en tijd om na te denken over een volwassen toekomst. Om daarbij juiste keuzes te kunnen maken, is een visie op morgen niet voldoende. Een eerlijk beeld van vandaag is het essentiële startpunt. In zijn bekendste werk geeft Swift een heldere kijk op de status van ons vak. De hoofdpersoon, Gulliver, reist door verschillende landen en culturen. In het verslag van twee van zijn reizen wordt ons als testers een driehonderd jaar oude spiegel voorgehouden.

Lilliput „It began upon the following occasion: It is allowed on all hands, that the primitive way of breaking eggs, before we eat them, was upon the larger end; but his present majesty's grandfather, while he was a boy, going to eat an egg, and breaking it according to the ancient practice, happened to cut one of his fingers. Whereupon the emperor, his father, published an edict, commanding all his subjects, upon great penalties, to break the smaller end of their eggs. The people so highly resented this law, that our histories tell us, there have been six rebellions raised on that account.‟ In de beginjaren was sequentieel testen de norm. Het V-model is daarin leidend en heeft zijn nut bewezen. Tegelijk heeft het klassieke testen ook nadelen. In meer dan één project sneden testers zich in de vingers met deze aanpak. Het antwoord op de nadelen werd gevonden aan het andere einde van het ei; ontwikkel en test iteratief. Inmiddels zijn er twee kampen. Ze pakken ieder ei vanaf de eigen kant aan. Ze hebben het gevoel dat alleen zij het goed doen. En ze verwijten elkaar te dogmatisch te zijn. De ironie is fraai. Er zijn nog geen opstanden geweest rond dit onderwerp en dat hoeft ook niet. De oplossing ligt voor de hand; blijf vragen! Vragen stellen is het krachtigste middel dat we hebben. Een goed gestelde vraag laat ons zien wat de betekenis is van wat de ander zegt. Wat de betekenis is voor hem en wat de betekenis zou kunnen zijn voor ons. Iedere dogmatische discussie begint wanneer het vragen stopt. Zodra weer vragen worden gesteld, stopt de dogmatiek en begint het leren. Blijven leren is essentieel voor een vak als het onze. Niet ieder ei is hetzelfde en dus zal geen enkele aanpak onder alle omstandigheden werken. Geen enkele klant is geholpen met een tester die dogmatisch één aanpak toepast. Er is niet één antwoord voor alle vragen. Dus blijf vragen.

Futiliteit Verder lezend ontdek ik dat Swift nog lang niet klaar is met ons en de futiliteit van sommige discussies in ons vak; de haren kunnen immers nog veel fijner gekloofd. „[…] you are to understand, that, for above seventy moons past, there have been two struggling parties in this empire, under the names of Tramecksan and Slamecksan, from the high and low heels of their shoes, by which they distinguish themselves. […] The animosities between these two parties run so high, that they will neither eat nor drink nor talk with eachother.‟ Er zijn zeker verschillen tussen ISTQB en TMap. Maar op geen enkele wijze rechtvaardigen deze verschillen een rangschikking. Zoals de hoge en de lage hakken waarschijnlijk door dezelfde schoenmaker zijn gemaakt, zo zijn ISTQB en TMap voor een flink deel door dezelfde kennis, ervaring en zelfs individuen voortgebracht. Dezelfde leest, dezelfde ha-

Pagina 30

mer en hetzelfde leer; dezelfde risico-gebaseerde aanpak, dezelfde fasering en, voor het grootste deel, dezelfde technieken. Tegelijk vraagt niet iedere gelegenheid om dezelfde schoenen en loopt niet iedereen gemakkelijk op hoge hakken of vindt juist lage hakken mooi, dus is één paar schoenen niet genoeg. Zoals een tester niet kan volstaan met één techniek of methodiek. Hij zal een breed scala moeten beheersen en de omstandigheden laten bepalen welke hij inzet. Ook hier dus alle aanleiding om te blijven vragen. Nippend aan het laatste beetje in mijn glas merk ik dat de discussie over eieren en hakken volgens Swift niet eens ons grootste gebrek is.

Laputa „I went into another chamber but was ready to hasten back, being almost overcome with a horrible stink. […] The projector of this cell was the most ancient student of the academy. […] His employment from his first coming into the academy was an operation to reduce human excrement to its original food by separating the several parts, removing the tincture which it receives from the gall, making the odor exhale, and scumming off the saliva. He had a weekly allowance from the society of a vessel filled with human ordure, about the bigness of a Bristol barrel.‟ In de afgelopen jaren hebben wij onszelf ervan overtuigd dat testen intrinsiek nuttig is, dat testen altijd moet. Veel opdrachtgevers delen dit beeld, overigens vaak zonder precies te weten waarom. Ook vragen niet veel opdrachtgevers zich dagelijks af wat er in de krochten van hun IT-organisatie gebeurt. Nog minder van hen willen exact weten wat er zich in een testlab afspeelt. Hun belang ligt vaak elders. En als ze die belangstelling wel hadden, zouden wij ze dan met goed fatsoen kunnen binnenlaten? Hoe zeker zijn we er van dat we iets nuttigs doen, dat we daadwerkelijk bijdragen aan de resultaten van de organisatie waarvoor we werken? Vaak en teveel worden testopdrachten aangenomen zoals ze zijn. De meeste testers lijken zich niet te verdiepen in de achterliggende behoefte, maar zij duiken zo snel mogelijk in hun methodes en technieken. De stappen die zij vervolgens zetten, zijn gestructureerd, traceerbaar en herhaalbaar. Het vat wordt iedere week aangepakt en methodisch verwerkt. En het resultaat? Ook hier geldt; blijf vragen! Starend over de rand van mijn glas kom ik tot een eenvoudige conclusie. Zolang we onderling blijven kibbelen over de juiste kant van het ei, de passende hoogte van hakken en wekelijks samen de twijfelachtige inhoud van vaten ontleden, kunnen we geen werkelijke bijdrage leveren. En mocht je het niet met me eens zijn, bewijs dan niet mijn gelijk door geen vraag te stellen.

Pagina 31

NIEUWE HELDEN: THE FINAL Door Jan Jaap Cannegieter • [email protected]

10 mei was het zover: het TestNet Voorjaarsevenement „Nieuwe helden‟. Een TestNetevenement waar ik naar had uitgekeken, omdat er niemand mocht presenteren die ooit bij TestNet, EuroSTAR of een andere testconferentie had gesproken, afgezien van de buitenlandse keynote sprekers. Ruim baan voor nieuw talent dus. Een verslag.

Artikeltje Wat was de aanleiding voor deze avond? Het begon allemaal met een artikeltje van mijn hand in TNN begin 2010. Daarin vroeg ik me af waarom we toch steeds dezelfde namen zien op seminars en op boeken. Het was in mijn gedachte een pretentieloos, luchtig artikeltje. Tot mijn verbazing maakte het veel los. Verschillende mensen die een reactie gaven, zeiden dat er wél nieuwe helden zijn en daarbij kwamen heel wat namen voorbij. En dat is natuurlijk gewoon waar. Anderen zeiden dat er best nieuwe helden zijn, maar dat die nieuwe media, zoals blogs, twitter en discussieforums, gebruiken. En oude helden (waaronder ik voor het gemak ook werd ingedeeld) gebruiken die over het algemeen niet, dus weten die oude helden het niet. Daar zit ook wel een kern van waarheid in. Nog anderen zeiden dat het juist prima is dat we onze oude helden blijven eren, omdat zij toch de basis hebben gelegd voor testen in en buiten Nederland. Ook dat is weer waar. Veel goede discussie dus, prima! Een uitvloeisel van het artikel en de discussie erna was het voorjaarevenement „Nieuwe helden‟. Dit was absoluut niet mijn bedoeling toen ik het artikel schreef, maar het is wel erg goed: ruimte voor nieuw talent.

Wisselende kwaliteit Hoe was het evenement nou uiteindelijk? Eigenlijk zoals ik had verwacht. Je kunt maar drie van de negen tracks bijwonen. Om dus een compleet beeld te krijgen moet ik ook afgaan op de reacties van anderen. En ik kom dan tot de conclusie dat de kwaliteit wisselend was. Dat is niet vreemd, want er staan immers mensen met weinig ervaring. Kunnen wij, TestNet en de presentatoren, er nog iets van leren? Ja, zeker. Op basis van wat ik zelf heb gezien en wat ik heb gehoord, zit het met de inhoud van wat gepresenteerd werd wel goed. Uit onderzoek over communicatie wordt de mate waarin een boodschap overkomt voor acht procent bepaald door de inhoud, voor 37 procent door intonatie en stemgebruik en 55 procent door non-verbale communicatie. Nu is presenteren niet hetzelfde als communiceren, maar ik denk dat deze cijfers voor presenteren niet heel anders liggen. Mijn beeld na het TestNet voorjaarsevenement is dat bij sommige presentatoren de aandacht voor stemgebruik en non-verbale communica-tie te laag was. En dat is zo belangrijk! Wat dat betreft had TestNet helemaal de goede voorbereiding gedaan door een workshop presenteren te laten verzorgen door Derk-Jan de Grood. Maar ja, na één cursus testen waren we ook nog geen volleerd tester, toch?

Boodschap Kortom, om een boodschap over te brengen heb je meer nodig dan kennis van zaken en een goede boodschap. En ook dat moet je leren en daar moet je ervaring mee opdoen. Fantastisch van het TestNet bestuur dat ze een aantal onbekende TestNetters die mogelijkheid boden. Dat moeten ze in de toekomst zeker ook blijven doen. Voor de presentatoren was het een eerste stap en hopelijk volgen er meer. Was het voorjaarsevenement nu een succes? Ik vond van wel!

Pagina 32

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‟.

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.

Thema-avond Testlab XL Woensdag 7 september 2011 18.00-21.00 uur Nadere informatie over de opzet van het extra grote testlab volgt op de website.

Najaarsevenement – Cloud Testing Dinsdag 4 oktober 2011 9.00-21.30 uur Het thema is “Cloud testing; roze wolk of gebakken lucht?”. • ‟s ochtends zijn er 4 tutorials van 3 uur • ‟s middags en ‟s avonds zijn er in totaal 16 presentaties van 45 minuten, omlijst met keynotes. Virtualisatie, testen in de cloud, cloudtesting, laaS, PaaS en SaaS om maar een paar termen te noemen. Is de cloud inmiddels volwassen geworden? En hoe beweeg je als tester, testafdeling of als testleverancier mee in deze ontwikkelingen? Het najaarsevenement is een mooie gelegenheid om je ervaringen te delen met je vakgenoten.

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