Testnet Nieuws - Najaarsspecial 2014
-
Upload
marcel-hogenhout -
Category
Documents
-
view
221 -
download
0
description
Transcript of Testnet Nieuws - Najaarsspecial 2014
Voorjaarspecia l Me i 2014 2013
Pagina 1
Oktober 2014 • Jaargang 18 • Najaarsspecial
www.testnet.org [email protected]
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
Opzeggen l idmaatschap: http://www.testnet.org/a lgemeen/a lgemene -voorwaarden.html#opzeggen
VAN DE REDACTIE
Door Rob van Steenbergen ● [email protected] @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 ● [email protected]
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 ● [email protected]
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 ● [email protected] @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 ● [email protected] @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 ● [email protected]
Pagina 15
REIS OM DE WERELD IN ÉÉN DAG
Door Ijsbrand Kaper ● [email protected] @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 ● [email protected]
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 ● [email protected] en Pascal Dufour ● [email protected]
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 ● [email protected] @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 ● [email protected] @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 ● [email protected]
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 ● [email protected]
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 ● [email protected] @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 ● [email protected]
Pagina 43
HOE MAAK JE KWALITEIT VAN IT-IMPLEMENTATIES WEL MEETBAAR...
Door René Ceelen ● [email protected]
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 ● [email protected] @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 ● [email protected]
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 ● [email protected]
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 ● [email protected] en Jacob Hooghiemstra ● [email protected]
@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 ● [email protected] @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) ● [email protected] en Erik Bits (rechts) ● [email protected]
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.