Voorjaarspecia l Me i 2014 2013

Pagina 1

Oktober 2014 • Jaargang 18 • Najaarsspecial

www.testnet.org secretaris@testnet.org

COLOFON

Redactie Bestuur

Paul Beving Rik Marselis Voorzitter

Kees Blokland John de Goei Penningmeester

Astrid Hodes Peter van Tulder Evenementen & thema-avonden

Hans van Loenhoud Kees Blokland Informatievoorziening & beheer

Gerben de la Rambelje Bernd Beersma Marktverkenning & werkgroepen

Johan Vink Harro Philip Secretaris & ledenadministratie

Rob van Steenbergen

redactie@testnet.org

Opzeggen l idmaatschap: http://www.testnet.org/a lgemeen/a lgemene -voorwaarden.html#opzeggen

VAN DE REDACTIE

Door Rob van Steenbergen ● redactie@testnet.org @rvansteenbergen

Hoe verbeter ik mijn prestatie? Als je het mij vraagt is het essentieel om zoveel mogelijk

ervaring op te doen. Als je iets voor de eerste keer doet, bijvoorbeeld het testen van een

webapplicatie, dan zal je nog veel moeten uitvinden en uitzoeken. Het voor de tweede

keer testen zal al een stuk beter en sneller gaan. Het lijkt op eerste gezicht lastiger om

variatie in je ervaring op te bouwen en dat is misschien nog wel belangrijker. Elk project

heeft zijn specifieke aanpak nodig en het testen zal dan ook elke keer aangepast moeten

worden aan een specifieke situatie. Deze flexibiliteit kan je niet bereiken door met een

standaard testplan elk project proberen te bedienen. Hoe bouw je nieuwe ervaringen op om als tester flexibel te

worden in je aanpak?

De mogelijkheden om nieuwe ervaringen op te doen zijn vaak makkelijk te bereiken. Zowel op persoonlijk vlak of

op teamniveau. Vind je bijvoorbeeld het testen wat stroef gaan in combinatie met een bepaalde afdeling, dan is een

paar dagen vertoeven bij die afdeling wellicht voldoende om de samenwerking te verbeteren. Heb je wat praktische

tips nodig? Dat is mooi, want in dit magazine vind je er genoeg. Ik heb bijvoorbeeld zelf een artikel geschreven over

hoe ik een bughunt heb georganiseerd. Verder kan je ideeën opdoen over hoe je stap voor stap testverbeteringen

kunt uitvoeren of hoe je je sociale vaardigheden ten opzichte van je dagelijkse werkzaamheden kunt verbeteren.

Ideeën genoeg en zo in dit blad voor het grijpen. Laat je inspireren door de artikelen die deze verhalen vertellen en

maak daarmee je eigen werk en dat van je team nog beter. Dit najaarsmagazine helpt je hierbij, dankzij de auteurs

van de artikelen (bedankt!). Het is weer een boeiende mix van ervaringsverhalen, persoonlijke verbeteringen en de

nodige verdieping. Verdieping in jezelf; het eerste artikel gaat in principe niet eens over testen; en verdieping in het

testvak. Grijp je kans, lees één of meerdere artikelen en laat je inspireren. Hier een tip: neem jezelf voor dat je één

idee wat tijdens het lezen in je opkomt daadwerkelijk in praktijk brengt. Dan ben je al aardig aan de verbetering

van je prestaties bezig. Succes!!

Pagina 2

Nieuws.testnet.org – TestNetNieuws wekelijks online

De TestNetNieuws ‘Weekly’ verschijnt iedere week in de vorm van één artikel op de website. Surf eens

naar TestNetNieuws op http://nieuws.testnet.org!

In dit nummer

Van de redactie 1

Van de voorzitter 3

Testen met aandacht 4

Mijn ervaringen met een bughunt 7

Hoe leer je werken met een testtool? 12

Reis om de wereld in één dag 15

Testware genereren met Sepiola 17

Serious games voor testers 18

Het testgeval - een epistemologische deconstructie 22

Succesvolle testverbetering in iedere situatie 27

Bughunting - testen vergeleken met een spelletje zeeslag 33

Productrisicoanalyse: Vele wegen leiden naar Rome! 36

Beter is niet altijd goed 40

Hoe maak je kwaliteit van IT-implementaties wel meetbaar... 43

Testen: Houding en sociale vaardigheden maken het verschil 49

Spreadsheet testen met spreadsheets 52

Focus op verbeteringen? Ervaringen van een ex-perfectionist 54

Testen? Natuurlijk, da's logisch. Biologisch! 58

Goed, beter, best: op weg naar een perfect presterend team! 60

En de winnaar is... Functionaliteit? 67

Pagina 3

VAN DE VOORZITTER

Door Rik Marselis ● voorzitter@testnet.org

Beste TestNetter, hoe zit het met jouw test-prestatie?

Lastige vraag eigenlijk hè? Wat bedoelen we met ‘prestatie’? Gaat het om je

persoonlijke prestatie? Of hoe effectief je testproces is? Of de prestaties van het

testobject?

Antwoord: Ja, … alledrie.

Want dat is waar we het op dit najaarsevenement over gaan hebben. Er komen weer

bijzonder inspirerende presentaties over allerlei deelgebieden van ons mooie vak.

Neem alleen al de twee keynotes. Eerst komt Alon Linetzki, een testexpert die al jarenlang op de testconferenties in

de wereld aanwezig is, maar nog niet eerder in Nederland. Hij gaat met ons in op de combinatie van testen en Agile.

Dat hij daar wat van af weet, blijkt wel uit het feit dat hij een van de mensen is die de ISTQB Foundation Agile

Extension syllabus hebben gemaakt. Een interview met Alon heb je kunnen lezen in de TestNet Nieuws Weekly, kijk

het nog eens even terug via deze link. De andere keynote is niet van een persoon maar van een werkgroep. En niet

zomaar een werkgroep, maar, mag ik namens ons allen denk ik toch wel zeggen, de meest succesvolle werkgroep

gemeten naar het aantal mensen dat werkelijk met hun resultaat aan de gang gaat. De werkgroep HBO/Universitair

Curriculum heeft namelijk hun eerste resultaat opgeleverd. HBO-instellingen gaan daadwerkelijk op basis van het

door de werkgroep ontwikkelde curriculum IT-studenten opleiden. Zodat we voortaan jonge vakgenoten krijgen die

onmiddellijk aan de slag kunnen. Graag feliciteer ik alle werkgroepleden (zowel uit de onderwijswereld als uit het

bedrijfsleven!!) met hun succes.

Een evenement bestaat natuurlijk uit meer dan keynotes. In de ochtend kun je zoals gebruikelijk kiezen uit vijf

workshops waarin je in drie uur uitgebreid ingaat op een bepaald deel van het vakgebied. ’s Middags en ’s avonds

heb je weer ruime keuze uit de beste presentaties die zijn ingezonden op de call for papers.

Heb je je al aangemeld voor het evenement? Fijn, je gaat weer een prima dag beleven!! Nog niet? Doe dat dan snel!

En kun je niet de hele dag, geen nood, aangezien het gratis voor leden is, kun je ook gewoon even aan het eind van

je werkdag langskomen, een presentatie en een keynote meepakken, gezellig een hapje mee-eten en weer naar

huis. Want dat is het mooie van een vereniging: je mag het precies inrichten zoals jij wilt, niets hoeft maar als je

wilt kun je alles meemaken. En het is ook een kwestie van leden onder elkaar, want bijna alle sprekers zijn zelf

TestNet-lid. Zo werken we met z’n allen aan het mooi houden en verder uitbouwen van het testvak in Nederland en

ver daarbuiten.

Gebeurt er meer binnen TestNet? Natuurlijk! We hebben nog veel meer actieve werkgroepen, kijk eens op de

website. En de redactie maakt wekelijks een interessant stuk via de website en periodiek deze mooie elektronische

nieuwsbrief. De evenementencommissie is al druk bezig om de thema-avonden en evenementen van 2015 te

organiseren, binnenkort komt de call-for-papers.

Verder zijn de secretaris en penningmeester in hun nopjes, de ledenadministratie gaat soepel, het aantal leden blijft

gestaag groeien, en daarmee blijft onze vereniging ook financieel gezond. Kortom, TestNet is voor en door testers,

en door al deze actieve testers heel waardevol voor de IT in het algemeen.

Tot ziens op het evenement en/of een van de thema-avonden!

Pagina 4

TESTEN MET AANDACHT

Door Esther Kluver ● Esther.Kluver@bartosz.nl

Ken je dat gevoel? Dat een dag voorbij is gevlogen, zonder dat je precies weet wat je hebt

gedaan? Kom je ‘s avonds vermoeid thuis, terwijl je voor je gevoel weinig hebt gedaan die

dag? Je hebt waarschijnlijk de hele dag op de automatische piloot gewerkt en veel te veel

energie gestoken in zaken die er niet direct toe doen. Je vindt jouw werk leuk en gaat met

plezier naar je werk, maar toch knaagt er iets. Je krijgt er geen energie meer van. Misschien

levert het zelfs stress op! Wat je zelf niet direct merkt, is dat deze automatische piloot ook de

kwaliteit van jouw werk beinvloedt. Je mist de frisse blik op de zaak die voor een testanalist

zo kenmerkend is. Je kunt deze automatische piloot uitzetten en meer uit je werk halen. Een

in populariteit groeiende benadering om dit te kunnen bereiken is mindfulness.

Mindfulness wordt vaak vertaald als aandachtstraining of opmerkzaamheid. Het is een vertaling van oosterse

meditatietechnieken naar een in het Westen aansprekende benadering. Mijn eerste reactie hierop was ooit:

‘Meditatie? Uren stil zitten op een kussentje met brandende wierook en zweverige muziek? Dat is niks voor mij! Daar

ben ik veel te nuchter voor.’ Gelukkig ben ik er achter gekomen dat dit beeld van meditatie niet overeenkomt met

de werkelijkheid. Zelf heb ik het dan ook liever niet over meditatie, maar over concentratie.

Het woord concentratie geeft veel beter aan wat mindfulness is. Door je te concentreren op je gedachten, je

gevoelens en je lichaam, leer je heel veel over jezelf. Je kunt hierdoor de manier waarop je op jouw omgeving

reageert veranderen. Door naar gedachten te luisteren krijg je inzicht in gewoonten. Je gedachten hebben weer een

grote invloed op emoties en op de beslissingen die je neemt.1 Verander jouw gedachten en je verandert jezelf!

Mindful testen

Hoe kan mindfulness jou helpen in je werk als tester? Het leven als testconsultant is vaak druk. Een werkdag begint

vroeg met in de auto stappen om een eind te rijden naar jouw werk. Kun jij je nog herinneren hoe dat vanochtend

ging? Wat je onderweg hebt gezien of gehoord? Waarschijnlijk niet, je hebt de hele weg op een soort van

automatische piloot gereden. Deze automatische piloot gebruiken we eigenlijk constant. Werkdagen vliegen voorbij,

zonder dat je achteraf nog precies weet wat je hebt gedaan. De automatische piloot heeft invloed op onze beleving

van en reacties op onze omgeving. Je hebt een bepaalde test al zo vaak gedaan, dat je bij een volgende oplevering

dezelfde handelingen weer uitvoert zonder echt na te denken. Of je luistert maar half naar die collega die in jouw

ogen altijd zo zeurt, en misschien vandaag wel een goed punt heeft. Mindfulness leert je om met een open houding

naar de dingen te kijken, zoals ze op dat moment gebeuren. Dit betekent niet dat je al jouw ervaring als tester niet

meer kunt gebruiken. Je laat je alleen niet meer leiden door de automatische piloot en gaat de situatie bekijken

zoals deze nu is, zonder vooroordelen. Het is mogelijk veel objectiever naar een situatie te kijken. Je kijkt naar de

zaken met een ‘beginners mind’, open voor alle mogelijkheden. Vanuit die houding kun je vervolgens natuurlijk wel

jouw ervaring en testkennis gebruiken om de juiste oplossing te zoeken voor de situatie.

1 Uit: De kleine Mindfulness voor Dummies, Shamash Alidina, BBNC Uitgevers, 2012.

Pagina 5

Een eerste stap om dit te bereiken is inzicht te krijgen in hoe hectisch en automatisch je eigenlijk door het leven

gaat. Probeer tijdens die rit naar het werk eens op de omgeving te letten en op je medeweggebruikers; niet constant

met jouw gedachten af te dwalen naar iets anders. Dat is vaak best lastig. Hier komt concentratie aan bod. Je leert

hierdoor jezelf en jouw gedachtenpatroon steeds beter kennen. Daardoor kun je bijvoorbeeld beter luisteren. Eerst

goed luisteren, zonder dat jouw hoofd aan de haal gaat met de eerste indruk van wat je hoort, waardoor je de rest

van het verhaal eigenlijk niet meer mee krijgt.

Zoals je jouw gedachten kunt leren kennen met behulp van concentratie, kun je ook jouw gevoelens en emoties

bekijken. Je kunt leren afstand te nemen van deze gevoelens en ze te accepteren, zonder dat je er iets mee doet.

Zo kun je besluiten het vervelende gevoel dat een (in jouw ogen) irritante collega je geeft, niet mee te laten spelen

in jouw communicatie met deze collega. Hierdoor word je objectiever en waarschijnlijk een prettiger collega om mee

samen te werken.

Als laatste richt de mindfulness-concentratie zich op jouw lichaam. Je leert meer naar je lichaam te luisteren. Waarom

eet je die pot dropjes die naast je staat eigenlijk leeg? Je lichaam heeft al een tijdje geleden aangegeven dat je

genoeg dropjes hebt gehad. Deze signalen heb je echter, in gedachten of werk verzonken, genegeerd. En nu ben je

misselijk! Nu is dat met een pot dropjes nog niet zo erg, maar op dezelfde manier negeren we signalen van ons

lichaam die ons voor ernstiger zaken waarschuwen: dat we te hard werken, of te veel hooi op onze vork nemen.

Ook het onderbuikgevoel van een ‘slechte’ beslissing ga je steeds beter herkennen. Als je deze signalen tijdig

waarneemt, kun je er nog iets aan doen voordat het te laat is. Een niet gestreste tester is een betere tester.

Hoe het werkt

Hoe werkt dat dan, mindfulness? Kort gezegd verenigt mindfulnesstraining oosters inzicht met westerse

psychologische methoden. Het is inmiddels een vertrouwde benadering in Nederland, gebaseerd op resultaten van

wetenschappelijk onderzoek. Een klein stukje geschiedenis: De Amerikaan John Kabat Zinn wordt gezien als de

‘grondlegger’ van mindfulness in het Westen. Hij zag in dat onze waarneming wordt gekleurd door onze oordelen

over wat er op dit moment gebeurt en we verliezen onszelf in dagdromen en fantasieën over het verleden en de

toekomst. We identificeren ons met de inhoud van onze gedachten en beschouwen onze gedachten als een accurate

weergave van de werkelijkheid. We hechten ons aan positieve ervaringen en proberen aversieve ervaringen te

vermijden of te verwijderen. (Brown et al., 2007a; Hayes & Plumb, 2007) .

Pagina 6

Kabat Zinn was eind jaren zeventig moleculair bioloog aan de universiteit van Massachusetts. Hij deed zelf aan

meditatie en dacht dat de technieken die hij leerde van waarde konden zijn bij chronisch zieke patiënten die

‘uitbehandeld’ waren. Hij begon hiermee te experimenteren en boekte resultaten. Patiënten die aan mindfulness

deden, konden beter omgaan met hun ziekte, hadden minder pijn en waren minder depressief. Inmiddels wordt

mindfulness ook op vele andere manieren ingezet, zoals bij gedetineerden, in het zakenleven en op vele plaatsen in

de gezondheidszorg.

Over mindfulness zijn vele boeken geschreven en er is veel onderzoek naar gedaan. Een paar omschrijvingen2:

Mindfulness is ‘de open aandacht met betrekking tot het lichaam, gevoelens, gedachten, zintuiglijke

prikkelingen en de emotionele gesteldheid in het hier-en-nu’ (Koster, 1999, p. 32).

Mindfulness is het helder gewaarzijn van wat er op ieder moment gebeurt (Goldstein & Kornfield, 2001).

Het is ‘een vorm van observeren die open is, zonder oordelen, objectief, met onverdeelde aandacht. Zonder dat

wat zich in je bewustzijn voordoet te manipuleren, proberen weg te krijgen of vast te houden of je er mee te

identificeren’ (Tinge, 2005, p. 253).

Mindfulness

Kort en krachtig leer je door mindfulness te leven en werken:

… met opmerkzaamheid; om opmerkzaam te zijn, moet je letten op datgene waarop je vindt dat je moet letten.

… zonder directe reactie; normaal gesproken reageer je automatisch op een gebeurtenis op basis van

ervaringen uit het verleden. Mindfulness stimuleert je om je ervaringen te beantwoorden en niet om op je

gedachten te reageren.

… zonder oordeel; door niet te oordelen, kun je de zaken zien zoals ze zijn en niet door de bril van je

persoonlijke ervaringen.

… in dit moment; je moet je bewust zijn van zaken zoals ze zijn op dit moment.

… met openhartigheid; mindfulness speelt niet alleen in op jouw gedachten, maar ook op jouw gevoel. Met

openhartigheid breng je ook een gevoel van vriendelijkheid en medeleven mee in jouw ervaringen.

Mindfulness is eigenlijk oude wijn in nieuwe zakken. Maar dan wel eeuwenoude wijn! Al duizenden jaren wordt

meditatie in het Oosten beoefend. Mindfulness maakt deze eeuwenoude wijsheid toegankelijk voor ons nuchtere

Westerlingen. Met het aanleren van een paar basisprincipes merk je al verschil in jouw denken en doen, waardoor

je een betere en gelukkiger tester wordt!

2 Uit: Mindfulness: Wat is het? Hoe werkt het? Waartoe dient het? Chris van de Bospoort, Radboud

Universiteit Nijmegen, 2008

Pagina 7

Mijn ervaringen met een bughunt

Door Rob van Steenbergen ● rob@chickenwings.nl @rvansteenbergen

Een bughunt? Wat is dat, waar is het voor en hoe voer je dat uit? Dit zijn vragen die

wellicht gelijk bij je naar boven komen. Gaan we jagen? Nou, inderdaad. Een bughunt is

een korte jacht op bugs! In dit verhaal mijn ervaringen met een bughunt binnen het bedrijf

ThiemeMeulenhoff en wat lessons learned.

Er zijn diverse testsoorten voor het opsporen van verschillende soorten bugs. Een

performancetest voer je uit om informatie te krijgen over de grenzen van een systeem.

Met testsoorten als usability- en securitytesten krijg je andere informatie. Ook kan je kiezen voor bepaalde

testtechnieken om informatie in te winnen vanuit een ander perspectief. Met een grenswaardeanalyse zoek je

bijvoorbeeld de grenzen op van de verwerking van data en met een techniek als ‘ik zet mijn schoen op het

toetsenbord’ kan je een soort van stresstest uitvoeren.

In mijn huidige project heb ik de ‘bughunt’ geïntroduceerd, waarmee je bugs kan vinden waar je niet eerder aan

gedacht had. Dit omdat de software tijdens de bughunt vanuit verschillende perspectieven wordt bekeken, door

mensen die samenwerken. Voor een bughunt nodig je diverse mensen van verschillende disciplines uit. Doordat je

de mensen verdeelt in teams, kun je bijvoorbeeld een programmeur bij iemand van sales zetten en iemand met

inhoudelijke kennis bij een architect of een beheerder. Een mooie mix van mensen die samen discussiëren en de

software uitproberen, dit geeft goede inzichten en brengt onverwachte nieuwe bugs aan het licht. En het is ook leuk

om te doen! Teams gaan op jacht naar bugs in een wedstrijd setting. Het team met de meeste bugs wint een prijs!

Dit motiveert iedereen om z’n best te doen.

Context beschrijving van het project

We maken met een Scrum-team bij ThiemeMeulenhoff een educatieve applicatie voor het voortgezet onderwijs in

Nederland. De applicatie bestaat uit twee belangrijke onderdelen, de software die de functionaliteit biedt en het

lesmateriaal (de content). De software bevat educatieve didactische concepten, waarbij de leerling wordt

gestimuleerd om te leren en daarnaast evaluatiefunctionaliteit voor de docent.

Het ontwikkelteam bestaat uit zes personen, front-end, back-end, javascript, testen, een Product Owner en een

Scrum-master. We worden ondersteund door tijdelijke teamleden, zoals interactie-ontwerpers. Het project loopt nu

elf maanden. Met onze bughunt zijn we in de eindfase van de eerste versie voor livegang voor het nieuwe schooljaar.

Voorbereidingen

Receptiebellen

Als men een bug heeft gevonden, kan men de scheidsrechter roepen door de bel aan te

tikken. Een receptiebel wordt ook gehoord door de andere teams en helpt bij de motivatie.

Uitnodigingen versturen

Ik had aardig wat mensen uitgenodigd, ongeveer dertig. Het was vakantietijd, dus ik

verwachtte wel wat minder mensen en ongeveer de helft kwam opdagen. Dit aantal was

voldoende om vier teams samen te stellen.

Pagina 8

De teams samenstellen

Van tevoren had ik de teams al samengesteld, zodat ik een goede mix kon maken van verschillende disciplines.

Agenda en presentatie

De bughunt bestaat uit drie onderdelen: de briefing, het testen en de prijsuitreiking (debriefing). In de briefing gaf

ik een presentatie over de reden van de bughunt en hoe dit past binnen de teststrategie. Verder werden de regels

uitgelegd en de nodige praktische informatie gedeeld. Het benadrukken van de te winnen prijzen is ook belangrijk.

Motiveer!

Charters maken

Charters zijn testdoelen waar de testen zich op kunnen richten. Bijvoorbeeld: het onderzoeken van externe links om

te bekijken of er geen gebroken links zijn en de juiste links op de juiste plaatsen staan. Deze lijst had ik gemaakt

op basis van productrisico’s die tijdens het project zijn geïnventariseerd.

Hoe schrijf je een bug

De uitleg hierover heb ik van tevoren opgeschreven, omdat niet

iedereen weet hoe je een goede beschrijving maakt. Tevens had

ik formulieren gemaakt, zodat men deze met pen kon invullen.

Teamnummer bordjes

Handig als je rondloopt en punten uitdeelt. De bordjes lagen op

de tafels zodat je gelijk kon zien aan welk teamnummer je punten

kon geven.

De coach en scheidsrechter

Het is goed om twee rollen te hebben. In ons geval werd de Scrum-master de scheidsrechter en ik als tester de

coach. De rol van de scheidsrechter is om de bugs te beoordelen; is het een nieuwe bug en goed beschreven? Alle

overige vragen gaan naar de coach.

Briefing

Tijdens de briefing heb ik het proces uitgelegd en hebben we

de teams ingedeeld aan de hand van de mensen die er waren.

Vier teams deden mee in de bughunt: Twee teams met

diverse tablets en andere devices en twee ‘klasjes’ met een

docent en leerlingen. De bordjes, devices en diverse

formulieren had ik klaargelegd op de plaatsen waar de teams

zouden gaan zitten en het was simpelweg iedereen verwijzen

naar de plaatsen. Deze briefing heb ik zo kort mogelijk

gehouden, tien minuten maximaal, want het gaat uiteindelijk

om de tijd die overblijft voor het testen.

Pagina 9

De bughunt

Toen de teams aan de slag gingen, volgden al snel de eerste belletjes en kon de scheidsrechter heen en weer gaan

rennen om de bugs te beoordelen en punten uit te delen. In het begin kwamen er aardig wat belletjes. Later werd

dat wat rustiger, alhoewel tegen het einde er toch weer meer bugs werden gevonden. Als coach liep ik rond en hielp

bij problemen, ruilde bijvoorbeeld devices uit tussen teams als deze niet gebruikt werden. Als het druk werd, hielp

ik mee als interim scheidsrechter om bugs te beoordelen.

De software die wij hebben, ontsluit leermateriaal voor scholen, dus bevat veel inhoudelijk lesstof. We hadden

afgesproken dat een probleem dat gevonden werd in

deze content, ook als bug werd beschouwd.

Debriefing

De reacties van de bughunters: ‘Interessant’, ‘Leuk

om eens echt de software te bedienen in plaats van

alleen de demo’s’, ‘vanuit gebruikersperspectief’ en

‘leerzaam’. Het teamgevoel en de bughunt werden als

positief beschouwd en het gaf mensen meer inzicht in

de software. Niet iedereen had de software goed

kunnen bekijken en vooral tijdens sprintdemo’s

gezien, dus dit hielp om meer inzicht te krijgen. De

charterlijst is niet gebruikt om als testideeënlijst te

gebruiken tijdens de testen. De hunters waren druk bezig met hun onderzoek en zijn op een vrije manier aan het

testen geslagen. De scheidsrechter reikte aan het einde de prijs uit aan het team met de meeste bevindingen. Er

was ook een prijs voor de beste bevinding.

Conclusie en ideeën

Simpel houden

Score: eerst hanteerde ik een verdeling van één tot drie punten, van lichte tot zware bugs, maar we hebben toch

gekozen voor één punt per onbekende bug. Zo werden discussies vermeden en bleef het simpel voor de

scheidsrechter. Dat bleek een goede zet.

Een online bug-formulier of bevindingendatabase gebruiken is een goed idee, maar het moet wel makkelijk te

gebruiken zijn. Iedereen zal de beschikking moeten hebben over een computer. In dit geval vonden wij dat mailen

of het handmatig invullen op papier goed genoeg was. Dit hadden we verder niet voorbereid, maar had het invoeren

wel wat gestructureerder en duidelijker gemaakt. Bugs waren niet op de beste manier ingevoerd, er was veel nawerk

om de bugs uit te zoeken en te reproduceren.

Sturing met testcharters

Het is goed om wat sturing te geven via charters en deze te verdelen onder de teams. Dit helpt wat meer focus te

krijgen en eventuele niet belangrijke onderdelen te vermijden. Dit zal ook helpen met het voorkomen van het melden

van dubbele bugs door verschillende teams.

Pagina 10

Usability

Mensen die nog nooit met het product hadden gewerkt, konden

meteen aan de slag. De usability bleek dus goed! De bughunt is erg

geschikt om dit onderdeel te testen en hier naderhand vragen over

te stellen in de debriefing.

Software- en contentbugs

Contentbugs waren achteraf niet zo belangrijk voor de mensen die

met deze bughunt bezig waren. Men was nog druk bezig met de

inhoud. Dit zal ik bij de volgende keer beter voorbereiden door dit te

bespreken van tevoren met de contentvoorbereiders. Een tip: denk

goed na over de onderdelen van de software waarvan resultaten ook echt nodig zijn op dat moment. Dit door te

sturen via charters, testdoelen, testideeën of testopdrachten. Het is belangrijk om dit in de briefing goed te

bespreken, zodat hunters niet los gaan op allerlei bijzaken.

Onbekende bugs

De bugs die we zelf niet hadden kunnen bedenken, kwamen vooral van mensen die nog nauwelijks met het product

hadden gewerkt. Een voorbeeld is het niet verschijnen van een ‘sluit’-knop. Voor ons vanzelfsprekend dat je verder

kan gaan via een menukeuze, maar voor de kersverse gebruiker een plek in de software waar zij vastliep en niet

meer wist wat ze moest doen.

De twee rollen: coach en scheidsrechter

De scheidsrechter kan het te druk krijgen. De coach laten invallen als scheidsrechter is achteraf toch niet zo goede

keuze. Een bug die al is gevonden door team één en vervolgens door team twee wordt gemeld kan het best door

één persoon worden beoordeeld. Ik denk dat we hier en daar toch dubbele punten hebben uitgedeeld omdat ik de

rol van scheidsrechter af en toe invulde.

Scheidsrechter Marco Stuijvenberg en Rob als coach bij het bespreken van de scores

Pagina 11

Devices

Om discussie te voorkomen is het verstandig om alleen ondersteunde devices te laten testen, omdat je bij onbekende

devices niet zeker weet of een gevonden bug nu echt een waardevolle bug is tijdens de bughunt. Er is tijdens het

testen niet veel tijd voor onderzoek.

Tijd

Het gehele proces was binnen een uur uitgevoerd. Oorspronkelijk plande ik anderhalf uur, maar ik had mij vergist

in de tijd. De hunters vonden het te kort, dus volgende keer plan ik weer anderhalf uur. Eigenlijk verwacht ik wel

dezelfde reacties. Het is leuk om te doen, dus dan maakt de tijd uiteindelijk niet uit.

Verder

De belletjes werken prima. De prijsuitreiking was een succes, dus dit moet je altijd doen. Wij hadden overigens de

bekende ‘Celebrations’ chocoladedoosjes als prijzen. Tijdens de bughunt werden er ijsjes uitgedeeld. Ook iets wat

helpt bij de motivatie. We hebben in dit uurtje tien tot vijftien interessante nieuwe bugs ontdekt buiten de gevonden

contentbugs. Een geslaagde bughunt dus en zeker iets wat ik nog vaak wil doen als onderdeel van mijn teststrategie.

Referentie

Een presentatie die ik heb gebruikt is: ANZTB Bug-Hunting with Klaus Olsen - Softwaretest_dk v1_0. Hierin staan

een aantal vormen beschreven en nog meer tips in om je te helpen bij je eigen bughunt.

Pagina 12

HOE LEER JE WERKEN MET EEN TESTTOOL?

Door Eibert Dijkgraaf ● eibert.dijkgraaf@praegus.nl @EibertD

Op Twitter waart een Dilbert-bericht rond: ‘We spent $500k on SharePoint and people

still aren’t collaborating!’. Het geeft de wanhoop aan van de budgethouder die merkt

dat de ingezette tools het beoogde effect missen. Hoe herkenbaar is dit als het gaat

om testtooling?

Regelmatig kom ik het tegen. Prijzige testtools die slechts een geringe bijdrage

leveren aan het geheel van het testen. Het betreft niet alleen de uitdagingen bij

geautomatiseerde testen. Ook de zogeheten testmanagementtooling (zoals

bijvoorbeeld HP Quality Center of ALM-suite of Rational TestManager) heeft hier last

van. Deze tools bieden een scala aan mogelijkheden om je testware optimaal te beheren, voortgang te bewaken en

rapportages over de testresultaten te creëren. Bij de uitgebreidere varianten gooi je aan de voorkant meteen de

requirements erbij en je hebt volledig zicht op je dekking, inclusief een mooie requirements traceability matrix.

En dan komt daar de praktijk. De tool wordt ‘gedegradeerd’ tot een bevindingenbeheertool. De rapportage-

mogelijkheden worden maar mondjesmaat benut. Een kritische blik naar de ingevoerde data doet je soms berusten,

omdat de kwaliteit van de ingevoerde gegevens zelf ook te wensen over laat. Hoe komt het toch dat het gebruik van

dit type tooling vaak te wensen over laat?

Uit eigen ervaring observeer ik enkele gebruikers.

De ontkenner: gelooft niet in de meerwaarde van de tool. Het kost allemaal enorm veel tijd om de data in te

voeren. Het is het zoveelste managementfeestje en ook dit zal wel overwaaien.

De angsthaas: heeft de tool bekeken. Dat wil zeggen, na enig uitstel. Want het is allemaal erg ingewikkeld. Een

cursus heeft hij nodig. Maar helaas, daarna lukte het allemaal nog niet. Trouwens, het werkt allemaal prima met

Excel en Word.

De perfectionist: ziet de meerwaarde van de tool en gaat er voortvarend mee aan de slag. Echter, hij bemerkt

al gauw wat lastige zaken. Er zijn dingen die niet lukken en de tool doet soms rare dingen, die hij graag anders

had gewild. Teleurstelling dreigt de overhand te krijgen en zijn omgeving wordt bepalend of hij het vol gaat

houden of terugvalt.

De enthousiasteling: ziet de mogelijkheden en is bereid om de lastige hobbels te nemen. Het resultaat komt er

en aanvullende mogelijkheden worden uitgezocht en zo wordt het gebruik aangevuld.

Leerstijlen

Als je betrokken bent bij toolimplementaties, moet je voor een diverse groep van beoogde gebruikers het juiste

lesmateriaal maken om tot optimale prestaties te komen. Maar hoe leert een gebruiker om te gaan met de tool?

Zoals uit bovenstaande typering mag blijken zal de één succesvol zijn zonder een training, terwijl bij de ander zelfs

een overdaad aan diverse trainingsvormen nog niet voldoende zal zijn om tot het beoogde resultaat te komen.

Het is interessant om in dat soort trajecten te kijken naar leerstijlen en die te herkennen bij de gebruikers. De

leerstijlen van Kolb (zie figuur) tonen aan dat het trainingsprogramma een divers aanbod moet omvatten. Een

Beslisser (of Toepasser) en een Doener willen graag aan de slag met oefeningen, terwijl een Dromer (of Waarnemer)

en een Denker eerst de nodige uitleg willen krijgen.

Pagina 13

De leerstijlen hebben als valkuil dat er te weinig aandacht is voor de acceptatiegraad. Zoals hierboven geschetst

hoeft niet elke beoogde gebruiker al in de ‘leermodus’ te zitten. Dan moet er aandacht zijn voor dieperliggende

weerstanden. Is men voldoende overtuigd van de toegevoegde waarde (voor zichzelf of voor anderen)? Is er sprake

van angst voor het onbekende? Wil men geen afstand doen van al het moois dat door de jaren heen is opgeslagen?

Gebruiksvriendelijkheid

Maar als het leren omgaan met de tool problematisch blijft, dan heeft de toolleverancier daar gelukkig een oplossing

voor: de gebruiksvriendelijke tool. Je kent het wel: ‘deze tool neemt u op geheel intuïtieve wijze mee in de organische

workflow om zo te komen tot de meest optimale prestaties met een nimmer eerder ervaren user experience.’

Kortom, een gebruiksvriendelijke tool werkt intuïtief en leidt daardoor tot een kleinere behoefte aan training en

bevordert het juiste gebruik. Dit strookt echter niet met mijn ervaringen. Wat zie ik in de praktijk? De meest fancy

en geavanceerde tools zijn dezelfde tools die het slechtst worden gebruikt. Gebruikers blijken slecht op de hoogte

van alle mogelijkheden, maar zijn door de minimale training ook niet goed in staat om hun eigen beperkte gebruik

te optimaliseren. Een krachtige tool wordt daardoor maar matig gebruikt.

Daartegenover zie ik gebruikers met OpenSource tooling aan de slag gaan. Deze tools blinken vaak niet uit in

gebruikersvriendelijkheid. De handleidingen zijn matig, laat staan dat er mooie (dure) trainingsprogramma’s

bestaan. Toch zijn de gebruikers van deze tools vaak goed in staat om de tools op de juiste manier te gebruiken en

zelfs aanvullende oplossingen erbij te creëren.

Hoe valt dat nou te verklaren? Ik heb het vermoeden dat de verklaring staat in het boek The Shallows van Nicholas

Carr. In dit boek beschrijft hij het effect van internet op ons menselijk brein. In het menselijk bestaan zijn er twee

cruciale momenten. De uitvinding van de boekdrukkunst heeft ertoe geleid dat mensen zich konden verdiepen in

een onderwerp. Neurofysiologisch onderzoek heeft aangetoond dat onze hersenstructuur daardoor is gewijzigd. Het

tweede cruciale moment is het toenemend gebruik van internet. Van verdieping gaan we nu naar verbreding, doch

oppervlakkig. We worden overspoeld met een overload aan informatie, waar we ons echter niet meer in graven,

maar waar we overheen hoppen. Klikkend van blog naar blog, via een URL-letje hier en een hyperlinkje daar.

Inmiddels is ook wetenschappelijk aangetoond dat deze vorm van informatievergaring opnieuw zijn effect heeft

Pagina 14

op onze hersenstructuur. De wijze van informatieconsumptie verandert en daarmee wordt ook ons leervermogen

beïnvloed.

Vanuit bovenstaande beschrijving komt hij tot het punt waar hij beschrijft: ‘The more that people depended on

explicit guidance from software programs, the less engaged they were in the task and the less they ended up

learning.’ Iets verderop bondig weergegeven als: ‘The brighter the software, the dimmer the user.’

Voor mij vormt bovenstaande ontdekking een verklaring voor het beperkte succes waar de uitgebreide

testmanagementtools mee te maken hebben. Het intuïtieve karakter van de tool vormt zelf een belemmering om tot

verdieping te komen in het lesmateriaal of de handleiding, met als gevolg dat de mogelijkheden maar sub-optimaal

benut blijven. Met deze verklaring in het achterhoofd wordt de uitdaging om tot een succesvol implementatietraject

te komen er echter niet gemakkelijker op. Wanneer ga jij de aangereikte tools optimaal gebruiken en wat heb je

daar voor nodig?

CARTOON

Door Gerard Numan ● gerard.numan@polteq.com

Pagina 15

REIS OM DE WERELD IN ÉÉN DAG

Door Ijsbrand Kaper ● ikaper@vxcompany.com @testbats

De afgelopen jaren heb ik redelijk wat landen mogen zien. Studiereizen naar

Zuid-Afrika en de Verenigde Staten en vakanties in onder meer Vietnam en

Suriname. Dit zijn fantastische locaties voor iemand die ervan houdt om

nieuwe omgevingen te verkennen en mensen en culturen beter te leren

kennen. Als lead-tester voor crowdtestprojecten reis ik ook regelmatig, maar

dan vanuit mijn kantoor in Baarn. In deze rol beoordeel ik de kwaliteit van

opgeleverde bevindingen door de community van softwaretesters en

communiceer hierover met zowel klanten als testers vanuit de hele wereld.

Crowdtesten

In het kort is crowdtesten het aanbieden van testtaken aan een community van softwaretesters. Dit gebeurt via een

portaal, vanwaaruit de testopdrachten worden verstrekt aan de softwaretesters en waarin de resultaten worden

geregistreerd. Testers die zich aanmelden voor een dergelijk platform, worden uitgenodigd voor testopdrachten waar

zij voor in aanmerking komen op basis van een profiel en de devices waarop ze kunnen testen. Crowdtesten biedt

aan klanten de mogelijkheid om snel meer testvolume aan te spreken en om specifieke testvormen uit te voeren,

zoals multi-device en multi-platformtesten.

Internationale dienstvorm

Natuurlijk tref ik de testers waarmee ik werk niet fysiek en in hun eigen context. Dat is een gemis, maar het is erg

interessant om vanuit het perspectief van een testproject te zien hoe testers uit verschillende landen en culturen

verschillend acteren en communiceren. Ik loop regelmatig tegen situaties aan die ik vooraf niet had voorzien. Een

voorbeeld van het laatste was een tester die me benaderde vanuit Egypte. Deze tester was zeer actief voor een

project voor een webshop en had hiervoor ook een leuk bedrag bij elkaar getest. Echter, bij het overboeken van de

betalingen bleek dat het niet mogelijk is om online betalingen te kunnen doen naar sommige Egyptische accounts.

In dit geval was het betreffende betaalsysteem nog niet beschikbaar voor een aantal landen. Gelukkig zal in het

najaar dit probleem verholpen zijn en kunnen we de bedragen alsnog uitkeren.

Verschillende culturen

Testers uit verschillende landen gedragen zich anders, omdat hun cultuur en leefomgeving anders is. Zo zijn

Nederlandse crowdtesters over het algemeen eerder gemotiveerd voor het crowdtesten vanuit een professionele

wens om een extra dimensie te geven aan hun vakgebied. Als crowdtester kom je namelijk in korte tijd in aanraking

met veel verschillende soorten testprojecten, elk met een specifieke uitdaging. Daarnaast zijn Nederlandse testers

een stuk minder afhankelijk van de geboden vergoedingen voor testwerkzaamheden. Dit heeft als gevolg dat

Nederlandse testers over het algemeen langer doen over het accepteren van een opdracht en ook kortere

aaneengesloten perioden intensief testen. Als er bij wijze van spreken een goede film op tv is, zal een Nederlandse

tester eerder een testronde aan zich laten voorbijgaan. Daarentegen is het gemiddelde opleidingsniveau van

Nederlandse testers weer erg goed te noemen, gekeken naar de kwaliteit van de bevindingen.

Testers uit bijvoorbeeld zuidelijk Azië daarentegen zijn veel meer gemotiveerd door de financiële vergoeding die

gegeven wordt voor het testwerk. Dit is duidelijk te merken aan het fanatisme waarmee opdrachten worden

uitgevoerd en de snelheid waarbij ze projecten accepteren. Als ik zie dat bij sommige projecten al enkele minuten

Pagina 16

na het neerzetten van een nieuwe opdracht de eerste bevindingen binnenkomen, stel ik mezelf onwillekeurig de

persoon voor die de hele dag de F5-toets ingedrukt houdt om als eerste een project te accepteren. Je voelt je als

lead-tester verplicht om deze mensen zo goed mogelijk te helpen goed werk af te leveren, omdat je merkt dat voor

deze personen iedere euro (of roepi) telt.

Parels en cheaters

In ieder land is ook een aantal testers te vinden die je gerust de pareltjes uit de community kunt noemen. Dit zijn

de testers die veel projecten doen en duidelijk het klappen van de zweep kennen. Zo heb ik een tester uit Argentinië

die vrijwel altijd meedoet aan onze projecten en vrijwel geen fouten maakt. Ik mis hem bijna als hij een poos niet

meedoet aan testtrajecten ondanks dat ik hem totaal niet ken. Dit zijn de dragers van de community, die in zekere

zin ook een voorbeeldfunctie vervullen voor andere testers.

Ook zijn er ook in elk land testers die proberen het systeem naar hun hand te zetten. Dit is inherent aan het

businessmodel van crowdtesting. Ik noem dergelijk gedrag de ‘cheat-factor’. Deze testers proberen op creatieve

manieren zoveel mogelijk bevindingen in te dienen en goed te laten keuren, om zo het bedrag dat uitbetaald wordt

kunstmatig te vergroten. Bijvoorbeeld door eenzelfde bevinding vanuit zoveel mogelijk perspectieven te beschrijven

in meerdere bevindingen. Dit spel tussen tester en lead-tester is er een van geven en nemen wat hoort bij

crowdtesten. En in zekere zin dragen de cheaters ook bij aan het verder volwassen maken van deze dienstvorm.

Diversiteit

Uiteraard neig ik in dit artikel een beetje naar generalisatie van groepen. Dit is niet de bedoeling. In ieder land en

in iedere regio in de wereld werken testers die goed of minder goed, snel of minder snel en nauwkeurig of minder

nauwkeurig zijn. Er zijn echter gemiddeld genomen

wel verschillen op te merken tussen gebieden in de

wereld. Dit is een kracht die ik benut door altijd

zoveel mogelijk diversiteit te creëren in opbouw van

testpanels voor mijn projecten.

Veel contacten

Crowdtesten is een internationale dienstvorm en ik

vind het fantastisch om te maken te hebben met de

grote diversiteit aan testprofessionals die er is. Het

spel spelen om testers gemotiveerd en betrokken te

houden om kwalitatief goed werk te leveren is erg

leerzaam. Daarnaast ben ik ervan overtuigd dat crowdtesten een mooie toevoeging is aan de testwereld. Het kan

vaker toegepast worden dan menigeen denkt! Het mooiste blijft echter dat je, ondanks dat je te maken hebt met

een community van duizenden testprofessionals, toch met bepaalde personen een leuke werkrelatie kunt opbouwen.

Ik houd er vanuit mijn kantoortje in Baarn wellicht meer internationale contacten aan over dan van mijn reizen over

de wereld. En wellicht stiekem ooit eens een leuk vakantieadres…

Pagina 17

TESTWARE GENEREREN MET SEPIOLA

Door Erik Skoda ● erik@esnet.nl

Ooit moest ik een webapplicatie gebruiken voor het invoeren van een behoorlijke

hoeveelheid kilometerregistratie. De kilometerstanden had ik al in een Excel-sheet, de data

lieten zich niet zomaar importeren in de webapplicatie. Het beloofde een saaie, tijdrovende

en foutgevoelige klus te worden. Op dat moment had ik graag een tool gehad die de data

vanuit een Excel-sheet leest en deze omzet in Selenium scripts, waarmee ik de data met

één druk op de knop kon invoeren. Voor het genereren van testdata had ik ook meermalen

behoefte aan een dergelijke tool. Een naam had ik namelijk al bedacht: ’Sepiola’, vernoemd

naar een kleine inktvissoort die ook in Nederlandse zoute wateren te vinden is. Aangezien ik verwachtte dat er al

zoiets beschikbaar zou zijn, had ik de realisatie hiervan in eerste instantie uitgesteld.

Bij mijn inzet bij PharmaPartners ontstond opnieuw de behoefte om grote datasets geautomatiseerd te verwerken;

in eerste instantie voor testdoeleinden ten behoeve van AORTA: de nationale zorginfrastructuur voor elektronische

uitwisseling van patiëntgegevens. Binnen PharmaPartners zijn voor Aorta vele middelen ingezet, onder andere

ketentests en kwalificaties met, voor en door NICTIZ: Nationaal ICT instituut in de Zorg. Daarnaast hebben we de

tool soapUI gebruikt voor het simuleren van gegevensuitwisseling tussen zorgverleners. De gegevensuitwisseling

gaat volgens het HL7-format. De HL7-berichten kennen een complexe structuur en tientallen parameters waarvan

de namen veelal op elkaar lijken.

Gedurende het project werd het voor mij steeds duidelijker dat een oplossing zoals ‘Sepiola’, echt nodig was. De

beschikbaarheid van het tool zou het behalen van een stevige testdiepgang gemakkelijker maken. Om deze reden

ben ik in eigen tijd begonnen met het ontwikkelen van het tool. De nadruk bij de ontwikkeling lag voor mij op

eenvoud, zowel qua opbouw als bediening. De nadruk qua tijdsindeling verschoof van het editen van HL7-berichten

naar het variëren van testgevallen. In dezelfde tijd konden we nu ook veel meer variatie bereiken.

Aangezien het tool zelf niets anders doet dan data uit een Excel-sheet combineren met platte tekst, kan deze ook

prima voor andere doeleinden gebruikt worden, bijvoorbeeld voor het genereren van EDIFACT bestanden of scripts.

Zo heb ik het tool ook gebruikt voor het genereren van Selenium scripts om geautomatiseerd enkele tientallen Oracle

Weblogic parameters in de gewenste setting te krijgen voor de testopstelling.

Binnen PharmaPartners is het tool gedeeld met collega's van het Testgilde, echter was de broncode nog afgeschermd.

Het tool is nu als open source oplossing gratis te downloaden via de site esnet.nl. De broncode is niet afgeschermd.

Het tool bevat zowel een Engels- als Nederlandstalige handleiding (het tabblad ‘Lees mij’) en bevat een

minimalistisch voorbeeld om het werkingsprincipe te demonstreren. Veel plezier!

Pagina 18

SERIOUS GAMES VOOR TESTERS

Door Cesario Ramos ● cesario@agilix.nl en Pascal Dufour ● pascal@validate-it.nl

Voor het toepassen van ATDD met tools zoals FitNesse, Cucumber en

Robot Framework is het noodzakelijk om acceptatietesten te schrijven.

Deze acceptatietesten zijn een logisch vervolg op de user story. Om de

juiste functionaliteit juist te bouwen hebben we als team een geza-

menlijk beeld nodig van de user story.

Je gebruikt workshops (product backlog refinement meetings in

Scrum), zodat je hele team deelneemt aan het helder krijgen van de

wat-, waarom- en de hoe-vraag van de user stories. Tevens schrijf je

samen met de stakeholders nieuwe user stories in deze workshops.

Werken als een team samen met je stakeholders geeft je de volgende voordelen:

1. Het is waarschijnlijker dat je functionaliteit ontwikkelt die business value creëert. Door de nauwe samenwerking

ontdek je, waarom deze functionaliteit gemaakt dient te worden en welke business value hij vertegenwoordigt.

2. Je bent beter in staat om het juiste probleem op te lossen. Nadat het probleem van de klant helder is, kun je met

een veel betere oplossing komen.

3. Je mindset wijzigt van het vinden van fouten naar het voorkomen van fouten. Het vinden van fouten is immers

een verspilling.

4. Je bent in staat om helder op te schrijven wat we bedoelen met het succesvol ontwikkelen van een user story. Je

ontwikkelt alleen wat nodig is, niet meer of minder dan dat.

Requirements workshops zijn er niet alleen om een beter begrip te krijgen van wat er gemaakt dient te worden met

bijbehorende acceptatietesten, maar het maakt het mogelijk om als gehele team te testen. Het gaat namelijk om

die paar testcases die de kern van de story weergeven en dus niet om een uitputtende lijst van alle testgevallen.

Daar heb je immers nog voldoende tijd voor om die te uit te werken gedurende de volgende iteratie. Deze kerntest-

cases kunnen geautomatiseerd worden zodat ontwikkelaars en testers samen kunnen werken tijdens ontwikkeling.

Terwijl een developer bijvoorbeeld de kerntestcases aan het automatiseren is, kan een tester alvast meer testgeval-

len uitwerken. Nadat de kerntestcases geautomatiseerd zijn, is iedereen in staat om de testcases uit te bereiden of

te wijzigen.

Het gezamenlijk beeld van de stories maakt het ook mogelijk om gezamenlijk de manuele tests te definiëren, zoals

bijvoorbeeld exploratory test charters. En zoals je weet, is iedereen nu in staat om de exploratory test charters uit

te voeren zolang je een ervaren tester hebt die begeleidt.

Dit is allemaal interessant, maar hoe realiseer ik eigenlijk een succesvolle workshop? Welke stappen zijn er nodig,

welke serious games kunnen er gespeeld worden en hoe faciliteer ik de workshop? In dit artikel vertellen we je over

hoe wij de requirements workshops houden en hoe we serious games gebruiken.

Wat is een serious game?

Als je net bent zoals wij, dan heb je deelgenomen aan saaie meetings die ook nog eens niet productief waren en

waarschijnlijk gedomineerd werden door een paar collega’s. Je mocht verschijnen van het management om een paar

dingen te vertellen. De meetings hoeven niet zo te zijn. Je kunt game-mechanieken in al je meetings

Pagina 19

toevoegen, zodat ze niet alleen veel leuker zijn, maar ook veel productiever en met een beter resultaat. Een manier

om succesvolle meetings te hebben is door gebruik te maken van serious games.

Een serious game [1] is een game speciaal ontwikkeld om business problemen op te lossen. In een ‘normale’ game

is het doel te vermaken. In een serious game maak je gebruik van game-mechanieken, die net zoals bij een ‘normale’

game ervoor zorgen dat de beleving, betrokkenheid en creativiteit van mensen wordt aangesproken. Serious games

kun je uitstekend toepassen tijdens een requirements workshop waar eenieder vanuit zijn eigen invalshoek een

bijdrage levert om de gezamenlijke requirements en testcases scherp te krijgen.

Wat is een requirements workshop?

De doelstelling van een requirements workshop is het creëren en het helder krijgen van user stories voor het gehele

team. De discussie maakt duidelijk waarom moeten we deze user story maken, welk probleem de stories oplossen

en welke acceptatietesten nodig zijn voor het ontwikkelen en valideren van de user story.

De doelstelling voor een requirements workshop zou kunnen zijn:

1. We willen twee à drie voorbeelden van acceptatietesten hebben van elke user story;

2. We willen voor elke user story een exploratory test charter.

Onze requirements workshops duren tussen de één tot twee uur. Je kunt altijd stoppen als je eerder klaar bent,

maar dat gebeurt niet vaak dankzij Parkinson’s law [2]

Het probleem dat eerst aandacht behoeft, is het zeer goed begrijpen van de user story vanuit een bepaalde persona.

We moeten weten waarom deze persona deze behoefte heeft en welk probleem hij opgelost wil zien. Dit is een

requirement probleem. De te beantwoorden vraag is: ‘Welk probleem heeft de klant en waarom wil de klant het

opgelost hebben?’.

Een user story is ook een requirement waarvoor een oplossing ontworpen moet worden. Daarom moet de volgende

vraag beantwoord worden: ‘welke oplossing past het beste bij de wensen van de klant?’. De details van het ontwerp

worden niet beantwoord in de requirements workshop maar er wordt al wel erover nagedacht.

Uiteindelijk hebben we nog het testprobleem. De vragen die hiervoor beantwoord moeten worden zijn:

1. Hoe weten we dat de oplossing het probleem van de gebruiker oplost? Levert de nieuwe oplossing meer waarde

dan de vorige oplossing?

2. Hoe weten we dat we het juiste probleem hebben opgelost? Is het probleem dat we hebben opgelost ook het

probleem dat de klant wil dat we oplossen?

3. Hoe weten we dat we het probleem juist hebben opgelost? Hoe kwantificeren we succes en fout van de oplossing?

We zouden tests nodig kunnen hebben om antwoord op deze vragen te vinden.

Hoe faciliteer je een requirements workshop?

Er is een aantal zaken waar je rekening mee moet houden om succesvol een requirements workshop te faciliteren.

Allereerst moet je een doel hebben voor de requirements workshop. Het is zeer belangrijk om een doel te stellen

aan het begin van de requirements workshop om betrokkenheid te krijgen.

Vervolgens bediscussieer je de stappen van de requirements workshop zoals de agenda, wat gaan we doen en

wanneer we het doel hebben bereikt.

Pagina 20

Nadat het duidelijk is, spreken we de regels af van de requirements workshop. Hoe gaan we om met verstoring zoals

overgaande telefoons? Het interrumperen van elkaar wanneer we aan het woord zijn? Mogen we een e-mail lezen

tijdens de requirements workshop? Mocht het zijn dat je al vaker een requirements workshop met het team hebt

gedaan, herinner dan het team even aan de afgesproken regels en of ze er nog altijd achter staan.

Om creativiteit een boost te geven maken we gebruik van time boxing. Geef ook tijdig aan dat de tijd is verstreken

voor een onderwerp. Bijvoorbeeld elke tien tot vijftien minuten geef je aan hoever de tijd is verstreken, of we nog

genoeg tijd hebben en of we nog werken aan het belangrijkste punt.

Het gebruiken van een parking lot is zeer wenselijk. Als je vragen krijgt die niet relevant zijn of te veel tijd kosten,

dan zet je ze op de parking lot en behandel je ze aan de einde van de meeting nog kort.

Een game stappenplan voor een succesvolle requirements workshop

In de requirements workshop voor het vaststellen van de testcases wil je de volgende stappen volgen:

1. Introductie: leg uit wat het doel en de agenda is van de requirements workshop.

2. Begrijpen van de business value: de Product Owner legt een coherente set van user stories uit met een doel

(Sprint doel als je Scrum gebruikt) en relateert ze terug aan de business doelstellingen. Het team bediscussieerd

‘waarom doen we dit?’. In onze workshops gebruiken we impact maps [3] en de 5 Why’s [4].

3. Begrijpen van de klantwaarde: het team splitst zich op in teams en verdeelt de user stories. De subteams creëren

scenario’s van de huidige situatie van de persona’s zodat ze de situaties goed begrijpen waar de uitdaging ligt

voor de persona. Tevens creëren ze scenario’s van de situatie zoals die zal zijn als het probleem is opgelost. Op

deze manier begrijp je beter wat de voordelen zijn van de oplossing. Het team komt vervolgens weer bij elkaar

en bediscussieert de gecreëerde scenario’s met gehele team. The team bediscussieert ‘waarom wil de persona

dit?’. We doen dit door middel van een StoryBoard [5] en Pain Gain map [6].

4. Destilleren van de acceptatietesten: het team creëert de acceptatietesten voor de user stories. Afhankelijk van

de tools die je gebruikt, zijn het Gherkin specificaties [7], flow tables [8] of decisions tables [9]. Het team wordt

gesplitst in subteams en gaat aan de slag met de tabellen of de Gherkins specificatie in

Pagina 21

samenwerking met de Product Owner. Dit alles doen we op whiteboards, zodat het voor elk teamlid goed te

volgen is (gezamenlijk begrip)

5. Definiëren van exploratory test charters: identificeer risico’s om de exploratory test charters een doel te geven.

Nu het duidelijk is welke risico’s we willen mitigeren, kunnen we manuele testen bedenken door als team explo-

ratory test charters te definiëren. We doen risicoanalyse door bijvoorbeeld een impact matrix [10] en we kunnen

exploratory testing tours gebruiken om de charters te maken [11].

6. Afsluiting: een korte samenvatting en de laatste opmerkingen.

Het bovenstaande game stappenplan zou je kunnen gebruiken voor jouw requirements workshop. De games die we

genoemd hebben, zijn games die we vaak toepassen. Er zijn veel meer games die je kunt toepassen. Wij moedigen

je dan ook aan om verschillende games uit te proberen en te ervaren welke het beste werken in jouw specifieke

context.

Referenties

1. Serious game / innovation games http://www.innovationgames.com

2. Parkinson’s Law http://en.wikipedia.org/wiki/Parkinson's_law

3. Impact Mapping http://www.impactmapping.org

4. The 5 why’s http://www.gamestorming.com/games-for-problem-solving/the-5-whys/

5. Story board http://www.romanpichler.com/blog/agile-scenarios-and-storyboards/

6. Pain Gain map http://www.gamestorming.com/games-for-design/pain-gain-map/

7. Gherkin Language http://cukes.info/gherkin.html

8. Flow tables http://fitnesse.org/FitNesse.UserGuide.FixtureGallery.ImportantConcepts.FlowMode

9. Decision tables

http://fitnesse.org/FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.SliM.DecisionTable

10. Risk quadrants http://pascaldufour.wordpress.com/2013/11/19/user-story-risk-quadrants/

11. Testing tours http://michaeldkelly.com/blog/2005/9/20/touring-heuristic.html en

http://msdn.microsoft.com/en-us/library/jj620911.aspx#bkmk_tours

Pagina 22

HET TESTGEVAL - EEN EPISTEMOLOGISCHE DECONSTRUCTIE

Door Joep Schuurkes ● j19sch@gmail.com @j19sch

Als we over testen praten, dan hebben we het al snel over testgevallen. Vroeger met grote

vanzelfsprekendheid, ondertussen al iets minder. Vanuit de praktijk wordt namelijk

regelmatig de vraag gesteld: kunnen we niet beter testideeën gebruiken in plaats van

testgevallen? Naast die praktische benadering kun je testgevallen ook bekijken vanuit een

abstracter en meer filosofisch perspectief. Het gaat dan om de vraag: welke informatie zit er

wel en niet in een testgeval? En hoe draagt dit bij aan ons begrip over wat en hoe we aan

het testen zijn?

Testen is een informatieprobleem. We zijn op zoek naar bepaalde informatie, naar een

antwoord op de vraag: beantwoordt dit systeem aan de relevante expliciete en impliciete verwachtingen? De precieze

manier waarop we die vraag kunnen beantwoorden, is echter niet onmiddellijk duidelijk. Eerst zullen we moeten

bepalen welke vragen we moeten stellen, hoe we die moeten stellen en hoe we de antwoorden gaan evalueren.

Vandaar: testen is een informatieprobleem.

Binnen de klassieke testmethoden (de bekendste vertegenwoordigers hiervan zijn ISTQB en TMap) is het testgeval

een groot deel van de oplossing. Meer dan voldoende reden dus om deze oplossing epistemologisch3 uit elkaar te

trekken en te kijken wat er dan voor ons ligt. Als we het klassieke testgeval als oplossing hanteren, welke informatie

bevat zo'n testgeval? Hoe verandert dit na het uitvoeren van het testgeval? En ook, waar zit het begrip van wat er

gebeurt?

Ik zal eerst het ontstaan en gebruik van een typisch testgeval beschrijven. Daarna kijken we naar welke soorten

informatie een testgeval bevat, om in het derde deel te analyseren waar het begrip aanwezig is van wat er gebeurt

tijdens het testen, en waar niet.

Ontstaan en gebruik van het testgeval

Laten we om te beginnen kijken waar volgens de klassieke testmethoden testgevallen vandaan komen en hoe ze

daarna gebruikt worden. Vanwege de beschouwende intentie van dit artikel zal ik mij beperken tot wat er gebeurt

volgens deze methoden op zich en mogelijke pragmatische afwijkingen buiten beschouwing laten.

Testbasis

Een testgeval wordt opgesteld aan de hand van de testbasis. In de testbasis zijn de verwachtingen over een systeem

vastgelegd. Waarschijnlijk zijn niet alle (maar wel bijna alle) expliciete verwachtingen vastgelegd. Daarnaast is in

het vastleggingsproces een aantal impliciete verwachtingen expliciet gemaakt. Tot slot bevat de testbasis een aantal

impliciete verwachtingen: verwachtingen waarvan je het bestaan kunt afleiden uit de expliciete verwachtingen in de

testbasis. Dit betekent dat de impliciete verwachtingen in de testbasis af zullen wijken van de 'echte' impliciete

verwachtingen, want ze zijn gebaseerd op verschillende expliciete verwachtingen.

Kortom, de testbasis is geen kopie maar een model van de verwachtingen over het systeem.

3 Epistemologie of kennisleer is het gebied in de filosofie dat zich bezighoudt met vragen als: wat is kennis en wat kunnen we weten?

Pagina 23

Testontwerptechniek

Het opstellen van testgevallen gebeurt aan de hand van de testontwerptechnieken uit de teststrategie. Die

teststrategie is net als de testbasis een transformatie, een model van de expliciete en impliciete verwachtingen over

het systeem. Waar dit bij de testbasis een redelijk rechtlijnige transformatie is (vastleggen van de verwachtingen),

is de teststrategie een complexere transformatie. Naast de verwachtingen houdt de teststrategie ook rekening met

risico's.

De combinatie van deze twee modellen (testbasis en teststrategie) door middel van die testontwerptechnieken

resulteert in het derde model: de verzameling opgestelde testgevallen.

Ook hier gebeurt hetzelfde als bij het opstellen van de testbasis, ook hier zal er dus geen één-op-één relatie zijn

met alle daadwerkelijke verwachtingen. Sterker nog, er zal ook geen één-op-één relatie zijn tussen de verwachtingen

vastgelegd in de testbasis en de verwachtingen in de testgevallen. Sommige informatie gaat verloren, andere wordt

gewonnen. Hoe al deze elementen (daadwerkelijke verwachtingen, testbasis, teststrategie en verzameling

testgevallen) elkaar precies beïnvloeden, moet ik jammer genoeg buiten beschouwing laten.

Testdekkingsmatrix

Eén testontwerptechniek - en als het goed is, gebruiken we meer dan één testontwerptechniek - zal leiden tot

meerdere testgevallen. Vaak groeperen we deze testgevallen om de testuitvoer makkelijker te maken. In dit alles is

het moeilijk bij te houden tot welk deel (of delen) van de testbasis elk testgeval zich precies verhoudt. De oplossing

hiervoor is het opstellen van een dekkingsmatrix ('traceability matrix'): een tabel die deze verhoudingen in kaart

brengt.

Testgeval

Een testgeval bestaat uit twee delen: enerzijds de input (testdata en uit te voeren stappen) en precondities,

anderzijds de verwachte output en postcondities. Correcter zou zijn als er 'de verwachte input en precondities' stond.

Pagina 24

Los van de vraag of de uitvoerende tester de precondities correct identificeert en de input correct invoert, is er het

feit dat het onze verwachting is dat we de specifieke input van het testgeval in kunnen voeren onder de beschreven

precondities. Totdat we dit daadwerkelijk proberen en vaststellen dat dit mogelijk is, blijft het echter niet meer dan

een verwachting. Hetzelfde geldt voor de verwerking door het systeem. Vandaar ook de golvende lijnen in

voorgaande figuur. Een testgeval is onze verwachting op basis van onze beste kennis, maar deze kennis is nog niet

getoetst4. We weten nog helemaal niets over het systeem dat we van plan zijn te gaan testen tot we het

daadwerkelijk gaan testen.

Testresultaat

Als we het testgeval uitvoeren, controleren we de precondities, voeren de input in en vergelijken we de

daadwerkelijke output en postcondities met de verwachte output en postcondities. Op basis daarvan bepalen we:

'test ok' of 'test niet ok'. Hier komen de verwachtingen die geleid hebben tot een te testen systeem voor het eerst

direct samen met de verwachtingen die geleid hebben tot een verzameling testgevallen. Het resultaat hiervan wordt

vastgelegd bij die testgevallen als een reeks groene vinkjes en rode kruisjes - test geslaagd of test niet geslaagd.

Soorten informatie in een testgeval

Nu we hebben beschreven wat een testgeval is (een mogelijke oplossing voor een informatieprobleem), is het tijd

om te kijken wat voor informatie er in een testgeval zit. We kunnen de volgende vier soorten informatie herkennen

(zie zwarte cijfers in de eerdere afbeelding):

1. Hoe het systeem zou moeten werken;

2. Hoe het systeem daadwerkelijk werkt;

3. Waarom we dit testgeval opgesteld hebben;

4. Wat er is getest.

Laten we deze één voor één verder bekijken.

Hoe het systeem zou moeten werken

De informatie over hoe het systeem zou moeten werken, zit in het opgestelde testgeval: de input, de verwachte

output, de precondities, de postcondities. Zoals eerder aangegeven is het belangrijk te beseffen dat we tijdens het

opstellen van het testgeval nog niet weten hoe het systeem zich daadwerkelijk gedraagt. We werken op basis van

verwachtingen, ook bij het bepalen van de input en de precondities. Van sommige verwachtingen zijn we vrij zeker,

van andere een stuk minder. Er ontstaat daarmee een interessante spanning binnen de verwachtingen over hoe het

systeem zou moeten werken: op welk moment ben je zeker genoeg van een bepaalde verwachting om deze te

accepteren als input en/of preconditie van een testgeval?

Een andere vraag is wat er verloren gaat bij het transformeren van de testbasis door middel van

testontwerptechnieken tot testgevallen. We verliezen de impliciete verwachtingen in de testbasis en ruilen deze om

voor de impliciete verwachtingen in de testgevallen.

4 Dit is uiteraard alleen letterlijk waar bij een volledig nieuw systeem gebouwd op nieuwe technologie. We moeten echter niet vergeten dat testen

een informatieprobleem is en dus dat alleen nieuwe informatie interessant is. Over het algemeen is bevestiging van onze bestaande kennis door

een testgeval niet interessant.

Pagina 25

Dit is de kracht van en de zwakte van testontwerptechnieken: ze staan ons toe bepaalde verwachtingen erg scherp

te stellen; het bijbehorende verlies moeten we voor lief nemen. Iets anders dat we verliezen in deze transformatie

is de structuur van de testbasis, de onderlinge relaties van de delen. Er wordt vaak geprobeerd dit verlies te

compenseren door middel van een dekkingsmatrix: hoe verhoudt de structuur van de testbasis zich tot de structuur

van de testgevallen?

Hoe het systeem daadwerkelijk werkt

Tijdens de testuitvoer ontdekken we voor het eerst wat het systeem daadwerkelijk doet. De verwachtingen worden

getoetst aan het systeem. Een manier om hiernaar te kijken is door middel van de OODA-loop van John Boyd:

Observe - Orient - Decide - Act. We voeren een testgeval uit en doorlopen dan de vier elementen: we zien het

resultaat (Observe), we interpreteren die observaties (Orient), op basis waarvan we een beslissing nemen (Decide)

en tot handelen (Act) overgaan (zie figuur). Bij een testgeval gaat die beslissing over de vraag: Is er een probleem

of niet? Voldoet de output aan de verwachte output of niet?

Omdat het testgeval ook de verwachte output beschrijft, betekent dit dat het beschreven testgeval ook het orakel

is, het mechanisme op basis waarvan we beslissen of er een probleem is of niet. Het testgeval beschrijft wat je zou

moeten zien als output; als je dat niet ziet, dan is er een probleem. Het denkproces tijdens het uitvoeren van een

testgeval, hoe we observeren, hoe we ons oriënteren en welke beslissing we nemen, wordt dus voor het grootste

deel bepaald door het van tevoren beschreven testgeval.

Sterker nog, de OODA-loop is amper een 'loop', een lus, te noemen. Na het uitvoeren van een testgeval zal een

tester niet door de OODA-loop heengaan om te bepalen wat het volgende testgeval wordt. Dit volgende testgeval

ligt al voor hem klaar; het is de volgende op de stapel.

Waarom dit testgeval

Elk testgeval bestaat met een reden. Het is ontstaan omdat de teststrategie bepaald heeft dat een bepaalde

testontwerptechniek moet worden gebruikt op de testbasis. Of anders gezegd, als we het rijtje

strategie/tactiek/acties gebruiken (zie figuur), dan wordt het strategische niveau van onze tests beschreven in de

teststrategie. Het tactische niveau, dat de strategie met de testacties verbindt, wordt nergens expliciet beschreven.

Het zit vervat in de gekozen testontwerptechnieken. De testacties tot slot worden beschreven in de testgevallen.

Gevolg van dit alles is dat de reden voor het bestaan van een testgeval nergens expliciet wordt beschreven of

vastgelegd. We moeten het door middel van actieve interpretatie zelf reconstrueren op basis van het testgeval, de

gebruikte testontwerptechniek en de teststrategie. Vraag blijft hoe dichtbij deze reconstructie bij de oorspronkelijke

redenen komt.

Wat er getest is

De vraag wat er is getest, kan op meerdere niveaus gesteld worden. Op het niveau van het testgeval is deze vraag

erg makkelijk te beantwoorden: een testgeval is uitgevoerd of niet, met een 'test ok'-resultaat of niet.

Zodra we voorbij dat niveau gaan, wordt het gelijk een stuk moeilijker. Zoals eerder aangegeven, is de testtactiek

nergens expliciet beschreven. Om tot bij de teststrategie te komen, zullen we dus zelf die sprong moeten maken.

Nu is dat nog wel te doen. Bij gebrek aan expliciete tactiek echter wordt het moeilijk om over de strategie te

communiceren anders dan door terug te keren naar het niveau van uitgevoerde testgevallen.

Een andere weg is de dekkingsmatrix te gebruiken. Dit is echter een beperkte oplossing. Uiteindelijk is deze matrix

niets meer dan het koppelen van verwachtingen uit het testgeval aan verwachtingen uit de testbasis. Hoewel we

Pagina 26

er dus vanuit een andere hoek naar kijken, kijken we er niet naar vanuit een ander perspectief, op een ander niveau.

We winnen er dus relatief weinig mee.

Deze beide oplossingen (terugkoppelen naar teststrategie of naar testbasis) brengen hun eigen problemen met zich

mee. Vandaar dat de derde oplossing misschien wel de makkelijkste is: vertrouwen in het eerder gedane werk.

Waar zit het begrip?

Als we nu een stap terug en daarmee het overzicht nemen, dan valt vooral de verspreidheid van de informatie op.

Het gevolg is dat informatie minder beschikbaar is dan we zouden willen5.

We kunnen echter nog een stap verder gaan: het begrip van wat en hoe we aan het testen zijn, is evenzeer verspreid.

Strategie en actie zijn losgekoppeld door de impliciete tactieken van de testontwerptechnieken. In de testacties zijn

de oriëntatie en de beslissing losgekoppeld van de observatie en de handeling. De eerste twee worden namelijk

vastgelegd in het testontwerp; de laatste twee gebeuren pas in de testuitvoer. En eigenlijk wordt ook de observatie

sterk gestuurd door het testontwerp. Alleen de handeling zelf (aanduiden of een testgeval geslaagd is of niet) gebeurt

volledig binnen de grenzen van de testuitvoer.

Al bij al doet dit sterk denken aan de Chinese kamer van John Searle. In dit gedachtenexperiment zit een man in

een kamer en krijgt hij briefjes met Chinese tekens. Hij heeft een dik boek op basis waarvan hij die reeksen Chinese

tekens in andere reeksen Chinese tekens omzet en deze schrijft hij op een ander briefje. De briefjes die hij krijgt

zijn vragen; de briefjes die hij teruggeeft zijn correcte antwoorden. Voor een buitenstaander lijkt het alsof er in de

kamer iemand zit die Chinees kent. De vraag is nu: Waar zit die kennis, dat begrip van het Chinees? Niet in de man

en niet in het boek. Een mogelijk antwoord is dat het begrip in het systeem als geheel zit, in de man samen met het

boek.

Hetzelfde kunnen we beargumenteren over testen op basis van testgevallen. Er valt niet één iets aan te wijzen dat

begrip heeft van het geheel: van strategie naar tactiek tot geplande en uitgevoerde acties. Dat begrip is alleen

aanwezig in het systeem als geheel bestaande uit teststrategie, testontwerptechnieken, dekkingsmatrix,

testgevallen, testresultaten en mensen.

Is dat een probleem?

Het antwoord hierop zal afhangen van hoe we de complexiteit inschatten van het informatieprobleem dat we testen

noemen. Met als ironische twist dat hoe groter we die complexiteit inschatten, hoe noodzakelijker maar ook hoe

moeilijker het wordt om deze verdeeldheid van begrip te vermijden - of toch op zijn minst voldoende te beperken.

5 Voor verdere gedachten hierover, zie mijn blogpost over informatieschuld: http://testingcurve.wordpress.com/2014/07/13/information-debt/

Pagina 27

SUCCESVOLLE TESTVERBETERING IN IEDERE SITUATIE

Door Kees Blokland ● kees.blokland@polteq.com @keesbloklandp

We lopen steeds vaker tegen de grenzen aan van bestaande modellen voor testverbetering.

Als we de traditionele modellen toepassen moeten we ons in allerlei bochten wringen, omdat

ze niet meer goed aansluiten op de huidige praktijk. Hoe kunnen we dat voorkomen? Hoe

nemen we de beperking van een model weg en leveren toch een voorspelbaar resultaat op?

Lees verder en neem kennis van belangrijke innovaties in testverbetering.

Knelpunten nader bekeken

Veelgebruikte modellen voor testverbetering zijn ontwikkeld in een tijdperk waarin testen bezig was volwassen te

worden en in de fase zat van het structureren. Inmiddels bevinden veel organisaties zich in een volgende fase van

volwassenheid met Agile werken en veel aandacht voor specialismen, zoals testautomatisering, continuous delivery,

non functional testing, testen van services, et cetera. Naast deze verbreding en verdieping gaan de ontwikkelingen

in de technologie ook steeds sneller. Dit stelt nieuwe eisen aan testverbetering.

Los van de druk vanuit de evolutie van IT en testen willen we ook met de volgende hardnekkige problemen

afrekenen:

Het fenomeen dat scoren soms als belangrijker wordt gezien dan verbeteren;

Dat goede verbeterplannen vaak niet leiden tot het gewenste resultaat;

Dat testverbetering onvoldoende ruimte krijgt doordat de kortetermijnoperatie voor gaat;

Dat verbeteren wordt gestuurd vanuit een ‘ivoren toren’ met mensen die ver van de dagelijkse praktijk af staan,

waardoor het mist aan draagvlak op de werkvloer.

Wat moet anders? Belangrijke aspecten van doeltreffende testverbetering zijn onder meer ‘snel’, ‘flexibel’, ‘adding

value’, ‘continu’, ‘context driven’ en ‘gebaseerd op samenwerken’.

Pagina 28

Concreet betekent dit:

testverbetering inrichten als een continu, iteratief proces met in iedere iteratie een meetbaar effect;

testverbetering adaptief maken waardoor we goed kunnen omgaan met veranderingen onderweg;

testverbetering goed inbedden in de operatie (in business as usual);

aanhaken van de juiste personen en samenwerken op elk niveau van testverbetering (neerhalen van de ivoren

toren).

Daarbij maken we goed gebruik van allerlei ‘lessons learned’ en succesvolle innovaties in de IT, zoals Agile en Scrum.

Verbeterde aanpak

Testverbetering start op architectuurniveau. Een improvement architect zorgt dat de volgende stappen worden

doorlopen: vaststellen van de doelstellingen en de scope en approach matching. Tijdens approach matching bepaalt

de improvement architect samen met de belanghebbenden welke modellen en benadering voor testverbetering de

meeste kans van slagen hebben, gegeven de doelstellingen, de scope en de context. Daarbij is keuze uit zowel

‘bound’ (vaste, voorgedefinieerde) als ‘unbound’ (flexibele) modellen. Voor de eigen rol zoekt de improvement

architect naar de juiste balans tussen ‘faciliteren’ en ‘strakke kaders zetten’. Dit hangt af van de organisatie: zijn dit

ervaren Agile teams die volledig zelfsturend zijn, of is het een projectorganisatie met managementsturing in de

operatie.

Onder begeleiding van de improvement architect voert de organisatie een (eerste) assessment uit volgens de

gekozen ‘approach’. Samen met alle belanghebbenden worden concrete voorstellen voor testverbetering opgesteld

in de vorm van improvement stories om te worden opgepakt door improvement teams op implementatieniveau. Een

improvement team bestaat onder meer uit mensen in de operatie die de verbeteringen in de praktijk gaan brengen.

In een ervaren Agile organisatie nemen de teams de verbeterdoelstellingen mee in de sprints. Ieder Agile team is

dan tevens improvement team. De improvement owner stelt de prioriteiten van de improvement stories vast. In

iteraties worden de improvements broksgewijs geïmplementeerd.

Architectuurniveau

Het architectuur niveau omvat de volgende activiteiten:

Test Improvement Intake

Assessment

Continuous Improvement Release

In de intake fase van testverbetering worden de volgende stappen uitgevoerd:

Pagina 29

Objective setting; wat zijn de doelen? Voorbeelden: verlagen van testkosten, verkorten van de testdoorlooptijd,

het verhogen van de kwaliteit van testen, verhogen van testautomatiseringsgraad, verbeteren van Agile testen.

Meer nog dan vroeger staat de ‘business value’ van testen centraal. Wat is de bijdrage van testen aan (de

kwaliteit van) het product?

Scope; wat is het aandachtsgebied? Waar is het testverbeteringsinitiatief op gericht? Gaat het over een hele

organisatie, alleen over performancetesten, succesvol Agile testen, TDD, testen van cloudservices, et cetera? In

tegenstelling tot bij traditionele methoden voor testverbetering hoeft de scope niet beperkt te zijn tot sec testen,

maar kan het betrekking hebben op zaken met een testcomponent, zoals het verbeteren van het continuous

integration proces. Binnen de scopebepaling wordt het in kaart brengen van de context steeds belangrijker. Om

te beginnen gaat het daarbij om de status van de technologie: gaat het over legacy, over web development of

over mobile en cloud? Vervolgens: wat is de manier van ontwikkelen, welk samenwerkingsmodel wordt

gehanteerd? Sequentieel werken, Agile of devops? En niet in de laatste plaats: wat is de cultuur? Formeel of

niet? Tot slot moet duidelijk worden wat voor ruimte er is voor de verbeteractiviteiten in tijd, geld en resources.

Approach matching; welke aanpak, welke methode, welk model kan het best worden gekozen, welke modellen

kunnen het best worden gekozen? Approach matching wordt in de volgende paragraaf toegelicht.

Approach matching

Op basis van de nu beschikbare gegevens wordt bepaald welke methoden, welke modellen, welke benaderingen de

grootste kans geven om de doelstellingen te behalen. Formele testorganisaties die een groot belang hechten aan

reproduceerbare assessment resultaten hebben voorkeur voor traditionele modellen zoals TMMi en TPI Next.

Organisaties die bezig zijn met de inrichting van Agile /Scrum hebben meer aan een model voor testen binnen Agile

processen. Voor minder formele organisaties, voor kleine organisaties, of als er zeer snel resultaat nodig is, zijn

informele methoden een goed alternatief. In veel gevallen kiest men voor een hybride aanpak: een combinatie van

modellen, aangevuld met informele methoden die elkaar versterken.

Unbound, bound & tailor-made models

Traditionele modellen zoals TPI Next, TMMi en minder bekende zoals STEP en CTP leggen een vast referentiekader

op. We noemen ze daarom ‘bound models’. Een interessante subgroep daarbinnen wordt gevormd door zogeheten

maatwerk (tailor-made) modellen die zich richten op een specifiek aspect, zoals bijvoorbeeld Belbin-rollen of testen

binnen Agile. Als tegenhanger van de bound models introduceren we de zogeheten ‘unbound models’. Denk hierbij

bijvoorbeeld aan experience based, heuristic based, brainstorm en exploratory aanpakken, die meer ruimte bieden

om flexibel in te spelen op de situatie in en de wensen van de organisatie. Een huisarts doet dat ook door met

‘questioning’ uit te zoeken wat er met je is (Hoe voel je je? Heb je dit eerder gehad? Doe je aan sport? Hoe gaat het

met de familie?), in plaats van slechts procedureel, ‘bound’ een vast checklijstje af te lopen met bloeddruk-, hartslag-

, en temperatuurmeting. Een interessante unbound methode is het houden van een ‘idea raising session’, waarbij

met betrokkenen via een brainstorm een assessment wordt uitgevoerd, met verbetervoorstellen als direct resultaat.

Wel belangrijk voor ‘unbound’ is om de argumenten en criteria te vermelden die een rol hebben gespeeld bij de

uitkomsten.

Pagina 30

Hybride

De cultuur in een organisatie is mede bepalend voor de modelkeuze. Formele of grote organisaties kiezen eerder

voor bound modellen. Kleine of informele organisaties voelen zich meer op hun gemak met een unbound benadering.

Ervaren TPI assessoren werken in de praktijk vaak hybride: een bound model geeft de structuur, unbound methoden

in de uitvoering geven de broodnodige bewegingsruimte. Met de organisatie wordt daar in de approach matching

fase heldere afspraken over gemaakt. Zo volgen de assessoren de nuances van de praktijk en zoomen ze in op wat

er werkelijk aan de hand (b)lijkt te zijn.

Pagina 31

Assessment

Met een assessment ontstaat een (beter) beeld van de startpositie van de testverbetering: ‘if you don’t know where

you are, a map won’t help’. De gekozen ‘approach’ bepaalt hoe een assessment wordt uitgevoerd. De doorlooptijd

varieert tussen een paar uur en een maand of twee. De assessmentresultaten leggen de basis voor concrete

testverbetering.

Improvement stories

Net zoals bij softwareontwikkeling verloopt testverbetering succesvoller in kleine brokken, met regelmatige

bijsturingsmomenten om veranderingen in mee te nemen. Bovendien sluit dat beter aan bij de Agile methodiek, die

in steeds meer organisaties wordt toegepast. Een jaarplan voor verbetering is goed om een stip op de horizon te

zetten, maar verbeteren doen we beter broksgewijs met haalbare doelen op afzienbare termijn van eerder weken

dan maanden. De Agile methodiek verhoogt bovendien de eigenaarschap voor de verbeteringen op de werkvloer.

De improvement architect zorgt, met hulp van vertegenwoordigers van de werkvloer en de improvement owner,

voor de vertaling van voorstellen voor testverbetering naar improvement stories. Hiermee ontstaat een goed helder

beeld van:

wie de belangrijkste belanghebbende is (en dus de sponsor voor de verbetering is);

welke concrete verbetering moet worden gerealiseerd;

aan welke doelstelling die verbetering bijdraagt.

Deze informatie is van groot belang voor de mensen die met de uitvoering aan de gang moeten. Willen die hun

commitment aan de verbetering verlenen, dan moet voor hen helder zijn wanneer sprake is van succes. Met andere

woorden, wat zijn de acceptatiecriteria bij deze improvement story? Net zoals bij de voorbereiding van een Agile /

Scrum softwaredevelopment release kan ook bij testimprovement release nadere uitwerking van de stories nodig

zijn (elaboration). Alle betrokkenen zijn daarbij nodig: de improvement architect, de improvement owner en het

(beoogde) improvement team.

Hieronder staan enkele voorbeelden van improvement stories (of improvement epics die nog nader moeten worden

uitgewerkt in improvement stories).

As senior IT-director, I want to increase test efficiency, so that the testing cost is reduced by 20%.

As test department manager, I want to automate the regression tests, so that the effort for regression testing

is reduced.

As product manager, I want to increase the release frequency, so that we will be more competitive.

Pagina 32

Implementatieniveau

In een improvement releaseplanning meeting wordt volgens goede Agile / Scrum praktijk met alle betrokkenen een

realistische releaseplanning voor de testverbetering gemaakt inclusief indeling in improvement sprints. Commitment

van alle betrokkenen is een belangrijke voorwaarde voor succes. Hiermee wordt de kans op succes verhoogd (geen

ivoren toren, inpassen in de operatie).

De improvement owner stelt de prioriteiten van de improvement stories vast en zorgt voor het vrijmaken van de

benodigde resources. Hij of zij doet dit namens de primair belanghebbenden zoals genoemd in de eerste regel van

de improvement stories.

Indien de organisatie al veel ervaring heeft met Agile / Scrum en de teams zijn gewend aan het meenemen van

verbeteringen als normale sprinttaken, dan integreren de improvement activiteiten volledig met de

ontwikkelactiviteiten. De rol van de improvement architect lijkt dan veel op die van een testmanager in een Scrum-

of-Scrum constructie die de grote lijn in de gaten houdt (de stip op de horizon), eventuele blokkades helpt wegnemen

en de teams coaching op het gebied van testverbetering aanbiedt.

Afrondend

In de architectuurfase wordt voldoende informatie verzameld om te komen tot een gezonde keuze voor de aanpak

(approach matching). Hiermee wordt voorkomen dat de testverbetering niet succesvol is door de toepassing van

methoden of modellen die niet goed passen bij de doelstellingen of de context. De snelle ontwikkelingen in de IT en

de specifieke wensen en karakteristieken van de organisatie kunnen op de voet worden gevolgd.

Unbound modellen en methoden voegen een belangrijke dimensie toe aan het palet van testverbetering. Door die

in combinatie toe te passen met bound modellen (hybride aanpak), ontstaan de flexibiliteit en de ruimte om in te

spelen op actuele ontwikkelingen. Een bijkomend voordeel van ‘unbound’: de neiging tot scoren vermindert.

Methoden die geleend zijn van Agile / Scrum helpen goed bij het verkrijgen van de juiste mate van samenwerking

en het verhogen van de kans dat de testverbeteringen werkelijk tot resultaat komen. Daarmee integreert

testverbetering ook beter in de hedendaagse manier van werken.

We hebben de ivoren toren van de testverbeteraars afgebroken, de neiging tot focus op scoren gedempt, de kans

dat verbeterplannen in de la verdwijnen verkleind, de aansluiting gevonden met business as usual, kortom de kans

op succes van testverbetering verhoogd.

Pagina 33

BUGHUNTING – TESTEN VERGELEKEN MET EEN SPELLETJE ZEESLAG

Door Bram Bronneberg ● bram.bronneberg@cgi.com

Heb jij ooit maar heel beperkt de tijd om je duim omhoog of omlaag te steken om je oordeel

te geven over een bepaalde oplossing en loop je toch tegen een bevinding aan, maar je

wilt het probleem zo snel mogelijk opgelost krijgen zodat het systeem live kan? Aan de

hand van een spelletje zeeslag leggen we uit hoe je met kennis en ervaring en een goede

dosis exploratory testing (ET) heel ver kan komen.

Ik ben jammer genoeg nog maar zelden echt aan het testen, maar kom toch nog wel eens

in de situatie dat ik zelf achter de knoppen kan zitten. Zo'n situatie doet zich meestal voor

wanneer we een release live brengen ergens in een weekend of avond en ik nog ‘even ‘

test of alles werkt. Een mooi sentiment toch, al ons harde werk met testvoorbereiding zo weer even vergeten en

ogenschijnlijk free format aan het testen slaan. Nu ik dit schrijf, voelt het alsof ik een beetje vloek in de kerk, maar

hopelijk wordt het me vergeven.

Maar wat doe ik dan eigenlijk in zo'n situatie, kijk ik in de specificatie of zoek ik de testplannen erbij…? Nee eigenlijk

niets van dat alles. Maar wat dan wel? Ik begin natuurlijk de zoektocht gespitst op de productrisico's die ik natuurlijk

wel ken uit de PRA-sessies en ga ik met de basisfunctionaliteit aan de gang. Dat is mijn startpunt en vandaaruit vind

ik een mogelijk probleempje. Mijn verhaal gaat over het verder zoeken vanuit deze gevonden probleempjes. Ik zal

mijn werkwijze proberen uit te leggen aan de hand van het spelletje zeeslag. Uit de praktijk blijkt namelijk dat bugs

meestal samenklonteren en dat ervaren testers ook weten hoe ‘groot’ een bug is. Testers kunnen dus op basis van

ET-technieken heel efficiënt, dus met betere dekking tegen lagere kosten, hun werk doen.

Zeeslag?

Zeeslag is een spel voor twee spelers dat zijn oorsprong heeft in het begin van de vorige eeuw. Het spelelement

bestaat uit het gokken van de positie van de vloot van de tegenstander. Beide spelers hebben een raster van

(gewoonlijk) 10x10 hokjes waarop ze hun ‘vloot’ opstellen bestaande uit een

vooraf afgestemd aantal schepen met bekende afmeting. In de afbeelding

rechts zie je een voorbeeld met een typische opstelling voordat de slag echt

losbarst. Beide spelers maken zo'n opstelling, op papier of op een plastic spel

met pinnetjes of met een digitale variant. De volgende stap is dat men

beurtelings een schot lost op het veld van de ander en dus gokt waar de vloot

van de tegenstander precies opgesteld is. De tegenstander moet zeggen of

het raak of mis was waarvan de schutter een aantekening maar. Het

uiteindelijke doel is natuurlijk om de gehele vloot van de tegenstander tot

zinken te brengen voordat je eigen vloot naar de kelder is.

De eerste testrun

Maar waarom toch deze uitleg over een simpel spelletje? Nou, het is ons testers allemaal bekend dat er bepaald

soorten bevindingen zijn met ieder hun eigen karakteristieken in hun eigen context. Denk bijvoorbeeld aan diakriet

bevindingen waarbij de ‘é’ niet correct gebruikt kan worden op een formulier. We weten dat er een beperkt aantal

oorzaken zijn van deze bevindingen, maar ook welke andere bevindingen uit deze oorzaken kunnen voortkomen.

Pagina 34

Stel dat je in je geplande testrun zeven bevindingen tegenkomt. Je hebt dus

een probleem en kan niet live zonder heel goed te weten wat er allemaal nog

voor problemen zijn en deze mogelijk kan laten oplossen. In het figuur links

worden deze bevindingen als rode ‘treffers’ weergegeven en in het grijs de

‘missers’. Dit is het resultaat van je geplande eerste testrun, maar je hebt

dus bevindingen gedaan.

Root-Cause Analyses

Nu wil je dus inzoomen op deze bevindingen en achterhalen wat de

achterliggende oorzaken van deze bevindingen kunnen zijn. Met je ervaring

en kennis van het domein en de techniek kun je de achterliggende oorzaak

van de bevinding beredeneren en op basis daarvan een inschatting maken

van alle mogelijke fouten die gerelateerd zijn aan deze bevinding. Je weet

dus bijvoorbeeld welke onderdelen gebruikmaken van een database of je

weet welke onderdelen allemaal diakrieten gebruiken op formuliervelden.

Deze mogelijke fouten zijn aangegeven met geel en iedere mogelijke bug vet

omlijnd. Zoals je kunt zien zijn er veel mogelijke posities voor de ‘vloot’ aan

bevindingen, maar je hoeft niet de hele zee te bombarderen. Voor ieder van

deze vermoedens kun je een Test Charter opstellen waarmee je later je ET-

sessies kan sturen.

Exploratory Testing & Test Charters

In dit artikel ga ik niet heel diep in op de verschillende ET-technieken of de

Test Charters, maar ik zal het in het kort toelichten. Het proces van ET

bestaat uit de volgende drie globale stappen:

1. Stel een Test Charter op;

2. Voer een Test Charter uit en maak notities;

3. Bespreek je bevindingen.

Een Test Charter zelf bestaat ten minste uit de volgende onderdelen:

• Wat ga je testen;

• Waarom ga je testen;

• Hoe ga je testen;

• Verwachte problemen;

• Referentiemateriaal.

Terug naar de strijd!

Met je Test Charters kan je dus nu heel gericht zoeken naar de bugs, je weet dus

waar de vloot kan liggen en vuurt je salvo's af. De donkerrode treffers hadden we

al gemaakt en zie je dat we weer een heel aantal salvo's afgevuurd hebben op de locaties waar we een schip

vermoeden. Wederom het lichtrode voor nieuwe treffers en het grijze voor missers. Het is namelijk niet zo dat de

oorzaak van één bevinding ook altijd een uitstraling heeft op de plekken waar wij die vermoeden.

De harde waarheid

Pagina 35

Het is echter wel zo dat deze techniek niet 100% dekkend is en we niet net zoals in zeeslag exact weten hoeveel

schepen er meespelen. Er zullen dus altijd nog andere bevindingen kunnen zijn

die we gewoon niet gevonden hebben met deze techniek. Zoals je hier naast kunt

zien in paars waren er nog meer bevindingen verstopt die we niet hadden

gevonden vanuit onze startende ET-sessie en ook niet door ons potje zeeslag.

Resumerend

Kom je weer in die fantastische situatie waarin je ‘even’ ging kijken of de

oplevering ‘goed’ is en heb je toch een treffer, ga dan door tot het slagschip

gezonken is. Gebruik je kennis en ervaring van de mogelijke onderliggende

oorzaken van de fout die je gevonden hebt om effectief de andere fouten te

vinden.

In werkelijkheid is de wereld natuurlijk veel complexer en niet 10x10 hokjes maar het idee is hetzelfde.

1. Je start je zoektocht met een geplande testrun;

2. Wanneer je een bevinding tegenkomt

a. Doe een root cause analyse,

b. Stel een testcharter(tje) op,

c. Voer je testcharter uit en rond hem af,

d. Parkeer eventueel nieuwe bevindingen die geen directe relatie lijken te hebben voor een volgend charter;

3. Blijf stap twee herhalen tot je al je charters afgerond hebt.

Succes met jullie eigen zeeslagen en salut!

Pagina 36

PRODUCTRISICOANALYSE: VELE WEGEN LEIDEN NAAR ROME!

Door Peter van Tulder ● peter.van.tulder@bartosz.nl

Voor een goede teststrategie is een productrisicoanalyse (PRA) onontbeerlijk. Als

professionele testers willen we niet alleen de volledige scope (requirements) van het

project testen, maar ook rekeninghouden met de belangrijkste bedreigingen (risico’s).

Binnen het testvak bestaat echter een soort onuitgesproken ontzag voor de PRA. Elke

testmanager leert dat een PRA belangrijk is en dat je deze zo snel mogelijk moet

organiseren, maar veel van ons zijn bang om het middel in te zetten. De PRA is namelijk

vaak het eerste moment waarop je als testmanager op de zeepkist klimt en leiderschap

moet tonen. Vaak ten overstaan van stakeholders die al jaren in het vak zitten, op een

moment dat je zelf nog nauwelijks inhoudelijk weet wat je project en product inhouden.

Met de dichterlijke vrijheid van overdrijving schets ik hoe zo’n sessie dan verloopt:

‘Na weken sleuren en pleuren heb ik projectmanager Anja eindelijk overtuigd dat ik de benodigde stakeholders

bij elkaar mag brengen voor mijn productrisicoanalyse. Ze was daar op tegen, omdat ze het gebruik van risico’s

als projectdriver niet zo belangrijk vindt als ikzelf (‘zo’n negatieve insteek!’). Ze vindt het bovendien moeilijk

verkoopbaar om zoveel belangrijke en dure mensen een halve dag uit de operatie weg te trekken.

Om negen uur (de geplande begintijd) druppelen de eerste stakeholders de kamer in, debatterend over het

laatste nieuws van de afdeling en de Champions League wedstrijd van gisteravond. Aangezien ik de meeste

deelnemers nog nooit ontmoet heb, stel ik me bij de deur op een geef iedereen netjes een pootje. ‘Snert, had ik

dat maar eerder gedaan’, denk ik. ‘zoveel nieuwe koppen. Hoewel, eigenlijk ben ik natuurlijk de nieuwe kop!’.

Ik besluit te wachten tot driekwart van de genodigden aanwezig is. De mensen die er al zijn, leunen achterover,

de smartphone getrokken als verdediging tegen mij en de verveling. De jongen die zich voorstelde als Rik, wordt

gebeld. ‘Nee, ik bel je vanmiddag even, ik zit in een of andere sessie over risico’s’, hoor ik hem achter zijn hand

zeggen.

Om tien over half tien schraap ik mijn keel en begin, met wiebelende knieën, aan de aftrap. Als ik het doel van

de ochtend heb uitgelegd, valt Anja naar binnen: ‘Toch eens even kijken waar ik drieduizend euro aan uitgeef’,

zegt ze terwijl ze vooraan gaat zitten. Ze verpakt het als een geintje.

Van voor af aan beginnen? Gewoon verdergaan? Ik aarzel even en kies het laatste. Ik vertel de groep dat de

input vandaag van hen moet komen en dat ik een actieve bijdrage verwacht. De deelnemers (zijn ze nu expres

aan de verste tafeltjes gaat zitten?) leunen nog wat verder achterover en nippen met een verwachtingsloze blik

aan hun bakje leut. ‘Nog maar vier uur en ik kan weer wat nuttigs gaan doen!’, zie ik ze denken. Hun grootste

interesse lijkt uit te gaan naar klok, koek en koffiepot. Als ik na een uur de eerste mensen losser heb gekregen

en daarmee de eerste prima productrisico’s vastleg, worden ook de anderen actiever. Niet om aanvullingen te

geven, maar om de eigen belangen te verdedigen. Jan, de functioneel applicatiebeheerder, noemt het risico dat

de applicatie niet performt. ‘Tssk... wat een onzin’, zegt Mark, de marketingman. ‘Als we niet eerst het

telefoonnummer van de boekingslijn voldoende zichtbaar maken, hoeven we ons over performance überhaupt

niet druk te maken!’. Kees, de proces-expert van de betalingslijn, geeft aan dat hij niets wil zeggen over de

impact van risico BL15. ‘Als ik het fout heb, krijg ik het op mijn dak’, bast hij. ‘Dat moet je maar aan mijn baas

vragen!’. Anja ergert zich intussen aan het detailniveau van sommige

Pagina 37

discussies, en kapt steeds eerder af, ook de zinvolle discussies. Fijn, net op een moment dat ik dacht dat ik

aardig op weg was, neemt de politiek een loopje met de sessie.

Na vier uur worstelen met de controle over de sessie maakt de lunch hardhandig een einde aan de meeting en

terwijl de laatsten door het gat van de deur verdwijnen voordat ik mijn laptop heb dichtgeklapt realiseer ik me

dat mijn doelen niet bereikt zijn. Een berg snelle aantekeningen toont een willekeurige en onvolledige lijst van

risico’s, prioriteiten (en tegenargumenten) en een bijna net zo grote lijst van onbesproken punten. ‘Ik hoop dat

je tevreden bent?’, vraagt Anja voordat ze de ruimte verlaat, ‘… want ik ben het in ieder geval niet’, klinkt haar

echo nog na.

PRA’s zijn best lastig en mislukken vaak juist omdat ze worden opgeblazen tot enorme proporties! In bovenstaande

karikatuur, deels mijn en deels verzamelde ervaringen, gaan diverse factoren mis. Mocht je bovenstaande als een

verwijt van inzet en motivatie bij stakeholders hebben geïnterpreteerd, dat is het geenszins! Voor al deze factoren

kan de hand in eigen boezem worden gestoken:

de vorm van de sessie (een workshop van een dagdeel of meer) is te groot;

de inschatting van de sessieduur is arbitrair gekozen;

de hoeveelheid aanwezigen is te groot om goed te managen;

de hoeveelheid belanghebbenden is te groot om te managen, wat zorgt voor politiek en principiële standpunten

in een sessie die gebaat is bij luchtigheid en vrijdenken;

de fase in de tijd is vaak te vroeg in het project: testmanager heeft vaak onvoldoende materiekennis om goed

te kunnen sturen en kent de deelnemers onvoldoende om ze op effectieve wijze aan te sporen;

we hebben business- en productiegebruikers onvoldoende voorbereid op wat we van hen verwachten, waardoor

ze de intrinsieke noodzaak van deze sessie niet voelen;

er is niet van tevoren bilateraal kennisgemaakt, het eerste contact is een onpersoonlijke sessie.

Bovendien, door de PRA zo groot en officieel te maken, creëren we een vehikel dat zo complex is dat we het zelf

nauwelijks nog kunnen besturen. Hoe groter het podium, des te feller de spotlights. Een goed optreden is dan nog

steeds niet onmogelijk, maar alleen testmanagers met een aangeboren podiumtalent zullen in een dergelijke setting

excelleren. Maar ook voor de mindere artiesten zijn er vele wegen naar Rome. Ook eenvoudiger en toch uitstekend

begaanbare wegen.

Voor mijn huidige project heb ik twee verschillende strategieën uit de kast getrokken.

De bilaterale PRA;

De brownpapersessie-techniek.

Bilaterale PRA

De band Toontje Lager zong ooit ‘Ik heb stiekem met je gedanst (ik hoop dat je het leuk vond)’. Ik zou dat willen

verbasteren naar: Ik heb stiekem met je ge’pra’at (ik weet dat ik het goed vond). Zou je aan willekeurige

stakeholders vragen of er in ons project een productrisicoanalyse is uitgevoerd, dan antwoorden ze de vraag

waarschijnlijk met ‘nee’. Toch hebben ze allemaal input geleverd.

Zo heb ik alle stakeholders uitgenodigd voor bilaterale kennismakingsgesprekken, waarin ik mezelf op zo informeel

mogelijke wijze heb geïntroduceerd, met veel koetjes en kalfjes. Hoe formeler je opstelling, des te formeler de

antwoorden en nogmaals: een PRA is gebaat bij vrijdenken! In deze introductierondes heb ik de risicovraag ter

discussie gesteld. En om te voorkomen dat politieke tijgers terugvallen in hun formele opstelling, heb ik

Pagina 38

mijn vragen bedekt en informeel gesteld. Begin met vragen naar de waarde (business value!) van het product voor

de betreffende stakeholder en zijn afdeling. Interesseer je in zijn belang: waarom is hij gebaat bij de inproductiename

van het systeem? Stakeholders worden nu eenmaal enthousiast over de kansen van een systeem, niet van de

bedreigingen ervan (tenzij ze fervent tegenstander van het systeem zijn!). Als je hun belang kent, kun je voorzichtig

doorvragen naar alles dat die waarde bedreigt. In plaats van te vragen ‘wat zijn voor jou afdeling de grootste risico’s

voor het livegaan?’, kun je vragen stellen als: ‘Wat is voor jouw rol nou de grootste nachtmerrie als we straks live

zijn?’ (vrees). Of ‘Zijn er in het vorige systeem problemen voorgevallen die we nooit meer mogen laten gebeuren?

(vrees voor herhaling)’ En ‘welke aanpassing zou dit systeem beter maken dan het vorige?’ (hoop). ‘Vrees’ en ‘hoop’

zijn krachtige triggers, omdat mensen bereid zijn te geloven in wat ze vrezen of graag zouden willen. Mijn

eindresultaat was een lijst van meer dan veertig risico’s, met opvallend veel punten die meerdere stakeholders

aandragen. Dat levert direct een voorzichtige prioriteitsstelling op.

Brownpapersessie

Mijn project beslaat zowel een twee verschillende project- en productgroepen in twee landen. Omdat Frankrijk niet

om de hoek ligt, heb ik in het begin van mijn opdracht een kennismakingsmeeting gepland met het voltallige Franse

project(management)team. Ik vond dat een uitgelezen

gelegenheid om ook in dat gezelschap de productrisico’s te

inventariseren. Omdat de belangen van de deelnemers (PM,

teamleads van productiegroepen, functional application

management) uiteenlopen, heb ik een brownpapersessie

georganiseerd. Dat is een techniek die op gestructureerde

wijze ervoor zorgt dat alle betrokken evenveel input

leveren, dat niemand zich kan verstoppen of door anderen

onder de voet gelopen worden, en die alle politiek en

belangendiscussies platslaat.

De essentie van een brownpapersessie, is dat je dezelfde

specifieke vragen stelt als in de bilaterale PRA, maar dat de

antwoorden niet mondeling, maar schriftelijk gegeven

worden. Op de vraag ‘Wat mag er in het nieuwe systeem

nooit meer fout gaan?’ vult iedereen drie post-it briefjes in, met zijn of haar antwoorden. Minimaal drie, maximaal

drie. Daarmee voorkom je dat er ongelijkheid optreedt en dat de één maar twee antwoorden geeft, en de ander

zeven. Dat betekent ook dat iedereen prioriteiten moet stellen. Als iemand zes antwoorden weet, kiest hij de drie

belangrijkste uit. Neem daar per vraag tien minuten tot een kwartier de tijd voor. Als je groep eerder klaar is, stop

je eerder. Als iedereen gereed is, roep je de mensen een voor een naar voren om de antwoorden te presenteren.

Doel is dat het voor de groep duidelijk is wat de presentator bedoelt. Dat is wat anders dan dat ze het ermee eens

zijn. Elke discussie over zin en onzin van het punt druk je direct de kop in.

Zo doe je in verschillende ronden verschillende vragen. Elke vraag duurt inclusief presentatie al gauw een half uur

tot drie kwartier, afhankelijk van de groepsgrootte. Kies de vragen daarom zorgvuldig en stel zelf ook prioriteiten.

De belangrijkste vragen als eerste! Als alle post-its hangen, ga je als regisseur samen met de groep op zoek naar

clusters. Welke briefjes gaan over bepaalde functies, de performance, over downtime van het systeem, corrupties

in de database, of verkeerde informatie in de rapporten.

Pagina 39

In de laatste tien minuten van de sessie geef je iedereen vijf a tien mini-stickertjes, die men mag plakken op de

post-its waaraan ze het meeste belang hechten. Dat mogen verschillende zijn, maar ze mogen ook meerdere mini-

stickers op één post-it plakken.

Het eindresultaat is een leuke, onconventionele en levendige sessie, waarin je een goede verzameling van risico’s

krijgt met een groepsgewijze prioritering. Je zult zelfs merken dat als je bepaalde onderwerpen niet hebt kunnen

behandelen, er draagvlak is om deze in een additionele sessie alsnog te onderzoeken. Gewoon, omdat het nuttig én

leuk was!

Breng focus aan

Voor beide technieken geldt: als je mensen wilt aansporen om input te leveren, dien je als regisseur vaak focus aan

te brengen in hun denkpatroon. Tijdens een TestNet Agile Games avond, stelde Pascal Dufour me eens de vraag

‘noem mij eens vijf dingen die wit zijn?’. Dat koste me een kleine minuut, en ik noemde willekeurig vijf dingen die

geen relatie tot elkaar hebben. Vervolgens vroeg hij me om vijf dingen te noemen die wit zijn en die je in een

koelkast aantreft. Door de focus versmalt je horizon en krijgt deze structuur. Het koste me nu slechts vijftien

seconden om te antwoorden. Dat werkt met de risicovraag ook zo. Vraag iemand wat de risico’s van het project zijn

en je krijgt een onsamenhangende en onvolledige set antwoorden. Ga daarom gestructureerd te werk en kies een

indeling. Benoem bijvoorbeeld risico’s per functionaliteit, deelgebied, requirement(sgroep), kwaliteitsattribuut

(functionaliteit, performance, continuïteit, et cetera). Welke van deze indelingen je kiest, bepaal je zelf, zolang je

maar een indeling volgt.

Samenvattend

De bilaterale PRA en de brownpapertechniek zijn twee ‘kleinere’ wegen om in Rome te komen. En natuurlijk, beide

hebben hun beperkingen ten opzichte van een traditionele PRA. Zo heb je na de bilaterale PRA’s nog geen

gezamenlijke prioriteitstelling en filteren beide technieken geen risico’s uit die onzinnig blijken te zijn. De traditionele

PRA is daarom zeker niet failliet. In een project waarin je de projectdoelen, de materie en alle projectbetrokkenen

inclusief hun belangen al langer kent en je weet hoe je ze enthousiasmeert, kun je deze eenvoudiger toepassen.

Maar soms levert een kleine aanpak een gro(o)t(s)er resultaat! En in alle gevallen levert een kleine aanpak meer

resultaat dan geen aanpak!

Pagina 40

BETER IS NIET ALTIJD GOED

Door Bert Wijgers ● bert@wijgers.com @bertwijgers

Softwaretesten is een activiteit die kan leiden tot verbetering van het software-

voortbrengingsproces. Iedere bevinding is niet alleen een kans om het product te

verbeteren, maar ook een kans om het proces te verbeteren. Welbeschouwd is het maken

van fouten de enige manier om te leren. Dit geldt niet alleen voor ontwerpers en

programmeurs, maar ook voor testers.

Een voor de hand liggend startpunt voor een verbeteractiviteit is wat algemeen bekend staat

als de Deming-cirkel: plan, do, check and act. Eerst maak je een verbeterplan en dan voer

je het uit. Vervolgens kijk je of het plan heeft gewerkt. Zo niet, dan maak je een nieuw plan.

Als het plan deels heeft gewerkt, dan kun je actie ondernemen. Dat wil zeggen dat je je plan aanpast om het beter

te laten werken. Als het plan in eerste instantie al echt goed werkte, dan kun je een nieuw plan te maken om weer

verder te verbeteren. Hoe dan ook, verbeteren is nooit klaar.

Deming heeft zelf altijd verwezen naar deze cirkel van verbeteractiviteiten als de Shewhart-cirkel. Deming (1986)

deed eigenlijk maar één aanpassing aan de cirkel van Shewhart; hij verving ‘check’ door ‘study’. Helaas, deze

wijziging sloeg niet aan. Waarschijnlijk omdat ‘plan, do, study and act’ niet zo goed klinkt als ‘plan, do, check and

act’. Daarom stel ik een alternatief voor dat in lijn is met Demings idee dat de derde activiteit veel meer is dan alleen

controleren en dat wel hetzelfde ritme en rijm heeft als de originele Shewhart-cirkel: plan, do, test and act.

Softwaretesten is onderdeel van het software-voortbrengingsproces. In Agile-projecten werken testers in

multidisciplinaire teams samen met programmeurs en ontwerpers. Bij watervalprojecten lijken testteams

onafhankelijker, maar ze maken ook daar deel uit van het grotere plaatje. Een systeem kan niet geprogrammeerd

worden zonder een plan of op zijn minst een idee en het kan niet worden getest voordat het is geprogrammeerd.

Verder kan het niet worden vrijgegeven voordat het is getest en bevindingen zijn opgelost. Naarmate het testen,

programmeren en ontwerpen nauwer met elkaar verweven zijn, worden de cirkels korter. Echter, dezelfde

activiteiten blijven: plan, do, test and act.

Statisch testen, oftewel het reviewen van documentatie, is onderdeel van de documentatie-verbetercirkel. Aangezien

we documentatie gebruiken als het plan in de software-verbetercirkel, is reviewen een zeer rendabele vorm van

testen. Op basis van de ontwerpdocumentatie wordt het systeem geprogrammeerd; het plan wordt uitgevoerd. Dan

is het weer onze beurt.

Test en check

Ook in test-driven development, waar de test eerder bestaat dan de code, moet de software geschreven zijn om de

test te laten slagen. Je zou kunnen zeggen dat deze ‘test’ dan eigenlijk twee functies vervult; het is een plan

voorafgaand aan het programmeren en een check achteraf. Hetzelfde is het geval bij Specification by Example

(Adzic, 2011). Zonder hier al te diep in te gaan op het verschil tussen ‘check’ en ‘test’ durf ik te stellen dat er in elk

software-voortbrengingsproces momenten zijn waarop we het product, zoals het op dat moment is, uitgebreider

willen bekijken dan mogelijk is met behulp van, al dan niet geautomatiseerde, checks. In de woorden van Bach

(2013): The essence of testing is to shine light so that others do not have to work in darkness. This is not merely

the fun of waving a torch at night, but shining that light with purpose; as a service.

Pagina 41

Een onderdeel van dynamisch testen is controle (check). Wanneer we tests doen om te bevestigen dat software zich

gedraagt volgens de specificaties, dan controleren we. Een ander deel van dynamisch testen is niet-bevestigend. Dit

is het soort van tests dat is bedoeld om zwakke plekken op te sporen. Beide soorten tests, bevestigend en niet-

bevestigend, zijn waardevol en ze vullen elkaar aan. Wel dienen ze elk een ander doel en moeten we ze ook anders

beoordelen.

Test de testers

Om de kwaliteit van het testproces te optimaliseren, wil je de beste testers in je team. Voor niet-bevestigende tests

zijn dat degenen die de meeste fouten vinden en daarbij de belangrijkste fouten eerst. Als je kunt kiezen uit meerdere

kandidaten, geef ze dan een stuk werkende software met bijbehorende documentatie en kijk wat er gebeurt. Zorg

ervoor dat je weet welke fouten er in deze software zitten.

Zodra testers onderdeel zijn van het team, mogen aantallen bevindingen geen rol meer spelen. Dit zou hen alleen

motiveren om te gaan voor eenvoudige bevindingen en om variaties van dezelfde bevinding afzonderlijk te melden.

Als testers zich druk maken om hun bevindingentelling, zullen ze geen verbeteractiviteiten ondernemen (Kaner en

Bond, 2004).

Bevindingentellingen kunnen wel gebruikt worden in coachingsessies, maar alleen om testers te helpen om beter in

hun werk te worden. Om duidelijk te maken dat het aantal bevindingen niets te maken heeft met beloning, is het

raadzaam om testers te coachen op basis van hun prestaties in een gecontroleerde omgeving die geen onderdeel

uitmaakt van hun dagelijkse werkplek. Test testers regelmatig en maak verbeterplannen op basis van hun prestaties.

Bevestigende testers zijn niet gericht op het doen van bevindingen, maar op het aantonen dat de software zich

gedraagt volgens specificaties. Het opzetten en uitvoeren van, al dan niet geautomatiseerde, checks vergt een

andere instelling: ‘zien dat het werkt’ tegenover ‘van alles verzinnen om te zien dat het soms ook niet werkt’. Ieder

van ons heeft beide kanten in zich en het hangt af van de omstandigheden en de persoonlijke voorkeur welke kant

zich meer ontwikkelt. Soms is laten zien dat het kan werken het hoogst haalbare, bijvoorbeeld in een end-to-end

test van een complexe keten. Op een ander moment heb je misschien de tijd om één systeem uit die keten uitgebreid

te bekijken. En wat vind je leuker?

Test de test

Ook het testen zelf is te beschouwen als een verbetercirkel. We maken een plan, een zogenaamd testplan (mogelijk

uitgewerkt in een gedetailleerd testscript of niet meer dan een verzameling globale testideeën), en voeren dat uit.

De testuitvoering is de fase ‘test’ uit de software-verbetercirkel, maar ook de fase ‘do’ uit de test-verbetercirkel.

Vervolgens is het tijd om ons eigen werk kritisch te (laten) beoordelen.

Software wordt bijna nooit in één keer goed gemaakt. Dat is ons bestaansrecht. Ook wij kunnen niet altijd alles goed

doen. Iedere werkdag maak je vele keuzes en die zijn niet allemaal optimaal. Als je jezelf betrapt op fouten,

vergissingen of slordigheden, dan zijn dat kansen om te leren. Als je geen fouten maakt, of je daar niet van bewust

bent, dan blijf je doen wat je altijd deed. Als je een fout kunt toegeven, dan zul je die niet snel weer maken.

Fouten zijn dus ook goed, zelfs fouten in productie. Deze zijn bij uitstek input voor testprocesverbetering. Als blijkt

dat we een bevinding gemist hebben, is dat een uitgelezen kans om iets te leren. Soms pakt een testfout ook juist

heel goed uit. Wie heeft niet ooit per ongeluk een bevinding gedaan? Ik geloof dat je in de testuitvoering de vrijheid

moet nemen om je intuïtie te volgen en te ontwikkelen. Daarbij zijn fouten onvermijdelijk. Zolang we fouten mogen

maken om daarvan te leren zal het testproces als geheel ook verbeteren.

Pagina 42

Geef ook anderen de kans om jouw werk te beoordelen. Laat ze meekijken en vertel wat je doet en waarom. Je hebt

immers weinig te verliezen, maar veel te winnen met de feedback van anderen.

Referenties

Bach, J.M. (samen met Bolton, M) (2013), Testing and Checking Refined,

http://www.satisfice.com/blog/archives/856.

Adzic, G. (2011), Specification by Example, Manning Publications Co., Shelter Island NY, USA.

Deming, W.E. (1986), Out of the Crisis, MIT Press, Cambridge MA, USA.

Kaner, C. and Bond, W.P. (2004), Software Engineering Metrics: What Do They Measure and How Do We Know?

10th International Software Metrics Symposium.

CARTOON

Door Gerard Numan ● gerard.numan@polteq.com

Pagina 43

HOE MAAK JE KWALITEIT VAN IT-IMPLEMENTATIES WEL MEETBAAR...

Door René Ceelen ● rceelen@forusity.com

Het succes van de implementatie van een nieuw informatiesysteem wordt bepaald door de

acceptatie van het systeem door de eindgebruikers. Hoe accepteer je nu een softwaresysteem

vanuit eindgebruikersperspectief, hoe betrek je die gebruikers er op de beste wijze bij? ‘De

softwareleverancier test toch?’ ’Wij hoeven niet te testen, omdat wij voor een standaard ERP-

systeem kiezen?’ ’Het accepteren van het systeem vindt pas over negen maanden plaats,

omdat dan de testen pas gepland staan!’ Veelgehoorde opmerkingen, waardoor beslissers in

de praktijk nut en noodzaak van deze acceptatie-‘sluitpost’ flink onderschatten. Het accepteren

van IT-implementaties begint immers bij de eerste ontwerpen en niet pas wanneer het

acceptatietesten ‘in de planning’ staat.

Bij veel klantgerichte, middelgrote organisaties vormt ERP-achtige pakketsoftware de kern van de

informatievoorziening. In feite is de volledige bedrijfsvoering van de organisatie afhankelijk van het functioneren

van het informatiesysteem. Veel organisaties onderschatten niet alleen de complexiteit van het informatiesysteem

(met vaak talrijke integraties) maar ook de complexiteit van hun eigen organisatie: vele verschillende rollen en

verantwoordelijkheden, verschillende typen klantcontacten, door elkaar lopende processen en dergelijke.

Onvoldoende realiseren deze bedrijven zich dat zij niet of nauwelijks meer in staat zijn om de kwaliteit van het

informatiesysteem in relatie tot de organisatie te beheersen.

Het testen daarvan is domweg een te tijdrovende en te gespecialiseerde klus geworden. Het implementeren van dit

type informatiesystemen in organisaties is zoals het vervangen van een onderdeel in het zenuwcentrum van een

menselijk lichaam: het grijpt diep in en fouten zijn meteen voelbaar. Goed vormgeven van een acceptatietest is

derhalve geen sinecure; complexiteit van organisatie en informatiesysteem (en de samenhang daartussen!) vraagt

om een aanpak waarvoor de standaard testmethoden vaak geen oplossing bieden.

En het in productie nemen van informatiesystemen, die misschien wel werken, maar waarmee niet te werken valt,

leidt tot de nodige frustratie bij de eindgebruikers en ook

flinke extra herstelkosten om de ‘touwtjes’ weer aan

elkaar te knopen. Voor het falen van IT-projecten worden

vele onderzoeken gedaan vanuit verschillende

perspectieven met daarbij uiteenlopende beredenering,

zoals gebleken in de lopende parlementaire enquête over

falende ICT-projecten bij de overheid. In dit artikel richt

ik me op het ontwerpen en uitvoeren van een

gestructureerde acceptatietest, weergegeven in het schema rechts.

Ontwerpen

Het ontwerpen van een goede acceptatietest begint al met het feit dat helder moet zijn wat de businesscase van het

IT-project is. De Standish Group doet al jaren onderzoek naar falende en succesvolle IT-projecten en komen al jaren

tot de conclusie dat betrokkenheid van management en eindgebruikers gecombineerd met heldere doelstellingen,

50% van de succesfactor bepalen. Maar ook onderzoeksbureau Gartner zegt niet voor niets dat

Pagina 44

het test- en acceptatieproces gemiddeld 50% van de al dan niet verborgen kosten van IT-implementaties uitmaakt.

Gartner stelt bovendien dat de ‘business-waarde’ van testen structureel wordt onderschat door het management.

Voor de acceptatie van een IT-implementatie moet op twee vragen een positief antwoord komen: ‘Werkt het?’en

‘Kun je ermee werken?’. Vaak wordt alleen op de eerste een positief antwoord gegeven en pas in productie wordt

de tweede vraag beantwoord. En hopelijk ook positief!

Voor de definitie van kwaliteit hanteren we de meest gebruikte en tevens meest eenvoudige definitie van Juran:

‘geschiktheid voor gebruik’. Zwaartepunt ligt bij de acceptatiebeleving van de eindgebruikers: 'Geschiktheid voor

gebruik' wordt niet alleen ervaren vanuit functionaliteit van het informatiesysteem, maar ook vanuit de

organisatorische impact en verandering.

Wereldwijd zijn meer dan vierhonderd gereedschappen beschikbaar waarmee bedrijfsprocessen volgens een

bepaalde methode kunnen worden gemodelleerd. Of het nu gaat om het vastleggen van processen ter verkrijging

van het ISO-certificaat, veranderingen in het kader van business process redesign (BPR) of het leggen van de basis

voor de bouw en inrichting van softwaresystemen: alle methoden gaan uit van een model dat de bedrijfsprocessen

van de huidige of gewenste organisatie volledig beschrijft. In de praktijk komt het vaak voor dat er kasten vol papier

met procesbeschrijvingen worden voorgelegd, waarbij de organisatie zelf al discussies heeft over de juistheid en

eenduidigheid. Hoe moet de softwareleverancier deze processen dan correct inrichten en integreren in het

informatiesysteem? Andersom geeft de installatie van een ‘standaard ingericht’ ERP systeem de nodige frictie aan

de organisatorische kant: het systeem bepaalt te veel de werkwijze van de organisatie. Iedereen die bij

implementaties van informatiesystemen betrokken is kent dit dilemma. Er is daarom grote behoefte de te

ondersteunen bedrijfsprocessen ondubbelzinnig en voor alle stakeholders begrijpelijk in kaart te brengen. Deze

beschrijving kan dan als kapstok worden gebruikt om de vervolgstappen te bepalen. Óf het softwaresysteem

inrichten naar de processen, óf de organisatie inrichten naar de meegeleverde ‘standaard inrichting’ van het

softwaresysteem.

Er is geen ‘beste’ methode om bedrijfsprocessen in kaart te brengen, maar door het gebruik van DEMO (Design &

Engineering Methodology for Organizations) kunnen de bedrijfsprocessen op een globaal niveau worden opgezet. Dit

leidt tot een zuivere afweging over nut en noodzaak waarbij niet alle discussies gaan over details die er in de basis

nog niet toe doen. Met DEMO beschrijf je de essentie van een organisatie, volledig onafhankelijk van de

daadwerkelijke realisatie en implementatie. De essentie is stabiel en altijd up-to-date, omdat het alleen de geleverde

producten (of services) laat zien in relatie tot de bijbehorende transacties en actoren.

DEMO bestaat uit drie gelaagde aspectorganisaties, ook wel systemen genoemd: B-systeem (business), I-systeem

(informatie) en D-systeem (documentatie). De totale organisatie is samengesteld uit deze drie systemen, waarbij

de actoren in het B-systeem originele (nieuwe) feiten creëren door met elkaar afspraken aan te gaan over de levering

van producten en diensten. De processoren in het I-systeem bewerken bestaande originele feiten tot

informatieproducten zoals rapportages, jaarrekeningen, overzichten en dergelijke. Het I-systeem is ondersteunend

aan het B-systeem, dat wil zeggen actoren in het bedrijfsproces (B-systeem) gebruiken het I-systeem ter

ondersteuning van hun onderlinge communicatieve acties (het aangaan en nakomen van afspraken) en van hun

besluitvorming. De operatoren in het D-systeem zijn de ondersteuners van het I-systeem door middel van

infrastructuur, zoals e-mail en databasemanagementsystemen, maar ook alle elektronische formulieren waar

mensen in de organisatie dagelijks mee werken. Bij elke verandering binnen de organisatie (functioneel, maar

Pagina 45

ook in relatie tot ICT) worden één of meerdere systemen (aspectorganisaties) ‘geraakt’. Het implementeren van een

nieuw ERP-systeem heeft met name betrekking op de I-aspectorganisatie en op de D-aspectorganisatie. Indien een

nieuw product of service wordt geïntroduceerd heeft dit vooral invloed op de B-aspectorganisatie.

Binnen de drie aspectorganisaties is er sprake van twee (systeem)oriëntaties: functie en constructie. Vanuit de

functieorientatie wordt gekeken door de bril van de gebruiker van het systeem. Het systeem wordt in beschouwing

genomen als black box, alleen vanuit het perspectief ‘gedrag’. Kijkt men vanuit de constructieorie ntatie, dan wordt

gekeken door de bril van de bouwer. In dat geval wordt het systeem beschouwd als een white box: hoe het systeem

inwendig werkt en is samengesteld. Vanuit de B-aspectorganisatie kent DEMO vier hoofdmodellen: het

communicatiemodel (CM), het procesmodel (PM), het actiemodel (AM) en het toestandsmodel (SM). In dit artikel

gebruiken we alleen de modellen CM en PM, waarbij binnen het PM ook het transactieprocesmodel (TPM) wordt

gehanteerd. Figuur 2 laat zien hoe de samenhang van de systemen (aspectorganisaties) is ingericht in relatie tot de

modellen.

Figuur 2: systemen en modellen

In het eerste model, het communicatiemodel, worden de essentiële transacties en hun onderlinge samenhang

beschreven in compacte vorm (1 A4-tje). Het communicatiemodel geeft de constructie van de organisatie aan. Over

deze röntgenfoto moet consensus bestaan, omdat dit model de basis vormt voor de organisatorische inrichting, de

vertaling richting ICT en de daadwerkelijke toetsing van de kwaliteit van het informatiesysteem en de (bijbehorende)

organisatieverandering. Figuur 3 laat twee transacties uit dit model zien, waarbij de initiërende partij (actor A) een

verzoek doet (T01) aan de uitvoerende partij (actor B). De uitvoerende partij krijgt in deze schrijfwijze een zwart

vierkantje op de lijn.

Figuur 3: transacties met actoren

Binnen een transactie (T01) zit een aaneenschakeling van 5 statussen: (1) A verzoekt aan B; (2) B belooft aan A;

(3) B voert uit; (4) B verklaart aan A en (5) A accepteert van B. Elke transactie in het communicatiemodel

Pagina 46

bevat deze statussen. In het procesmodel wordt vervolgens de volgorde en samenhang van de onderliggende

transacties zichtbaar gemaakt. Hiermee wordt bedoeld dat bijvoorbeeld transactie T02 pas kan starten als transactie

T01 is afgerond, et cetera. Elke transactie heeft dus eenzelfde patroon van verzoekt - belooft - uitvoering - verklaart

- accepteert. Dit patroon wordt het ‘succespad’ van een transactie genoemd, omdat het verzoek altijd wordt

afgesloten met een acceptatie. In de praktijk is dat helemaal niet altijd zo. Er kan immers na een verzoek discussie

ontstaan over het verzoek of voor de acceptatie discussie ontstaan over hetgeen is uitgevoerd. Het

transactieprocesmodel (TPM) omvat naast het ‘succespad’ ook een universeel ‘niet-succespad’. In dit ‘niet-succespad’

ontstaat discussie over het wel of niet aannemen van een transactie en in het slechtste geval kan de transactie in

zijn geheel worden stopgezet. Samengevat geeft het transactieprocesmodel in één keer zo’n 23 statussen weer. Het

transactieprocesmodel reduceert daarmee op eenvoudige wijze de complexiteit van communicatie en de daarbij

mogelijke systeemfouten. In figuur 4 zie je één transactie tussen twee actoren met zijn ‘succespad (groen)’ en ‘niet-

succespad (oranje, rood)’ in zijn geheel.

Figuur 4: transactieprocesmodel met universele statussen

De complexiteit van de organisatie wordt door deze manier van modelleren enorm vereenvoudigd. Er is immers een

essentieel model ontstaan, in de ‘taal’ die iedereen in de organisatie kan verstaan. Op basis van dit

transactieprocesmodel kan dus op essentieel niveau een uitgebreide set van gedetailleerdere testscripts worden

beschreven, omdat alle ‘niet-succespad’ statussen vooraf al gedefinieerd zijn. Bovendien zijn de testscripts opgesteld

vanuit een gemeenschappelijk begrip van de organisatie en niet vanuit het informatiesysteem.

Pagina 47

Uitvoeren

De ontwerpen bepalen uiteindelijk de kaders van waarop ‘de kwaliteit’ meetbaar gemaakt kan worden. En op basis

van de bovenstaande werkwijze ontstaat eenvoudig een essentieel acceptatie(test)model. Zoals figuur 1 van de

totale methode laat zien is het samenspel tussen de fasen ontwerpen en uitvoeren een cyclisch proces, omdat een

ontwerp van het essentiële model een uitstekend fundament vormt, maar bij de uitvoering op onderdelen meer

detail nodig zal hebben en dus weer verfijnd ontworpen moet worden.

Zoals de Standish Group concludeert bepaald de betrokkenheid van eindgebruikers 20% van je succesfactor. Saillant

detail is dat 86% van de executives van deze IT-projecten het in meer of mindere mate moeilijk vindt om

eindgebruikers een rol te geven. Uit onze ervaring blijkt dat juist deze groep wel een rol wil invullen, maar door twee

primaire redenen niet of te laat betrokken wordt:

1. Het ontwerp van de acceptatietest te veel vanuit functionaliteit is ingericht, wat deze groep lastig aanspreekt. En

het daardoor moeilijk vindt om tijdens het testen ook het werkproces te beoordelen.

2. Het gereedschap voor het registreren van bevindingen te ingewikkeld of te arbeidsintensief is. Deze groep is

immers geen professionele tester noch professionele ontwikkelaar.

Testen met en door eindgebruikers vergt een andere aanpak dan testen met IT-professionals. Gebruikers kijken

immers vooral naar hoe het informatiesysteem hun feitelijke werkzaamheden ondersteunt. En ze willen kunnen

testen zonder zich eerst in een testhulpmiddel te moeten verdiepen. Maar ook bij functioneel testen met professionals

wil je snel aan de slag zonder overbodige ballast.

Juist daarom hebben we Forusity ontwikkeld. Een hulpmiddel om vanuit het proces door de gebruiker de technologie

op haar werking te laten beoordelen op een eenvoudige intuïtieve manier. Een hulpmiddel dat niet alleen ondersteunt

bij een nieuwe implementatie, maar gedurende de hele levenscyclus van het informatiesysteem. Hierdoor krijg je

snel inzicht in waar de organisatie en IT geoptimaliseerd kunnen worden op hun werking.

Alle testresultaten worden vanuit één grote bak gecategoriseerd en gebundeld in issues of bevindingen. Hiermee

creëer je een scheiding tussen hetgeen een eindgebruiker vindt en wat er daadwerkelijk moet worden opgepakt. En

juist dit centrale bevindingenbeheer is cruciaal, omdat bij grote IT-projecten altijd meerdere stakeholders (externe

leverancier A, externe leverancier B, interne procesoptimalisatie werkgroep, conversie werkgroep, et cetera)

betrokken zijn met hun eigen verantwoordelijkheden. Zonder centraal bevindingenbeheer met duidelijke

verantwoordelijkheden en afspraken vliegen de ‘Excel’-lijstjes je om de oren met ieder een eigen perspectief en

krijgt de opdrachtgever zelden een concreet feitelijk rapport met de werkelijke status van het project.

Conclusie

Uit eigen onderzoek is bovendien gebleken dat het organiseren en inrichten van de gebruikersacceptatietest met

deze gestructureerde werkwijze qua resultaten een beter resultaat geeft ten opzichte van de huidige

praktijkmethoden. Figuur 5 laat zien dat er twee verschillende acceptatietesten zijn uitgevoerd. Eén op basis van de

DEMO denkwijze (EO) en één op basis van ‘best practice’ (T) op hetzelfde onderdeel van het ERP-systeem. De

testresultaten zijn gecategoriseerd op basis van vooraf opgestelde kwaliteitscriteria, welke zwaarder wegen

naarmate het belang van het toepassingsgebied groter is.

De vergelijking van de beide testmethoden laat zowel overeenkomsten als (verrassende) verschillen zien. Op basis

van beide testmethoden kan de conclusie worden getrokken worden dat het informatiesysteem de nodige

Pagina 48

risico’s met zich mee zou brengen op het gebied van de financiële functionaliteit. Bij gebruik van de EO methode is

het resultaat van op het criterium ‘herleidbaarheid’veel gedetailleerder (en slechter …), doordat het

transactieprocesmodel standaard de universele ‘niet-succespad’ statussen beschrijft. Het verschil bij het

acceptatiecriterium ‘stabiliteit’heeft te maken met de gedetailleerdere acceptatietestscripts die ontstaan op basis van

de DEMO werkwijze. Naast de ‘harde’ resultaten merkten we tijdens het proces dat door het gebruik van het

communicatiemodel een meer zuivere discussie plaatsvond over wat nu wel of niet essentieel was.

Figuur 5: resultatenvergelijking van de twee acceptatietestmethoden

Samengevat kunnen we concluderen dat het nut en noodzaak van een gedegen acceptatietest belangrijk is. De

samenhang van de complexiteit van zowel organisaties als informatiesystemen is zonder methodische aanpak niet

meer te beheersen. De acceptatietest is daarom geen sluitpost meer van een project, maar een integraal onderdeel

van het gehele project. Door het ontwerpen van de acceptatietest al eerder in het project een prominente rol te

geven en gebruik te maken van methoden en technieken uit de Enterprise Engineering hoek ontstaan meer zuivere

discussies over hoofd- en bijzaken voor alle betrokken. Daarnaast zullen eindgebruikers meegroeien in het project

door de gestructureerde manier van modelleren en de afgeleide werkwijze om testscenario’s en –scripts te maken.

Naast de betere testresultaten zullen de eindgebruikers een grotere acceptatie hebben van zowel het ERP-systeem

als de ‘nieuwe’ organisatie, wat uiteindelijk zal leiden tot minder kosten.

Literatuur:

● Boehm B. / Englewood C., Software Engineering Economics. NJ : Prentice-Hall, 1981

● Ceelen R, Acceptatie van een IT systeem, Informatie 6-2013, p 44-49

● Ceelen R. / Metz L., Procesgestuurd testen met een hogere dekkingsgraad, Informatie 6 2009, p 22–27

● Dietz J.,Enterprise Ontology - Theory and Methodology. Springer, 2006

● Dipten E. Van/ Mulder H., Basic Enterprise Engineering Map, Informatie 10-2011, p. 54-61

● Standish Group. Chaos, tech. report. Technical report, Standish Group Int’l, 2013

● www.demo.nl

Pagina 49

TESTEN: HOUDING EN SOCIALE VAARDIGHEDEN MAKEN HET VERSCHIL

Door Erik van Veenendaal ● eve@improveqs.nl @ErikvVeenendaal

Early in the morning factory whistle blows

Man rises from bed and puts on his clothes

Man takes his lunch, walks out in the morning light

It's the working, the working, just the working life

(Factory [1978], Bruce Springsteen).

Luister eens naar de tekst en proef de treurnis in dit lied en de stem van Bruce

Springsteen. Hij zingt over zijn vader, die elke dag naar zijn werk gaat om geld te

verdienen, maar hier totaal geen plezier aan beleeft. Juist dit nummer doet me

denken aan een bepaald type tester, die ik in de afgelopen jaren regelmatig ben

tegengekomen. Deze testers zijn (helaas) notoire klagers; ze klagen altijd en zijn

bijna nooit positief:

Ik kan dit niet testen, want de requirements zijn niet compleet;

De testomgeving is niet beschikbaar en er is niemand die me dat heeft

verteld;

Testen wordt hier nooit serieus genomen;

Niemand vertelt me ooit dat er veranderingen zijn aangebracht in de software;

Wij zijn altijd de klos omdat we op het einde van het traject zitten;

Het management is toch niet geïnteresseerd in kwaliteit;

…

Calimero

Deze testers denken altijd in termen van problemen en zitten heel sterk in de ‘wij versus hen’ modus. Het is nooit

de schuld van de tester, maar altijd die van iemand anders. Ze hebben medelijden met zichzelf. Ik kan werkelijk

niet begrijpen dat deze testers het kunnen opbrengen om

elke dag weer naar kantoor te gaan, te gaan werken in hun

‘fabriek’. In sommige organisaties worden deze mensen

aageduid als Calimero’s. Immers, Calimero klaagt of zeurt

ook altijd, maar is zelf nauwelijks in staat om iets tot een

goed einde te brengen.

Uiteraard hebben managers een hekel aan deze

Calimero’s. Ze willen oplossingsgerichte medewerkers die

een positieve bijdrage leveren. Ze hebben al genoeg aan

hun hoofd, zonder dat ze zich ook nog eens druk zouden

moeten maken om de problemen van de tester.

Zij zijn groot en ik is klein en dat is niet eerlijk, oh nee!

Pagina 50

De Calimero-type tester is ook bijna altijd van mening dat het systeem niet goed genoeg is om te accepteren. Ze

richten zich vooral op dingen die niet (volledig) werken, in plaats van aandacht te hebben voor de risico’s die

inmiddels afgedekt zijn en de onderdelen die wel klaar zijn voor acceptatie en release. Hun rapporten worden

nauwelijks gelezen en het lijkt erop dat deze testers voor een groot deel slechts worden getolereerd binnen een

organisatie. De mensen om hen heen hebben het opgegeven met hen in discussie te gaan: ‘Ja, we weten het, maar

blijkbaar is dit de typische manier waarop testers zich gedragen.’

Herken je hier iets van bij jezelf in bovenstaand? Ben jij misschien een Calimero, of wellicht gedeeltelijk? Mocht dat

zo zijn, maak je (nog) niet al te veel zorgen; je bent namelijk met een grote groep. Maar lees vooral verder! Dit

geldt overigens ook als je dit niet bij jezelf herkent; wie weet kun je deze column geven aan één van je collega

testers! Natuurlijk schets ik het hier allemaal erg zwart-wit. Maar ik hoop ik dat het op deze manier een ‘wake-up

call’ wordt voor sommige testers.

En jij?

And in the lonely cool before dawn

You hear their engines roaring on

But when you get to the porch they're gone on the wind

So Mary climb in

It's a town full of losers

And I'm pulling out of here to win

(Thunder Road [1975], Bruce Springsteen)

Juist dit nummer, zo vol energie, heeft me al vaak geïnspireerd in actie te komen, beslissingen te nemen, zaken op

te pakken en positief te zijn over de dingen die ik doe. Natuurlijk is er een manier om eruit te komen; get a grip!

Kom uit die luie stoel en verander je gedrag. Uiteraard is dat makkelijker gezegd dan gedaan. Ik stel voor dat je

eerst een stapje terug doet en begint met het opstellen van een persoonlijk testmissie. Waarom test je eigenlijk?

Wat vind je zo leuk aan testen? Welk type testen vind je leuk? Wat zou je willen bereiken? En, heel belangrijk, ‘Wat

geeft je energie?’ en ‘Waar word jij nou echt blij van?’ Maak het concreet en probeer een paar persoonlijke doelen

te definiëren gebaseerd op deze zelfevaluatie. Documenteer je persoonlijke testmissie en bespreek het met vrienden,

(test)collega’s en (als je dat wilt) met management (bijvoorbeeld bij een evaluatiegesprek).

Misschien ontdek je wel dat er voor jou te weinig leuke aspecten aan testen zitten. Mocht dat zo zijn, stop ermee.

Misschien is testen geen echt carrièrepad binnen jouw organisatie en zal het dat ook nooit worden. Als je echt een

professioneel tester wilt worden, vertrek dan en ga naar een andere organisatie. Het economische klimaat wordt

weer gunstiger en biedt mogelijkheden. Er zijn altijd redenen om iets niet te doen en in je ‘comfort zone’ te blijven.

Maar wil jij Bruce’s factory worker zijn? Kom in actie. Dit is jouw (test) leven; start met veranderen vandaag!

Denk in termen als doelstellingen en uitdagingen in plaats van problemen. Verdien het respect van management

door een probleem niet alleen te benoemen, maar het aan te pakken en op te lossen. Natuurlijk is het leven van

een tester niet altijd even makkelijk, maar het biedt ook veel leuke uitdagingen. Ga van ‘wij versus hen’ naar ‘wij

samen met hen’, probeer constructief samen te werken met ontwerpers, gebruikers en management. Sociale

vaardigheden worden steeds belangrijker en geen enkel Agile team wil een Calimero hebben. Zonder aanpassingen

zul je eenvoudigweg niet overleven in deze nieuwe wereld en alle leuke dingen en uitdagingen missen.

Pagina 51

Natuurlijk kan de (test)organisatie een bijdrage leveren aan dit proces, bijvoorbeeld door erkenning van het testvak

en het aanbieden van een carrièrepad voor testers. Randy Rice heeft onlangs tijdens de STAREAST conferentie een

aantal suggesties gedaan om je team te demotiveren (zie kader). Maar uiteindelijk komt het er toch op neer dat de

tester zelf in actie moet komen en zich anders moet gaan gedragen. Alleen jij kunt het verschil maken!

Stel onredelijke, bijna onhaalbare doelen om te zien hoe hard mensen willen werken.

Leg nooit uit waarom je tot een bepaalde beslissing bent gekomen.

Geef testers zinloze taken.

Ook al is iets goed gedaan, lever altijd kritiek.

Eis zelf als manager alle ‘credits’ op.

Los problemen op met allerlei bureaucratische processen.

Luister…, maar als een ‘brick wall’.

Doe niets met suggesties om het werk efficiënter te maken.

Behandel je team alsof het machines zijn die niet kapot te krijgen zijn.

Doen!

Toen ik artikel wilde schrijven dacht ik nog even dat het misschien aan mij lag; dat ik zaken te negatief zag. Echter,

toen ik dit besprak met een aantal (test)professionals bleek het toch iets te zijn wat heel veel mensen herkennen.

Kijkend naar dit gedrag kunnen we wellicht stellen dat er sprake is van onbewust onbekwaam incompetent. Hopelijk

zal aan aantal testers, na het lezen van deze column, met een open-mind overgaan naar bewust onbekwaam. Of

misschien en hopelijk in de nabije toekomst nog een stapje verder.

Luister eens naar beide nummers van Bruce Springsteen. Geniet ervan, maar let vooral ook op het grote verschil

tussen deze twee nummers. Laat je inspireren door de kracht en energie van ‘Thunder Road’ en probeer deze mee

te neme naar je dagelijks werk.

Pagina 52

SPREADSHEET TESTEN MET SPREADSHEETS

Door Ben Visser ● ben.visser@sogeti.nl

Wel ‘ns meegemaakt? ‘Klein’ foutje in het spreadsheet waardoor je budgetaanvraag er een

paar ton naast zat? Een paar ton te weinig, bedoel ik… En dat terwijl je het spreadsheet al tig

keer gebruikt had, en niet alleen jij: ook andere testmanagers gebruiken het al jaren. Wat

kan er mis zijn gegaan… ? Dikke kans dat ‘het misgaan’ zijn oorzaak heeft in ‘het al jaren

gebruiken’. Want ken jij de werking van spreadsheets van anderen precies? Weet je hoe de

drie, vier, vijf (meer?) verschillende tabbladen zijn ingedeeld, welke formules zijn gebruikt en

hoe alles met elkaar samenwerkt?

Wellicht vind je enige troost in de wetenschap dat je niet de enige bent die wordt verraden door een spreadsheet.

Surf eens naar http://www.eusprig.org/horror-stories.htm om voorbeelden van fouten met spreadsheets te vinden:

Olympische spelen van Londen - een simpele tikfout (20.000 in plaats van 10.000) resulteert in een

overboeking van 10.000 kaartjes voor enkele zwemevenementen.

Belastingen bij Kern County, USA - een olieveld van ruim 1 miljard dollar wordt ‘vergeten’ waardoor het County

12 miljoen aan belastingopbrengsten zou mislopen. Men ontdekte het net op tijd!

Engelse inlichtingendienst MI5 - bij het opvragen van persoonsgegevens van 134 telefoonnummers werden

door een formatteringsfout de laatste drie cijfers vervangen door nullen.

Het blijkt dat een spreadsheet een gemiddelde levensduur heeft van pakweg vijf jaar, met uiteindelijk gemiddeld

tien à twaalf gebruikers, die allemaal aanpassingen doorvoeren. In die periode ontwikkelt het spreadsheet zich van

een overzichtelijk rekenblad voor alleen de oorspronkelijke auteur (programmeur …?) tot een complex en

onoverzichtelijk programma van meerdere ontwikkelaars. Dat allemaal zonder dat er ooit een basisontwerp is

gemaakt, zonder dat het ooit is gereviewd, zonder dat het ooit zelfs is getest. Laat staan dat het ooit ge-regressietest

is.

Als we op die manier ‘echte’ software zouden ontwikkelen, dachten we wel drie keer na voordat we daar belangrijke

beslissingen op zouden baseren, … of we zoudende uitkomst minstens drie keer narekenen. En dat terwijl het

spreadsheet misschien wel het meest gebruikte testtool ter wereld is, uitstekend geschikt om ‘zichzelf’

geautomatiseerd te regressietesten. Wat denken we van de volgende pseudo-code, die prima in bijvoorbeeld VBA6

om te zetten is?

6 VBA = Visual Basic for Applications, de taal waarin Excel macro’s zijn geschreven.

Pagina 53

Ook bieden de meeste spreadsheets een breed scala aan ‘test features’. Denk bijvoorbeeld aan de auditfunctie in

Excel. En last but not least: laat je spreadsheet op tijd reviewen, … daar dringen wij als testers toch altijd op aan bij

‘de anderen’.

Spreadsheets zijn een sterk en laagdrempelig hulpmiddel bij vrijwel alles wat we doen, van prille schattingen tot

zeer gedetailleerde planningen, van testmanagement tot test-engineering. Laten we ons niet alleen bewust zijn van

de mogelijkheden van spreadsheets, maar ook van hun valkuilen én de mogelijkheden die het spreadsheet zelf biedt

om die valkuilen voor te zijn!

Open oude spreadsheet

Voer test input gegevens in

Laat spreadsheet alles doorrekenen

Bewaar berekende output gegevens

Sluit oude spreadsheet

Open nieuwe/aangepaste spreadsheet

Voer test input gegevens in

Laat spreadsheet alles doorrekenen

Bewaar berekende output gegevens

Sluit nieuwe/aangepaste spreadsheet

Vergelijk bewaarde output

Pagina 54

FOCUS OP VERBETERINGEN? ERVARINGEN VAN EEN EX-PERFECTIONIST

Door Irina Malgina ● irina.malgina@gmail.com

Er wordt in de testwereld vaak gesproken over testprocesverbetering. Bij veel bedrijven

hoor je dat alles beter, sneller, efficiënter en daarbij het liefst goedkoper moet… Maar hoe

leg je de focus op verbetering in een testteam? Hoe kan een Agile aanpak daarin een rol

spelen?

In de eerste jaren van mijn carrière was ik een perfectionist. Ik wilde alles 100% goed

doen en het liefst nog beter, perfecter. Op een gegeven moment kwam ik tot conclusie

dat dit veel tijd kost en helemaal niet zo handig is. Met de jaren heb ik het kunnen afleren

om alles perfect te willen doen. Perfect is niet altijd beter, goed is goed genoeg. Het is

belangrijk om de juiste prioriteiten te leggen. Ik heb mijn focus veranderd. Ik heb geleerd dat de focus gericht moet

zijn op verbetering, rekeninghoudend met de omstandigheden, met de beschikbare middelen, om een zo goed en

efficiënt mogelijk testproces in te richten. Daarbij ook nog passend bij de wensen en de situatie van de klant en het

project.

Hoe zet je de focus op verbetering?

Tijdens al mijn opdrachten probeer ik mijn focus te leggen op verbetering. Hoe doe je dat? Dat hangt natuurlijk van

het project, de situatie en je rol in het geheel af. Hieronder een aantal voorbeelden uit mijn praktijk.

Wat een testmanager/testcoördinator kan doen

Na elke release, projectfase of belangrijke mijlpaal een evaluatie houden waarbij input van jezelf, het testteam en

alle belangrijke stakeholders meegenomen en geëvalueerd wordt. Het moment van evaluatie kan verschillend zijn,

maar vaak hangt het samen met het schrijven van een testrapport. Wat

ging er goed? Wat kan beter? Wat gaan we concreet aan verbeteracties

oppakken in een volgende fase of release? Deze vragen lijken op de vragen

van de Scrum retrospective. Maar eigenlijk wordt het vaak ook in

traditionele projecten gebruikt. Mijn ervaring: waar het om gaat, is niet

alleen al die mooie verbeterpunten te benoemen, maar ook prioriteiten te

bepalen en concrete verbeteracties uit te zetten en te monitoren.

Wat een testanalist/tester kan doen

Evaluaties: bij de testcoördinator of testmanager aangeven dat het je als team zou helpen om regelmatig samen

een evaluatie te houden en stil te staan bij de mogelijke verbeteringen in het testproces. Wellicht zijn er

ergernissen binnen het team die weggenomen kunnen worden, of zien mensen onderdelen binnen het testproces

die efficiënter kunnen.

Concrete verbetervoorstellen: bij de testcoördinator of testmanager aangeven wat er concreet verbeterd kan

worden in het testproces en voorstellen hoe dat te realiseren is. Een paar voorbeelden: een meer integrale

aanpak tussen diverse nieuw opgezette Agile teams of een review proces voor de testdeliverables nadrukkelijker

opzetten.

Pagina 55

Het goede voorbeeld zijn: zelf het goede voorbeeld geven en proactief aan de slag gaan met verbeteringen. Een

voorbeeld uit mijn praktijk: het testteam was bezig met de testspecificaties voor een nieuwe functionaliteit. Het

was een reeds bestaand team, maar met verschillende niveaus van testkennis (testprofessionals en beheer) en

verschillende niveaus van systeem- en materiekennis. Daarnaast moest er een testtechniek worden gebruikt,

die voor de meeste testers nieuw was. Het testteam ging snel aan de slag, er werd voortgang gemaakt met de

testspecificaties. Dat was op zich mooi. Maar er bleef een aantal belangrijke vragen onbeantwoord. Zoals: wie

reviewt de testspecificaties? Hoe kan dat centraal worden opgezet? Na het uitvoeren van een review van enkele

collega’s, bleek dat niet iedereen binnen het testteam de toepassing van de testtechniek correct had begrepen.

Dat kon gebeuren, omdat er niet alleen professionele testers in het team zaten… Resultaat? De testgevallen

waren niet correct opgesteld. In een door mij aangedragen reviewronde werd dit in een vroeg stadium van het

testproces ontdekt. Daardoor waren er minder tijdrovende aanpassingen nodig.

Evaluaties en wederzijdse reviews hebben een positief effect op het testproces. De laatste jaren verovert Agile de

wereld en bij veel bedrijven wordt de Agile werkwijze ingevoerd. Het meest bekende is waarschijnlijk Scrum, maar

ook Kanban, XP en Lean worden bij sommige bedrijven gebruikt. Wat zijn de redenen voor succes en de

kernprincipes? Dat staat in het Agile Manifesto en Agile Principles beschreven. De meesten onder ons zullen deze

kennen.

Waarom Agile?

Agile is van nature gericht op verbetering. Met name het Scrum ontwikkelproces is zo opgezet, dat het Scrum-team

continu gestimuleerd wordt om zijn prestatie te verbeteren.

Scrum is incrementeel en iteratief. De hele opzet van een

Scrum-proces is faciliterend voor een verbeteringsgerichte

samenwerking binnen een team. Middels het opleveren van

werkende software in korte sprints met aan het einde van de

sprint een retrospective. Daarbij wordt een aantal punten

genoemd die goed gingen, die minder goed gingen en beter

kunnen, plus concrete verbeterpunten waar het team tijdens

de volgende sprint aan gaat werken. In de volgende

retrospective volgt een evaluatie of de verbeteracties goed zijn

uitgevoerd. Zo worden de teamprestaties steeds opnieuw

geëvalueerd en verder verbeterd.

Mijn eerste ervaring in een Scrum-team vond ik heel boeiend.

Ik had van tevoren veel over Scrum gelezen en cursussen gevolgd, maar toen was het moment aangebroken om

het zelf te ervaren in de praktijk. Het team was een mix van mensen met en zonder Agile of Scrum ervaring en als

nieuw team waren wij op zoek naar een manier om efficiënt samen te werken en het beste ervan te maken.

Hoe heb ik dat ervaren?

Tijdens de eerste retrospectives hebben we vooral motivatie, teamspirit en dergelijke als positieve punten genoemd.

Herkenbaar? In de eerste sprints waren er veel verbeterpunten te noemen. Scrum schrijft voor

om tijdens de retrospective verschillende aspecten te evalueren, zoals mensen, communicatie, processen, tools en

dergelijke.

Pagina 56

Een paar voorbeelden:

1. Whole team approach: als testers hebben we de neiging om het te testen systeem uitgebreid onder de loep te

nemen en diepgaand te kijken, om fouten geen kans te geven. Hierbij zijn productrisico’s leidend. Wij waren

allemaal nog zoekende naar een passende manier en juiste diepgang met betrekking tot het beschrijven van

user stories en het definiëren van testgevallen. Als bepaalde zaken niet zijn beschreven, zijn deze niet van

toepassing. Heeft de Product Owner hier wel over nagedacht of simpelweg vergeten? Of is het ‘vanzelfsprekend’

en wordt daarom niet beschreven? Bijvoorbeeld, het is niet genoemd dat de einddatum van een contract niet

voor de startdatum mag liggen. Vanuit min of meer traditionele projecten zijn we gewend dat de requirements

en specificaties vastgelegd moeten zijn en op basis daarvan creëren we testgevallen. Het was heel erg zoeken

naar de juiste balans. Uiteindelijk hebben we geconcludeerd dat het beter is om het hele team, dus ook de

ontwikkelaars mee te nemen in het vaststellen van testdiepgang en frequenter te communiceren met elkaar, zo

vroeg mogelijk in het proces. Als verbeterpunt is gedefinieerd dat alle testspecificaties gereviewed moeten

worden door een ontwikkelaar. Tijdens die review bepalen we samen als team en in overleg met de Product

Owner welke aspecten (bijvoorbeeld welke validaties) belangrijk zijn. Deze moeten zowel door ontwikkelaars als

door testers worden meegenomen (ontwikkelt en getest). Zo waren wij constant aan het communiceren met

elkaar. Wij waren telkens een stap voor ten opzichte van een eerdere situatie: ontdekken van fouten tijdens de

testuitvoering en pas dan daarover communiceren. Voor ons team werkte dat goed!

2. Communicatie: in diverse sprints kwam naar voren dat de communicatie binnen het team toch niet optimaal

was. Van simpele zaken zoals doorgeven dat je even wat later bent, tot afstemming over acceptatiecriteria die

niet duidelijk genoeg zijn.

3. Beschikbaarheid van de Product Owner en deze er beter bij betrekken. Dit is een cruciaal punt om het Scrum-

project tot een succes te maken.

4. Tooling: we maakten gebruik van Kunagi (freeware tool bedoeld voor Scrum-teams) waar ook een bugtracking

functionaliteit in zit. Hoewel voor de ondersteuning van het Scrum-proces deze tool goed geschikt leek te zijn,

was het niet handig voor defect management. Er ontbraken bijvoorbeeld defect statussen (zoals ready for test).

Prioriteren van bevindingen was ook niet standaard voorzien. Wij moesten er creatief mee omgaan en hadden

zelfs emoticons gebruikt als workaround om de prioriteit van bevindingen aan te geven. In de ideale situatie, al

in begin van het project (Iteratie 0) had er een gefundeerde toolkeuze moeten worden gemaakt. Hier koos men

gewoon een tool uit om alvast een start te maken. Een herziening van de toolkeuze was daarom vaak het

onderwerp van verbetervoorstellen geweest binnen ons Scrum-team.

5. Documentatie: dit is vaak een discussiepunt in nieuwe Agile teams. Hoeveel documentatie moeten we opleveren?

‘Just enough documentation’, dat leer je in de Agile training. Maar wat betekent dat in praktijk? Op een gegeven

moment is het ons opgevallen dat er veel documenten op de SharePoint stonden die niet actueel waren. Er werd

een actie ingepland om alle documenten te checken of ze relevant zijn en toegevoegde waarde in het project

hadden. Is het document relevant? Dan up-to-date houden. Document niet relevant – dan archiveren.

Alle punten werden besproken om vervolgens gezamenlijk een keuze te maken welke concrete punten binnen de

volgende sprint opgepakt moesten worden door het team. Per sprint werden er in overleg enkel twee belangrijkste

verbeterpunten geselecteerd. Dat bevorderde ook de samenwerking. We begrepen elkaar beter en uiteindelijk

werden we succesvoller als team. Door het iteratieve proces kwamen we steeds terug op een evaluatie van onze

prestaties en gedefinieerde verbeteringen. Na een aantal sprints zag je dat het team steeds beter op elkaar

afgestemd raakte en zowel de team spirit als velocity steeds hoger werd.

Pagina 57

Hadden wij dit soort verbeterpunten ook zonder Scrum en de retrospectives

geïdentificeerd en opgepakt? Ik denk het wel. Dit hangt veel af van de mensen die

in het team zitten. Scrum helpt in ieder geval om een bepaalde structuur en richting

te geven aan de focus om continu verbeteringen vast te houden.

Conclusie

Als je de focus wilt leggen op verbetering en die focus wilt houden (binnen een team)

is een aantal zaken belangrijk:

‘Verbetering trekker’ (teamlead, testcoördinator, testanalist - iemand die deze rol op zich wil nemen) om de focus

op verbetering binnen het team te leggen en te stimuleren. Door dit aan te geven in meetings, face-to-face

gesprekken, door regelmatig evaluaties te houden, concrete verbeterpunten te bepalen en de uitvoering daarvan

te volgen.

Team members die daar open voor staan en allemaal willen bijdragen aan continue verbetering... Idealiter speelt

iedereen de bovengenoemde rol.

De gekozen ontwikkelmethode kan een rol spelen. Met Scrum wordt het team niet alleen zelfsturend en zelf

organiserend, maar ook verbeteringsgericht.

Het is belangrijk om prioriteiten te stellen en keuzes te maken zodat gericht kan worden gewerkt aan de meest

relevante verbeteracties op dat moment.

Pagina 58

TESTEN? NATUURLIJK, DA’S LOGISCH. BIOLOGISCH!

Door Hans Vedder ● H.Vedder@cimsolutions.nl en Jacob Hooghiemstra ● J.Hooghiemstra@cimsolutions.nl

@test_biologisch

Begrippen als ‘sneller’, ‘beter’ en ‘steeds meer’ zijn momenteel hun

waarde aan het verliezen. Er is een kentering gaande, waarbij bewuste

keuzes en duurzaamheid vooropstaan. Daarnaast wordt de natuur

steeds vaker als inspiratiebron gebruikt. Deze trend heeft ook zijn

weerslag op de manier waarop wij testen. Verzuipen we soms niet in

onze eigen hoeveelheid aan (on)mogelijkheden in het hele testproces?

Biologisch testen gaat over de manier waarop wij een waardevolle

duurzame prestatie kunnen leveren op het gebied van testen, op basis

van bewuste keuzes. Testen wordt hierdoor ook nog eens een stuk leuker!

Biologisch Testen

Veel mensen kunnen het begrip ‘Biologisch Testen’ in eerst instantie niet helemaal

plaatsen. En dat is begrijpelijk: het bestaat nog niet zo lang. Bij Biologisch Testen wordt

het hele testproces vergeleken met het verbouwen en nuttigen van biologisch voedsel.

Het gaat hier niet over een nieuwe testaanpak, het wordt niet het zoveelste boek over

testen en het is allerminst een tijdelijke bevlieging. Biologisch Testen kunnen we typeren

aan de hand van de etymologie van de woorden ‘bio’, ‘logisch’ en ‘testen’ en dan komen we uit op ‘een natuurlijke

beproeving’. Om de parallel te kunnen trekken met biologische voedsel zal ik eerst even uitleggen wat dat precies

inhoudt, want dat blijkt voor veel mensen onduidelijk. Biologisch voedsel is voedsel dat is geproduceerd zonder

gebruik van kunstmest, chemische bestrijdingsmiddelen of gentechnologie. Bij biologische veeteelt wordt zo veel

mogelijk gewerkt met biologisch veevoer. Biologisch voedsel is bij ons te herkennen aan het Europese

certificeringslabel. Dat is ook wel nodig, want er is inmiddels voldoende ‘namaak’ in de winkels verkrijgbaar.

Kernwaarden

Hetgeen we van de biologische wereld kunnen leren, worden kernwaarden van het Biologisch Testen. Dat zijn:

Maak bewuste keuzes;

Gebruik je boerenverstand;

Start bij de wortels;

Geen onnodige toevoeging;

Denk duurzaam.

Zonder alle punten stuk voor stuk te behandelen kunnen we zeggen dat in de testwereld te weinig keuzes worden

gemaakt. Tja, er is wel een productrisicoanalyse, maar daar blijft het dan vaak ook bij. Er zou vaker stil moeten

worden gestaan bij het kiezen van het aantal uit te voeren testsoorten, de tools die gebruikt worden, de

testtechnieken en ook de testers zelf. Er wordt nog te vaak een stramien gevolgd, dat niet voldoet aan een specifiek

testtraject. En die tester, die al jaren op hetzelfde systeem werkt, is ook wel eens toe aan een compleet ander

traject. Dan hebben we het ook meteen over het duurzame denken.

Pagina 59

Testers trek je niet met een blik tegelijk open en ze zijn ook geen verlengstuk van een tool. Bij hen moet juist een

creatieve geest aanwezig zijn om elk testtraject slim en handig aan te pakken. Lekker het boerenverstand eens

gebruiken zonder last te hebben van templates of een bestaand vast stramien. Bij biologische voeding staat ook de

wens van de klant centraal. Alles op een niet-kunstmatige manier voor elkaar krijgen, zodat de klant uiteindelijk een

heerlijke en voedzame maaltijd op tafel kan zetten: daar gaat het dus uiteindelijk om. Als tester zul je dan ook even

terug naar de wortels moeten: bij alles wat je doet eerst de ‘waarom?’ vraag stellen. Waarom gebruiken we deze

techniek, tool, testmethode? Waarom test de klant ook nog eens? Waarom belichten we de gebruikersvriendelijkheid

helemaal niet en waarom zouden we in dit vroege stadium er juist geen gebruiker bij halen? Dan maak je jezelf

bewust van de toegevoegde waarde van het testen.

Duur(zamer)

Bij biologische voeding denken velen aan de hogere prijs die moet

worden betaald in de winkel. Is de het de vraag die groter is dan

het aanbod of is het de zogenaamde 'bewerkelijkheid' van deze

voeding? Ik denk dat het de prijs waard is. Als je ziet wat er nu

soms voor onnodige zaken aan het testproces worden toegevoegd

(te veel testtechnieken, overlappende testsoorten, versnipperde

functionaliteiten met verschillende tools), dan worden die nu ook

betaald, maar de kosten hiervan zijn te onzichtbaar in de meeste organisaties.

Vergeten (test)groenten

De wereld van het biologisch voedsel heeft de vergeten groenten weer op de kaart gezet. Vergeten groeten zijn

bijvoorbeeld de paarse boerenkool, spruitjes of bonen. Maar ook de chioggia (rood-witte biet) en de aardperen zijn

van die vergeten groenten die steeds meer in trek zijn. In uiterlijk anders, verrassend en oogstrelend op het bord,

in smaak vaak hetzelfde als de conventionele variant. Ook binnen het testen

hebben we vergeten groenten, maar we noemen ze dan bijvoorbeeld handmatig

testen, checklist, Joint Testware Development of steekproef. Ook met deze

‘vergeten testgroenten’ kunnen we een prima eindresultaat bereiken, en de weg

ernaartoe kan vele malen prettiger zijn. We kunnen zoveel duurzamer, meer,

beter, aangenamer en vooral leuker testen als we Biologisch Testen onderdeel

laten uitmaken van het bestaande testcultuur. Niet alles hoeft biologisch te zijn:

we hoeven niet door te schieten of er een sleur van te maken. Zie het als een verantwoorde aanvulling. En wees

eens eerlijk: moeten we de huidige testfabrieken niet zien als grote mega-stallen, waar het alleen maar draait om

maximale productie, zonder nadruk te leggen op de manier waarop dit wordt verwezenlijkt? Vanzelfsprekend dat

het draait om het eindresultaat, maar als dat ook op een bewuste en duurzame manier kan worden behaald, waarom

niet?

En nu aan de slag!

Wil je ook beter presteren en aan de slag binnen je eigen organisatie of project met Biologisch Testen? Wees dan

zelf die slimme ‘Willie Wortel’ en geef aan wanneer er meer bewuste keuzes moeten worden gemaakt bij het testen.

Wij vertellen graag met humor en passie over deze nieuwe beweging in het testvak; de actuele ontwikkelingen van

het Biologisch Testen kun je volgen op Twitter.

Pagina 60

Goed, beter, best: op weg naar een perfect presterend team!

Door Berry Kersten ● berry.kersten@bartosz.nl @berrykersten

Niemand is perfect, maar een team kan dat wel zijn. Een écht goed team functioneert

als een geoliede machine en kan uitzonderlijke resultaten behalen. Denk aan een formule

1 pit crew. Zij moeten snel een probleem evalueren, een oplossing vinden, ernaar

handelen en tegelijkertijd bewust zijn van eventuele externe omstandigheden die de

oplossing kunnen belemmeren. En dat telkens weer. Dit worden High Performance Teams

(HPT) genoemd. High Performance Scrum Teams kunnen een productiviteit behalen die

maar liefst 400% hoger ligt dan die van gemiddelde watervalteams [1]. Op basis van

bestaande studies en mijn eigen visie leg ik in dit artikel uit wat de kenmerken van HPT

binnen Scrum zijn, welke metrics gebruikt worden en hoe tools ondersteuning kunnen bieden.

Samen meer presteren

Er zijn genoeg voorbeelden te vinden van academische en professionele studies over de relatie tussen IT-projecten

en productiviteit. Ook over HPT circuleren diverse artikelen (en meningen). Een eenduidige definitie ontbreekt echter,

omdat het contextafhankelijk is. In feite zet een HPT verrassende resultaten neer door een speciale manier van

samenwerking. Hierdoor halen de teamleden het beste uit zichzelf en heeft iedereen aan een half woord genoeg.

Is er één formule voor succes? Nee! Immers, elke organisatie en elk team is uniek. Om te begrijpen hoe teams

optimaal functioneren en wat de principes achter HPT zijn, helpt het om bewust te worden van wat zowel positieve

als negatieve invloeden zijn op de (team)prestaties. Aan de hand van twee modellen zal ik dit verder toelichten.

The 5 dysfunctions of a team van Patrick Lencioni

Het model van Lencioni [2] beschrijft de vijf frustraties die de samenwerking in teams saboteren. De volgende

afbeelding geeft dit weer.

Figuur 1: The 5 dysfunctions of a team

Pagina 61

De opsomming geeft weer in welke volgorde de frustraties, die gerelateerd zijn aan elkaar, overwonnen moeten

worden. Dus afwezigheid van vertrouwen leidt tot angst voor confrontatie en conflict, et cetera. Relaterend aan het

Scrum-proces, zou het betekenen dat vertrouwen naar de Product Owner en tussen de teamleden onderling de

absolute basis is. Dit klinkt eenvoudig, maar doorgaans is dit het lastigste gedeelte bij teamontwikkeling. Het vergt

onder andere dat men zich kwetsbaar durft op te stellen. Dat gaat niet vanzelf en dit kun je niet opeisen. Een teken

van onvoldoende vertrouwen is bijvoorbeeld als teamleden zich niet durven uit te spreken bij Scrum-meetings, maar

wel op de wandelgang klagen over het werk of over elkaar. Goede feedback durven geven is cruciaal voor het

functioneren van een team. Management Guru Ken Blanchard zegt niet voor niets ‘feedback is the breakfast of

champions’.

Stephan Covey’s ‘The 7 habits of highly effective people’

Het model van Covey [3] omschrijft zeven eigenschappen van persoonlijk leiderschap en effectiviteit. Hoewel dit

model gefocust is op het individu, vind ik dat de eigenschappen ook toepasbaar zijn voor een Scrum-team. Zie

daarvoor de volgende tabel.

Eigenschap Vertaling naar Scrum

1. Wees pro-actief

neem initiatief en

verantwoordelijkheid

Scrum-teams zijn volledig zelf organiserend en spelen zelf in op veranderende

omstandigheden (bijvoorbeeld gewijzigde prioriteit, scope).

2. Begin met het eind in

gedachten

werk vanuit je visie

Scrum-teams hebben het doel helder voor ogen door specifieke hulpmiddelen te

gebruiken, zoals: product vision/statement, release plan, sprint plan.

3. Belangrijke zaken eerst

werk vanuit belang en niet vanuit

urgentie

Een geprioriteerde product backlog zorgt ervoor dat het Scrum-team werkt aan items

met de hoogste waarde. Intensieve samenwerking tussen de Product Owner, Scrum

Master en Scrum-team is nodig.

4. Denk win-win

zoek oplossingen met wederzijds

voordeel

Niet alleen de prioriteit is belangrijk, maar ook een juiste balans van diverse items.

Bijvoorbeeld procesverbeteringen, wegwerken technische schuld, optimalisatie

testautomatisering, refactoring). Zo wordt iedereen gediend (klant, architect, team,

…)

5. Eerst begrijpen, dan begrepen

worden

empathisch luisteren

Dé top-focus van het team is om waarde te leveren aan de klant. In de ideaalsituatie

wordt direct nauw samengewerkt met de eindklant om het product volledig te

begrijpen. Zodra het team dit begrip heeft en heeft bewezen dat het snel waarde kan

leveren, dan wordt optimaal vertrouwen opgebouwd voor de verdere interactie met

klanten.

6. Synergie creëren

creëer samen meer dan de som van

de individuen

De sleutel voor goede synergie in een Scrum-team ontstaat bij een volledig

empowered team en gezonde transparante samenwerking. Het team is

multidisciplinair en complementair: niet alleen qua skills maar ook qua persoonlijkheid.

Ze kennen elkaars specifieke sterkten en zwakten en houden hier rekening mee.

7. Houd de zaag scherp

onderhoud en vernieuw jezelf

Er heerst een cultuur waarbij continue verbeteren mogelijk is. Bijvoorbeeld door naast

de retrospectives de individuen de mogelijkheid te geven zich te verdiepen in bepaalde

(nieuwe) technologieën / tools / onderwerpen.

Tabel 1: The 7 habits of highly effective people en de vertaling naar Scrum

Pagina 62

Met de bewustwording van beide modellen is een eerste stap gezet in de juiste richting. Vervolgens moet zeer hard

gewerkt worden. Want een HPT worden vergt een flinke dosis inzet, óók van het management. Dit moet men niet

onderschatten: de theorie is makkelijk te leren, maar het beheersen ervan is een kunst.

Van meten naar weten

Een HPT worden is lastig. Nog lastiger is wellicht om een stabiel HPT te blijven en continu te verbeteren. Zicht en

grip krijgen op de prestaties van je team is dus van belang. Zoals eerder beschreven bestaat er geen eenduidige

formule om hier succesvol in te zijn. Er zijn echter wel hulpmiddelen die een duwtje in de rug kunnen geven.

Hieronder zal ik er vier beschrijven.

1. Agile Maturity Assessment

Ten eerste heeft Kumar [4] een handzame manier bedacht om een team assessment uit te voeren. Dit wordt gedaan

op basis van de twaalf principes uit het Agile Manifesto. De Product Owner, Scrum Master en teamleden kunnen op

elk van de items een score geven; hoe hoger hoe beter. Door per principe te middelen, ontstaat een totaalbeeld van

het Agile volwassenheidsniveau.

Figuur 2: voorbeeld Agile Maturity Assessment report

Zo’n assessment moet in elke sprint worden gefaciliteerd waarbij levendige discussies gevoerd worden. Extra

aandacht moet hierbij besteed worden aan scores die ver uiteenliggen.

2. RoboScrum

Een andere benadering is die van Sutherland en Downey [1]. Zij beschrijven een (samenhangende) set van

verschillende metrics. Het gaat te ver om in dit artikel al deze metrics in detail te behandelen, maar onderstaande

tabel geeft een goed beeld van het nut.

Pagina 63

Metric Used to answer… Formula

Velocity How much value can the team plan and achieved to the

Product Owner's satisfaction in a sprint?

∑ Original Estimates of

All Approved Cards

Work Capacity How much effort can the Team expend in a sprint? ∑ All Work Reported

During the Sprint

Total Commitment

How much work did the Team ultimately commit to achieve in

the Sprint, including Adopted Work pulled forward after the

Planning Meeting?

∑ Original Estimates for

All User Stories

Focus Factor What percentage of the Team's total energy expenditure

results in requested-and-approved value?

Velocity ÷ Work

Capacity

Adopted Work

As a percentage of the Original Commitment, how much

additional work did the Team need to pull forward before the

end of the Sprint in order to stay engaged?

(∑ Original Estimates for

Work Pulled Forward) ÷

Original Commitment

Found Work

As a percentage of the Original Commitment, how much

unexpected complexity did the Team discover mid-Sprint on

the work they had already committed to do?

(∑ Work Reported per

Card - ∑ Original

Estimates) ÷

Original Commitment

Targeted Value

Contribution Increase

How much change has there been in the Team's Velocity over

time, since the initial Sprint? (Initial Sprint can be selected on

the Setup tab if Team structure changes)

Current Sprint's Velocity

÷ Original Velocity

Accuracy of Estimation How accurate are the Story Point estimates that the Team

provides for their Work?

1 - (Estimate Delta ÷

Total Commit)

Accuracy of

Commitment

When the Team commits to work, how accurate are they in

biting off a block that will keep them busy, at a sustainable

pace and be delivered by the end of the Sprint?

(∑Original Estimates) ÷

(∑Original Estimates +

∑Adopted Estimates +

∑Found Work)

Tabel 2: de negen metrics ten behoeve van RoboScum

Via een Excel tool genaamd RoboScrum [5] kunnen teamprestaties objectief worden gemeten in plaats van op basis

van een onderbuikgevoel. Als de gegevens correct worden ingevoerd, wordt automatisch weergegeven of het team

op de juiste koers zit qua HPT. Deze metrics kunnen het management helpen om de performance van teams te

vergelijken.

Hoewel deze metrics nuttig kunnen zijn, denk ik dat het enkel weggelegd is voor zeer ervaren Scrum-teams die zich

al (bijna) High Performing mogen noemen.

Pagina 64

3. Happyness Metric

In de volksmond wordt wel eens gezegd dat tevreden medewerkers beter presteren. Recentelijk is dit nog

onderschreven door een studie van de Universiteit van Warwick [6]. Misschien ook wel logisch, want geluk en

tevredenheid zorgen er mijn inziens voor dat je, even gechargeerd, ‘fluitend’ naar je werk gaat. Hierop verder causaal

redenerend zal dit resulteren in een beter werkklimaat en uiteindelijk in betere eindresultaten. Betere eindresultaten

zorgt voor tevreden klanten. En als klanten tevreden zijn kan dit weer leiden tot bijvoorbeeld hogere toekenning van

budgetten om nieuwe producten te realiseren, of een betere reputatie wat weer kan leiden tot de inzet van andere

professionals.

Het meten van medewerkerstevredenheid in je team is daarom belangrijk. Volgens Sutherland [7] is het een van de

beste metrics omdat het een zogenoemde voorspellende indicator is. De uitvoering hiervan kan vrij laagdrempelig

zijn door teamleden hun gevoelens te laten uiten op een schaal van 1 tot en met 5. Uiteraard is dit afhankelijk van

de context, maar te denken valt aan: ‘hoe tevreden ben je met je organisatie/project?’ en ‘hoe tevreden ben je met

je rol?’. Dit kan periodiek bijgehouden worden in een simpele spreadsheet. Wanneer duidelijke verschillen in de

gemiddelde waarden optreden, moet ingegrepen worden door interactie en discussie om de tevredenheid van het

team te vergroten.

4. Team Morale Metrics

Een stap verder is het meten van het moraal van het team. Christiaan Verwijs [8] propageert dat de ‘happyness

metric’ te subjectief is en heeft een alternatief bedacht: de ‘Team Morale Metrics’. Hiermee wordt meer feitelijk en

objectief gemeten wat het welzijn van het team is in algemene zin. In onderstaande tabel worden de

karaktereigenschappen samengevat van een hoog/laag teammoraal:

Hoog moraal Laag moraal

Teamleden zijn behulpzaam naar elkaar, ongeacht de

taak

Teamleden doen niet mee aan (fun) teamactiviteiten

Teamleden zijn trots op hun team en het werk dat ze

doen

Teamleden schamen zich soms voor hun team

Teamleden doen nét even wat meer, ook al betekent

dat incidenteel extra werk moeten verzetten

Teamleden hebben een ‘9 tot 5’ mentaliteit

Teamleden bezwijken niet onder hoge druk of lastig

situaties

Teamleden geven makkelijk op als problemen zich

voordoen

Tabel 3: vergelijking tussen hoog en laag teammoraal

Via een online tool [9] kan eenvoudig een vragenlijst worden ingevuld en de resultaten kunnen direct worden

ingezien. Tevens kan het individuele moraal vergeleken worden met het (gemiddelde) teammoraal.

Aanvullende aandachtsgebieden

Vanuit mijn ervaring heb ik nog aanvullende aandachtspunten die minstens zo belangrijk zijn als het volgen van de

juiste processtappen, namelijk:

Pagina 65

Practice what you preach

Wees een voorbeeld voor anderen: doe waar je voor staat en draag je vakmanschap uit. Als testprofessional kun je

je opgedane kennis en ervaring delen met je teamleden en vice versa. Zo reserveer ik periodiek tijd om free-format

met software ontwikkelaars en business analisten te sparren over actuele zaken met software kwaliteit als rode

draad. Zo ontstaan soms nieuwe inzichten die normaliter niet zo gauw zouden ontstaan. Probeer hierin uit je

comfortzone te komen en stimuleer kennisontwikkeling, want dit is essentieel voor innovatie [10].

Word dronken met je team

Rini van Solingen [10] deed ooit een uitspraak die me bijgebleven is. Vrij vertaald: ‘een groep mensen is geen team

tenzij ze ooit tegelijkertijd dronken zijn geweest op dezelfde locatie’. Met andere woorden, om je collega’s écht goed

te leren kennen is het aan te bevelen om soms een avondje uit te gaan. Niet per se dronken worden, maar in een

informele setting te praten over werk en privé is doorgaans goed voor de verstandhouding. Zo kan het nuttige met

het aangename gecombineerd worden. Want het ontwikkelen en testen van software kan worden beschouwd als een

creatief beroep. Afgezien van kennis, ervaring en inzicht is de output van het proces sterk afhankelijk van de

creativiteit en het oplossingsvermogen van de persoon. Goede ideeën en efficiënte oplossingen komen vaak juist ten

tijde van ontspanning en rust. Door het team onder druk te zetten wordt zowel de creativiteit als zelfontplooiing

beperkt en neemt de kans op softwarefouten toe. Vandaar dat het team af en toe ‘stoom moet afblazen’.

Netwerken

In de sportwereld is een perfect team niet altijd een groep mensen met sterspelers. Vaak zijn het spelers die

individueel veel verschillende én complementaire skills en ervaringen hebben. Als Scrum-team zou je idealiter ook

een dergelijke bemensing willen hebben. Uiteindelijk, een team dat goed ingespeeld is op elkaar en kort op de bal

zit, is voorbereid op de toekomst. Dat wil zeggen, als er problemen optreden, dan kunnen deze adequaat opgelost

worden. Als teamlid heb je weliswaar niet direct invloed op de bemensing van je team. Maar als je niet allemaal

‘schapen met vijf poten’ hebt in je team, dan is het van belang dat je professionele netwerk in orde is en je weet

waar je de kennis vandaan moet halen. Ik ken genoeg voorbeelden waarbij de analyse van een probleem onnodig

veel tijd kostte omdat het team niet snel genoeg elders hulp ging vragen (mede omdat niet duidelijk was waar de

specifieke kennis te vinden was). Teamleden moeten dus niet alleen goed intern communiceren, maar ze moeten

ook contacten onderhouden met andere teams.

De zwakste schakel

Als je Scrum-team onderdeel is van een groter geheel, dan kan het zomaar zijn dat jouw team uitstekend presteert,

maar dat anderen waarvan je afhankelijk bent in de ketenomgeving dat niet doen. Écht succesvol ben je pas als de

principes van een HPT volledig zijn geïntegreerd in (alle teams van) de organisatie. Pas dan is een volgende stap om

de organisatie high performance te maken. Diverse initiatieven kunnen hier handen en voeten aan geven, zoals:

SAFe (Scaled Agile Framework), DAD (Disciplined Agile Delivery), Enterprise Scrum en DevOps.

Gebruik het juiste gereedschap

Het lijkt vaak een cliché, maar de inzet van het juiste gereedschap wordt wel eens onderschat. High Performing zijn,

betekent snellere feedback loops, betere voorspelbaarheid en hogere softwarekwaliteit dan een ‘gewoon goed team’.

De inzet van Continuous Integration en testautomatisering is daarmee onmisbaar geworden. Zorg dat het

kennisniveau binnen het team up-to-date is met betrekking tot relevante methoden, technieken en aanverwante

tooling. Als Agile testprofessional is het een must om thema’s zoals (A)TDD en BDD te vertalen naar de

Pagina 66

werkvloer. Denk hierbij aan FitNesse, Selenium en Cucumber. In het verlengde van DevOps is kennis over ALM

(Application Lifecycle Management) een absolute pré. Want ALM is immers van toepassing tijdens het gehele

softwareontwikkelproces: van idee naar eindproduct tot en met uitfasering van de software.

Conclusie

In de inleiding staat dat High Performance Scrum-teams een productiviteit behalen die maar liefst 400% hoger ligt

dan die van gemiddelde watervalteams. Ik ben van mening dat zo’n percentage daadwerkelijk gerealiseerd kan

worden mits aan álle randvoorwaarden voldaan is, de steun van het management aanwezig is en er objectief

gemeten wordt. Echter, of je dit zou willen is een andere kwestie. Want je zou het even kort-door-de-bocht kunnen

vergelijken met CMMI en/of TMMi level 5. Niet iedereen is hiervoor geschikt en niet iedereen is geschikt om dit vol

te houden.

Ik vind dat als een Scrum-team de waarden en principes uit het Agile Manifesto (én de regels van Scrum) respecteert

en naleeft, er een goed fundament aanwezig is voor een goed presterend team. De beschreven modellen en metrics

zijn handzaam om van een (goed presterend) team een nog beter presterend team te maken. De stap naar het

beste team, namelijk High Performing, is dan niet zo groot meer. Het is ook sterk afhankelijk van welke doelen men

stelt om een HPT te worden, oftewel welke metrics er gekozen worden.

Al met al geeft dit artikel diverse concrete handvaten ter bewustwording en ter verbetering van je individuele

prestaties en teamprestaties.

Referenties

1. Downey, S., Sutherland, J., ‘Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft,’

hicss, pp.4870-4878, 2013 46th Hawaii International Conference on System Sciences (HICSS), 2013

2. Lencioni, P., The Five Dysfunctions of a Team, Jossey-Bass, 2002

3. Covey, S. R., The 7 Habits of Highly Effective People: Restoring the Character Ethic, New York: Free Press,

2004

4. Kumar, M.P., ‘Maturity Assessment Model for Scrum Teams’,

http://www.scrumalliance.org/community/articles/2014/july/maturity-assessment-model-for-the-scrum-teams

5. http://www.rapidscrum.com/RoboScrum

6. Oswald A.J., Proto, E., Sgroi, D., ‘Happiness and Productivity’, University of Warwick, UK, and IZA Bonn,

Germany JOLE 3rd Version, 2014

7. Sutherland, J., Harrisson, N, Riddle, J., ‘Teams that Finish Early Accelerate Faster: A Pattern Language for High

Performing Scrum Teams’, HICSS 2014: 4722-4728

8. Verwijs C., ‘Agile Teams: Don't use happiness metrics, measure Team Morale’

http://www.christiaanverwijs.nl/post/2012/07/24/Agile-Teams-Dont-use-happiness-metrics-measure-Team-

Morale.aspx

9. http://teammetrics.apphb.com

10. Nonaka, I., ‘The Knowledge-Creating Company’, Harvard Business Review, 1991.

11. http://www.rinivansolingen.nl

Pagina 67

EN DE WINNAAR IS.... FUNCTIONALITEIT?

Door Bernd Beersma (links) ● bernd@2b4qa.nl en Erik Bits (rechts) ● erik@2b4qa.nl

Functionaliteit is de meest belangrijke

eigenschap van ieder object. De functionaliteit

bepaalt of dit object nuttig is of juist niet. Zo’n

object kan van alles zijn: bijvoorbeeld een

koffiezetapparaat, een auto, een mobiele

telefoon, een stoel of software. In het kader

van dit artikel doelen we op de functionaliteit

van de laatste, de software. Deze software kan een interface, een Graphical User Interface (GUI), een webapplicatie

of zelfs een compleet informatiesysteem zijn. Voor al deze onderdelen geldt: de functionaliteit beschrijft ‘wat’ de

software moet doen. Vervolgens zijn het de compleetheid, correctheid en toepasbaarheid die bepalen op welk niveau

de software geschikt is voor haar doel. Dus functionaliteit is uitermate belangrijk.

We zien dit ook terug in de manier waarop we software ontwikkelen. Eerst vertalen wij de wensen van de klant naar

requirements, in de meeste gevallen zijn deze eisen gericht op de functionaliteit van de oplossing. Wat moet de

software doen? Daarna schrijven we, op basis van deze requirements, de functionele en technische ontwerpen waarin

we de functionaliteit verder concretiseren. Ten slotte bouwen we deze functionaliteit en we testen uitvoerig om te

bepalen of deze software werkt zoals ontworpen. Daar is helemaal niets mis mee, immers zonder functionaliteit zou

elk stukje software compleet nutteloos zijn. Maar hoe zit het met de andere categorieën, de hoedanigheden van de

software? Hoe krijgen we de overall kwaliteit op orde?

Waterval versus Agile

Misschien vinden we het antwoord in de manier waarop we de software ontwikkelen? Het principe van sequentieel

ontwerpen, bouwen en testen wordt waterval ontwikkeling genoemd. Deze methode gaf ons een aantal uitdagingen

van een heel andere aard: tijdige kwaliteit. Jarenlang hebben we onze de wensen van onze klanten vervuld door het

achtereenvolgend ontwerpen, ontwikkelen en testen van complete informatiesysteem om aan het einde tot de

conclusie te komen dat uiteindelijke resultaat helemaal niet was wat onze klant had verwacht. Dit is waarom we

tegenwoordig steeds vaker Agile-georiënteerde ontwikkelmethoden zoals Scrum gebruiken om deze mismatch te

voorkomen. In korte iteraties van ongeveer twee weken leveren wij kleine stukjes functionaliteit op die volledig

onafhankelijk van het geheel naar productie worden gebracht. Uitspraken als 'Werkende software' is belangrijker

dan 'uitgebreide documentatie en ‘Reageren op veranderingen' is belangrijker dan het 'Volgen van een plan’ helpen

ons te focussen op de onderwerpen die er echt toe doen. Als een specifieke activiteit of product geen waarde toevoegt

aan het eindresultaat, doen we het gewoon niet. Ik denk dat, op een bepaalde manier, dit is ook wat Lean en Six

Sigma ons vertellen. En dat is logisch want uiteindelijk draait het allemaal om gezond verstand.

De veranderende rol van de tester in een Agile omgeving

Agile geeft ons veel voordelen. Vanwege de vroegtijdige betrokkenheid van testers binnen het project zijn we in

staat om gebreken te vinden voordat ze echt schade veroorzaken. De flexibele aanpak stelt ons in staat om op de

veranderende eisen en wensen van onze Product Owner te reageren. Grenzen tussen testen en

ontwikkeling verdwijnen; als team zijn we allemaal verantwoordelijk voor het eindresultaat en daarmee voor de

kwaliteit. Een gezamenlijke kwaliteitsbewustzijn ... Echter, Agile brengt ook een aantal uitdagingen met zich mee,

ik zou het zelfs risico’s durven noemen. Gebrek aan documentatie, veranderende eisen en een flexibele

Pagina 68

aanpak vereisen speciale vaardigheden van onze testers, we moeten onszelf blijven verbeteren. Hij of zij moet in

staat zijn om de juiste basis voor de testen te vinden. Deze basis wordt niet langer alleen gevormd door de

uitgangsdocumentatie, maar kan ook verworven worden uit gesprekken met ontwikkelaars, voorafgaande

programmatuur of de broncode. Zo zie je dat onze basis skills als testers mee veranderen met de manier waarop

we software ontwikkelen. Gebruikt de tester niet het juiste referentiekader, dan zal er getest worden 'wat is' in plaats

van 'wat er verwacht wordt'. Testen wordt hiermee nog specifieker en specialistischer. Het gaat niet alleen om het

vaststellen van de correcte werking van de software, maar ook om het bepalen van de juiste kwaliteit binnen de

gegeven context. De tester ontwikkelt zich naar een Quality Engineer. De gezamenlijke verantwoordelijkheid voor

de kwaliteit is een voordeel, maar het creëert ook een risico. Het objectieve beeld van een tester, de gezonde strijd

tussen testers en ontwikkelaars is verdwenen. We zijn allemaal verantwoordelijk en daardoor eigenlijk niemand ...

Het belangrijkste risico is de sterke focus vanuit Agile op de functionaliteit van de software. Wij zijn van mening dat

met de introductie van Agile, we ook een scope vernauwing van ICT en Proces naar alleen IT hebben veroorzaakt.

Binnen de Scrum-teams zijn wij verantwoordelijk voor de levering van geïsoleerde stukjes werkende software. De

manier waarop software wordt gebruikt door de organisatie wordt vaak genegeerd, de nadruk ligt op de

functionaliteit. Dit kan gevaarlijk zijn, vooral wanneer je bedenkt dat de hoedanigheden van software steeds

belangrijker worden gevonden.

De waarde van non-functionals

In de laatste twee decennia zijn de hoedanigheden (of non-functionals zoals deze ook wel worden genoemd) van

software steeds belangrijker geworden. Tijdens het testen vóór het jaar 2000 lag de focus vooral op het bepalen van

het niveau van de kwaliteit van de functionaliteit. Het was belangrijk dat een systeem deed wat het moest doen. Wij

denken dat daar meerdere redenen voor waren; beperkte technische mogelijkheden, de invloed van de klant op de

IT en de toegankelijkheid van onze informatie. Onze informatie systemen waren beschermd door de muren van ons

kantoor. We waren tevreden zolang onze systemen gewoon functioneerden. Tegenwoordig is de correcte werking

van deze functionaliteit evident. Onder welke voorwaarden deze functionaliteit wordt geleverd is echter belangrijker

geworden. IT is niet langer leidend, zij zijn faciliterend voor de business. Onze gegevens en informatie worden niet

langer beschermd door de muren van ons kantoor, maar moet over de hele wereld toegankelijk zijn. Waar je ook

bent, wat je ook doet, je wilt toegang tot de gewenste informatie op ieder gewenst moment. Vanwege die reden

zien we een toenemend belang van het voldoen aan de eisen ten aanzien van de hoedanigheden. Natuurlijk moet

een systeem functioneren, maar deze functionaliteit moet onderhoudbaar, beschikbaar, veilig en compatibel met

verschillende hardware-platformen, besturingssystemen en apparaten zijn. Gelukkig zijn er verschillende theorieën,

methoden en modellen die ons kunnen helpen om het verschil tussen de functionaliteit en de hoedanigheden te

onderscheiden, te classificeren en te prioriteren.

ISO 25010 standaard

Laten we de ISO 25010 standaard als uitgangspunt nemen voor de veranderende blik en skill set van de tester. Deze

norm vervangt de ISO 9126 sinds 2011 en beschrijft alle kenmerken van software. Deze ISO-norm is onderdeel van

de NEN-ISO Square, een verzameling van normen die requirements (wat wil ik?), Modellen (Hoe wil ik dit?), Evaluatie

(Krijg ik wat ik wil?) en Metrics (Heb ik gekregen wat ik wil?) afdekken. Alle vier kwadranten geven ons inzicht in de

manier waarop we daadwerkelijk kunnen voldoen aan de eisen van onze klanten. In het midden plaatsen we het

management waar vanuit we de regie voeren door het toevoegen of verwijderen van activiteiten. Als we deze NEN-

ISO SQuaRE visualiseren, dan komen we tot onderstaande extended versie:

Pagina 69

Voor dit moment concentreren we ons op het ‘Model’ kwadrant (ISO 25010). Natuurlijk bevat dit model ook

‘functionaliteit’ als een categorie, maar ook alle hoedanigheden: veiligheid, overdraagbaarheid, betrouwbaarheid,

compatibiliteit, bruikbaarheid, prestaties, efficiëntie en onderhoudbaarheid. Acht categorieën om precies te zijn, elk

met hun eigen kenmerken. Wanneer we kijken naar deze standaard dan lijkt het alsof er geen onderlinge samenhang

bestaat tussen de verschillende categorieën. Alle categorieën bevinden zich op hetzelfde niveau, er is geen correlatie

tussen hen. Dat vinden wij niet correct. Zoals wij het zien, hoort de functionaliteit in het midden. Per slot van

rekening is dat waar het allemaal mee begint. Met deze functionaliteit krijg je de overige zeven kenmerken er gratis

bij. Er is geen keuze. Ongeacht de grootte, het gewicht, de prijs of de geavanceerdheid van de functionele oplossing,

het is altijd de vraag onder welke voorwaarden de software dit zou moeten doen. Wat zijn de eisen van de

beheerafdeling? Aan welke security-eisen moet worden voldaan? Welke prestaties zijn nodig en op welke platforms

of apparaten zal de software gaan draaien. Het is dus niet de vraag of we te maken hebben met die andere

kenmerken. De enige vraag die we moeten beantwoorden is hoe belangrijk is een specifiek kenmerk voor ons en

onze klanten. Als we de categorieën en hun onderliggende attributen herschikken, rekeninghoudend met het feit dat

de functionaliteit de oorsprong is van alle andere kenmerken, zou dit leiden tot het volgende beeld:

Pagina 70

Dit overzicht kan ook zeer nuttig zijn binnen Scrum-projecten. Naast tools zoals planning poker, welke je helpt te

bepalen hoeveel werk kan worden gedaan binnen de beschikbare tijd, en een Kanban bord dat je een overzicht geeft

van de hoeveelheid werk dat gedaan moet worden, kan dit blad helpen het belang te bepalen van de verschillende

kwaliteitskenmerken. Het beste moment om deze analyse uit te voeren aan de hand van dit extended ISO 25010

overzicht is iteratie nul. Tijdens deze iteratie worden alle voorbereidende activiteiten uitgevoerd. Dit is een uitstekend

moment om niet alleen de standaard Scrum-leden, maar ook de stakeholders van contracting, financiën, juridische

zaken, beheer, leveranciers et cetera te betrekken. In korte sessies gebruiken we dit blad niet alleen om bewustzijn

te creëren, maar ook om gezamenlijk te bepalen welke risico's we lopen en welke maatregelen we willen nemen

tijdens de komende iteraties. Dit houdt tevens in dat de rol van de testmanager zich uitbreidt. Hij of zij richt zich op

het volledige scala aan risico’s en bijbehorende maatregelen. Daarmee wordt de testmanager eigenlijk een soort

regisseur, een Quality director. Dus op het moment dat we de sterke punten van Agile ontwikkeling combineren met

het creëren van bewustzijn van het belang van de van de diverse kwaliteitskenmerken, introduceren we een compleet

nieuw concept gebaseerd op de NEN-ISO SQuaRE genaamd: Kwaliteit op Maat.

Samenvatting

Functionaliteit is dus veruit de meest belangrijke eigenschap van ieder stuk software. Naar onze mening kan deze

functionaliteit echter nooit los gezien worden van de overige karaktereigenschappen. De opkomst van Agile legt juist

de nadruk op de het creëren van werkende software en ‘vergeet’ hierbij de overige non-functionals. Het is onze taak

als testter om ervoor te zorgen dat deze scope weer hersteld wordt. Dit stelt natuurlijk specifieke eisen aan de

vaardigheden van de tester, zowel aan de hard- als aan de softskills. Het gebruik van de NEN-ISO SQuaRE is hierbij

een erg handig hulpmiddel om de juiste scope te definiëren. We benoemden in dit artikel de sterke punten van Agile

ontwikkeling en combineren deze met de karaktereigenschappen op het gebied van zowel de functionaliteit als de

hoedanigheden van software. We introduceren hiermee een compleet nieuw concept gebaseerd op NEN-ISO SQuaRE

genaamd: Kwaliteit op Maat.

TESTNET NIEUWS

TestNet Nieuws is een uitgave van de Vereniging TestNet, een bloeiende vereniging met meer dan 1600 professionele

testers als lid. TestNet streeft de professionalisering na van het testen van IT-producten, en de vergroting van de

bewustwording en het belang van testen als vak apart. TestNet stimuleert het uitwisselen en uitdragen van

vakkennis, ervaring tussen vakgenoten en stimuleert onderzoek vanuit zowel wetenschappelijk als praktisch

perspectief. Voor meer informatie en lidmaatschap, zie http://www.testnet.org.

TestNet Nieuws brengt tweemaal per jaar een Special uit met artikelen over een actueel thema uit de testwereld,

gerelateerd aan het TestNet Voorjaars- en Najaarsevenement.

Daarnaast verschijnt op internet de TestNet Nieuws Weekly, een blog met iedere week een artikel over testen en

TestNet.