Voorjaarspecia l Me i

Voorjaarspecial Mei 2014 2013

Pagina 1

Oktober 2014 • Jaargang 18 • Najaarsspecial www.testnet.org [email protected]

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!! 

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 [email protected]

Opzeggen lidmaatschap: http://www.testnet.org/algemeen/algemene -voorwaarden.html#opzeggen

Pagina 2

In dit nummer Van de redactie Van de voorzitter Testen met aandacht Mijn ervaringen met een bughunt Hoe leer je werken met een testtool? Reis om de wereld in één dag Testware genereren met Sepiola Serious games voor testers Het testgeval - een epistemologische deconstructie Succesvolle testverbetering in iedere situatie Bughunting - testen vergeleken met een spelletje zeeslag Productrisicoanalyse: Vele wegen leiden naar Rome! Beter is niet altijd goed Hoe maak je kwaliteit van IT-implementaties wel meetbaar... Testen: Houding en sociale vaardigheden maken het verschil Spreadsheet testen met spreadsheets Focus op verbeteringen? Ervaringen van een ex-perfectionist Testen? Natuurlijk, da's logisch. Biologisch! Goed, beter, best: op weg naar een perfect presterend team! En de winnaar is... Functionaliteit?

1 3 4 7 12 15 17 18 22 27 33 36 40 43 49 52 54 58 60 67

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!

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



1 Uit:

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

zoeken

voor

de

situatie.

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 omschrijvingen 2: 

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! 

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

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 rapportagemogelijkheden 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 gezamenlijk 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 kerntestcases 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 testgevallen 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 exploratory 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 epistemologisch 3 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 Scrumof-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 ETsessies 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 ministickers 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 softwarevoortbrengingsproces. 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 nietbevestigend, 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 ERPsysteem 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 functieoriëntatie 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 constructieorië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 ‘nietsuccespad (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

●

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 

J.,Enterprise Ontology - Theory and Methodology. Springer, 2006

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

Ook al is iets goed gedaan, lever altijd kritiek. 





Eis zelf als manager alle ‘credits’ op.

Los problemen op met allerlei bureaucratische processen. 



Geef testers zinloze taken.

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

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

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!  

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 Scrumproject 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

Scrum-teams zijn volledig zelf organiserend en spelen zelf in op veranderende

neem initiatief en

omstandigheden (bijvoorbeeld gewijzigde prioriteit, scope).

verantwoordelijkheid 2. Begin met het eind in

Scrum-teams hebben het doel helder voor ogen door specifieke hulpmiddelen te

gedachten

gebruiken, zoals: product vision/statement, release plan, sprint plan.

werk vanuit je visie 3. Belangrijke zaken eerst

Een geprioriteerde product backlog zorgt ervoor dat het Scrum-team werkt aan items

werk vanuit belang en niet vanuit

met de hoogste waarde. Intensieve samenwerking tussen de Product Owner, Scrum

urgentie

Master en Scrum-team is nodig.

4. Denk win-win

Niet alleen de prioriteit is belangrijk, maar ook een juiste balans van diverse items.

zoek oplossingen met wederzijds

Bijvoorbeeld

voordeel

testautomatisering, refactoring). Zo wordt iedereen gediend (klant, architect, team,

procesverbeteringen,

wegwerken

technische

schuld,

optimalisatie

…) 5. Eerst begrijpen, dan begrepen

Dé top-focus van het team is om waarde te leveren aan de klant. In de ideaalsituatie

worden

wordt direct nauw samengewerkt met de eindklant om het product volledig te

empathisch luisteren

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

De sleutel voor goede synergie in een Scrum-team ontstaat bij een volledig

creëer samen meer dan de som van

empowered

de individuen

multidisciplinair en complementair: niet alleen qua skills maar ook qua persoonlijkheid.

team

en

gezonde

transparante

samenwerking.

Het

team

is

Ze kennen elkaars specifieke sterkten en zwakten en houden hier rekening mee. 7. Houd de zaag scherp

Er heerst een cultuur waarbij continue verbeteren mogelijk is. Bijvoorbeeld door naast

onderhoud en vernieuw jezelf

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

How much value can the team plan and achieved to the ∑ Original Estimates of

Velocity

Work Capacity

Product Owner's satisfaction in a sprint?

All Approved Cards

How much effort can the Team expend in a sprint?

∑

All

Work

Reported

During the Sprint How much work did the Team ultimately commit to achieve in

Total Commitment

the Sprint, including Adopted Work pulled forward after the Planning Meeting?

∑ Original Estimates for All User Stories

What percentage of the Team's total energy expenditure Velocity

Focus Factor

results in requested-and-approved value?

÷

Work

Capacity

As a percentage of the Original Commitment, how much (∑ Original Estimates for Adopted Work

additional work did the Team need to pull forward before the Work Pulled Forward) ÷ end of the Sprint in order to stay engaged?

Original Commitment

As a percentage of the Original Commitment, how much (∑ Work Reported per unexpected complexity did the Team discover mid-Sprint on Card

Found Work

the work they had already committed to do?

-

∑

Original

Estimates)

÷

Original Commitment Targeted

Value

Contribution Increase

Accuracy of Estimation

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

How accurate are the Story Point estimates that the Team 1 - (Estimate Delta ÷ provides for their Work?

Total Commit)

When the Team commits to work, how accurate are they in (∑Original Estimates) ÷ Accuracy Commitment

of biting off a block that will keep them busy, at a sustainable (∑Original Estimates + pace and be delivered by the end of the Sprint?

∑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

Teamleden doen niet mee aan (fun) teamactiviteiten

taak Teamleden zijn trots op hun team en het werk dat ze

Teamleden schamen zich soms voor hun team

doen Teamleden doen nét even wat meer, ook al betekent

Teamleden hebben een ‘9 tot 5’ mentaliteit

dat incidenteel extra werk moeten verzetten Teamleden bezwijken niet onder hoge druk of lastig

Teamleden geven makkelijk op als problemen zich

situaties

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-TeamMorale.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 NENISO 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. 