Najaarsspecial Oktober 2013

Najaarsspecial Oktober 2013

Najaarsspecial Oktober 2013 BIJ DE VOORPAGINA Nee, TestNet Nieuws is niet ineens overgenomen door Artis. En we zijn ook geen reisbureau begonnen. Deze cover vraagt aandacht voor het thema Context. Kijk maar eens goed. De ijsbeer op beide foto’s is precies dezelfde. Het enige wat verschilt is de context, het landschap waarin hij is afgebeeld. En toch zien we beide beren verschillend: de ene is een stuk bruiner dan de andere. Gezichtsbedrog, weliswaar, maar toch. De context; als tester trekt die minstens even sterk onze aandacht. Een ijsbeer aan een zonovergoten strand is best wel apart en daar kleurt hij bruin; tussen de ijsbergen is hij in zijn element en wit zoals het hoort. Deze TestNet Nieuws Special is, in het kader van het thema van het Najaarsevenement 2013, geheel gewijd aan het thema Context Driven testen. Lees verder hoe wij onze kijk op ons testobject steeds weer kunnen, ja zelfs moeten, afstemmen op de context ervan.

Pagina 1

Oktober 2013 • Jaargang 17 • Najaarsspecial www.testnet.org [email protected]

VAN DE REDACTIE Door Hans van Loenhoud ● [email protected]

@hansvanloenhoud

Dit artikel is geschreven in een bepaalde context: de Special van TestNet Nieuws, die in het kader van het najaarsevenement 2013 aan het onderwerp Context Driven Testen is gewijd. En jij, beste lezer, leest dit artikel weer in een andere context. Misschien als voorbereiding op deelname aan het evenement, om te bepalen welke presentaties je wilt bezoeken, of juist achteraf, om in te halen wat je jammer genoeg hebt gemist. Mijn probleem is een beetje dat ik jouw context niet ken. Terwijl die eigenlijk onmisbaar is om een goed stukje te schrijven. Ik schrijf het immers niet voor mezelf, maar voor de lezer, ieder met haar of zijn eigen context. Ik zeg niets nieuws wanneer ik beweer dat je niet kunt testen zonder context. Ik citeer maar even uit de Seven Testing Principles van ISTQB Foundation: Principle 6 - Testing is context dependent. Dat weten we dus al meer dan tien jaar. En is dat nu ineens hot, omdat we van context dependent naar context driven zijn gegaan? Ik dacht van niet. Dit onderwerp staat in de schijnwerpers vanwege de context: het is de steen in de anders zo rustige testvijver, die heeft geleid tot gloedvolle betogen, felle discussies en vlammende polemieken tussen de structured testers en contexters. Deze TestNet Nieuws Special kiest geen partij in deze polemiek. Wij kijken liever naar wat ons verbindt dan naar wat ons verdeelt, wij zijn meer van ‘Onderzoekt alle dingen en behoudt het goede’ (1 Tessalonicenzen 5:19-21). Veel goeds over Context Driven testen vind je terug in deze TestNet Nieuws. Een ruim tiental auteurs neemt je mee op een exploratory reis door dit terra incognita. Ieder vanuit zijn eigen context, dat dan weer wel…

COLOFON

Redactie

Bestuur

Paul Beving

Michiel Vroon

Kees Blokland

John de Goey

Astrid Hodes

Rik Marselis

Voorzitter Penningmeester Evenementen & thema-avonden, vice-voorzitter

Hans van Loenhoud Gerben de la Rambelje

Kees Blokland

Johan Vink

Bernd Beersma

Rob van Steenbergen

Harro Philip

Informatievoorziening & beheer Marktverkenning & werkgroepen Secretaris & ledenadministratie

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

Pagina 2

In dit nummer Van de redactie Van de voorzitter Wat is context-driven testen? Context-driven Test Process Improvement Testen is geen ‘kunstje’ Exploratief testen gedefinieerd De context van de context-driven De relatie tussen organisatiecultuur en testen Meer context-driven worden; een personal story Prestatie-inkoop bij de overheid Productrisico’s vragen om de juiste focus Context-driven testing: Hoe werkt dat? Complementing traditional sw testing through crowdtesting WIPM – Heuristiek voor een context-driven testaanpak Testscholen, kiezen of mixen?

1 3 4 9 12 17 23 26 30 32 36 38 43 46 49

Nieuws.testnet.org – TestNetNieuws wekelijks online Naast de vertrouwde publicatievorm als PDF, die de afgelopen tijd steeds vaker was gekoppeld aan het voorjaars- of najaarsevenement, is TestNet Nieuws dit voorjaar een nieuwe weg ingeslagen. De TestNetNieuws ‘Weekly’ verschijnt iedere week in de vorm van één artikel op de website. Daarnaast blijft deze 'Special', gewijd aan het voor- of najaarsevenement, gewoon bestaan. Surf eens naar onze nieuwe TestNetNieuws op http://nieuws.testnet.org!

Pagina 3

VAN DE VOORZITTER Door Michiel Vroon ● [email protected] Context Driven Testing – het houdt de gemoederen al een tijdje bezig. Met mijn huidige context van 1312 meter lang*) weet ik als geen ander dat je omgeving een grote rol speelt bij de opzet van je testaanpak. De principes van deze overtuiging zijn dan ook niet de zaken waar ik me over verbaas. Nee, het zijn de emoties die me de wenkbrauwen doen fronsen. De emotie die het teweegbrengt wanneer een ware ‘believer’ van deze testschool zijn boodschap verkondigt, is opmerkelijk te noemen. Nu kenmerkt het vakgebied van de IT zich naar mijn ervaring sowieso als een emotionele laagvlakte en vormen wij als testgemeenschap wellicht de Pyreneeën daarin. Maar toch. De emoties lopen soms erg hoog op en laat ik eerlijk zijn, dat mag, sterker, dat moet. Elk geloof heeft zijn eigen revolutie met daarin zijn martelaren en afvalligen. Het juist erover kunnen blijven discussiëren geeft eenieder zijn soms noodzakelijk uitlaatklep en voorkomt dat het geheel explodeert. Alleen… en daar moeten we allemaal scherp op zijn, deze discussies met hun soms scherpe kantjes zijn alleen bestemd voor op ons eigen beschermende podium. Daarbuiten gelden de reguliere omgangsvormen zoals we die binnen de context van onze samenleving hebben afgesproken. Heel veel plezier en wijsheid toegewenst bij het lezen van deze TTN en wellicht tot ziens op het najaarsevenement. De voorzitter *) De Coentunnel waarvan tijdens mijn afwezigheid bij het voorjaarsevenement een foto is getoond!

Pagina 4

WAT IS CONTEXT-DRIVEN TESTEN? Door Huib Schoots ● [email protected]

@huibschoots

Het thema van het komende TestNet evenement is context-driven testen. Maar wat is context-driven testen nu precies? En hoe ziet dat er dan in de praktijk uit? In dit artikel probeer ik uit te leggen wat context-driven testen is. Wil je meer weten, kom dan naar mijn presentatie op het komende evenement in de grote zaal. Gewoon blijven zitten na de eerste keynote. In die presentatie ga ik ook in op vragen als: is context-driven een hype? Kan TMap context-driven zijn? Wat is context-driven testen? Context-driven testen is lastig te beschrijven. Vooral omdat iedereen het anders ervaart. Vraag tien context-driven testers om een definitie en een zeker aantal zal ‘dat hangt er van af’ antwoorden. In zekere zin is dat ook zo. Er is niet echt een definitie waar de hele community zich achter zal scharen. Want context-driven testen is niet alleen een aanpak, maar ook een paradigma en een community [1]. Het uitgangspunt voor een context-driven tester is het feit dat de wereld om hem heen een complexe, veranderlijke en onzekere plek is. Daarin is het dus noodzakelijk om je voortdurend aan te passen aan de context van dat moment. We zullen vaardigheden moeten ontwikkelen om te kunnen omgaan met de complexe, vaak dubbelzinnige en vluchtige, steeds veranderende wereld om ons heen. In de blogpost gepubliceerd op de website van DEWT [2] zegt James Bach: ‘Exploratory testing is het ultieme in adaptiviteit. Aanpassen, aanpassen, aanpassen, dat is exploratief testen. Exploratory testing is wanneer het ontwerp proces van testen en het uitvoeren van de test zijn getrouwd, samen in een interactief proces’. Toch een definitie? James Bach en Cem Kaner hebben in 2009 een blogpost geschreven waarin ze context-driven testen als volgt definiëren [3]: ‘Context-driven testers kiezen hun test doelstellingen, technieken en deliverables (met inbegrip van test documentatie) door eerst te kijken naar de details van de specifieke situatie, met inbegrip van de wensen van de stakeholders. De essentie van contextdriven testen is het toepassen van kennis en beoordelingsvermogen dat past in het project. De Context-Driven Test School plaatst deze benadering van het testen binnen een humanistisch, sociaal en ethisch kader. Uiteindelijk gaat context-driven testen over het beste doen wat we kunnen, met dat wat we krijgen. In plaats van te proberen "best practices" toe te passen, accepteren we dat een zeer verschillende aanpak het beste werkt in verschillende omstandigheden (zelfs verschillende definities van veel voorkomende test termen).’ De zeven principes Het meest opvallende dat geschreven is over context-driven testen zijn de zeven principes [4].

Er wordt vaak

naar verwezen, dus een verhaal over context-driven testen zou niet compleet zijn zonder deze principes: 1. De waarde van elke aanpak hangt af van de context. 2. Er zijn goede aanpakken in een bepaalde context, maar er zijn geen 'best practices'. 3. Mensen die samen werken, zijn het belangrijkste onderdeel van de context van ieder project.

Pagina 5

4. Projecten verlopen na verloop van tijd op een manier die vaak niet voorspelbaar is. 5. Het product is een oplossing. Als het probleem niet is opgelost, werkt het product dus niet. 6. Goed software testen is een uitdagend intellectueel proces. 7. Alleen door oordeelsvorming en vaardigheid, coöperatief uitgeoefend gedurende het gehele project, zijn wij in staat om de juiste dingen te doen op het juiste moment om onze producten effectief te testen. Michael Bolton verwijst in zijn keynote op Let’s Test in 2012 [5] naar de zeven principes van de context-driven school. Hij wijst erop dat elk beginsel onzekerheid in zich draagt. In een complexe wereld, moeten we in staat zijn om te gaan met die onzekerheid. Context-driven of toch niet? Onder de zeven principes op de website [4] wordt ook uitgelegd dat er vormen zijn die context-driven lijken, maar dat niet zijn. Context-aware (context-bewust) lijkt het meest op context-driven. Het voorbeeld op de website maakt het duidelijk. De IEEE Standaard 829 voor test documentatie begint met een visie op goede documentatie en moedigt de tester aan om de documentatie aan te passen aan de behoeften van de stakeholders. Dit is contextaware. Voor context-driven testing zijn de eisen van de stakeholders, de praktische beperkingen en mogelijkheden van het project het uitgangspunt. Voor de context-gedreven tester biedt de standaard suggesties in plaats van voorschriften. Voor meer uitleg over context-bewust, context-specifiek en context-imperial verwijs ik je graag naar de eerder genoemde website. Context-driven: een ultiem voorbeeld Ik herinner me een verhaal dat Michael Bolton vertelde over een ontmoeting tussen James Bach en Jerry Weinberg. Hij heeft het ook gebruikt in zijn keynote op CAST in 2011 [6]. Jerry vraagt James wat de eerste verantwoordelijkheid is van een tester. James antwoord dat hij er wel vijf weet en dat hij niet kan kiezen. Jerry zegt: ‘De eerste verantwoordelijkheid van een tester is om de situatie te verkennen. Zoiets als hoe je net de beperkingen van mijn vraag hebt uitgedaagd. Een tester is iemand die weet dat alles anders kan zijn. Testers moeten nieuwsgierig zijn. Dingen een beetje opschudden, zodat mensen dingen in een ander licht kunnen zien’. Lees het hele verhaal nog eens rustig na in de volledige transcriptie van de keynote (in het Engels). Voor mij is dit een fantastisch voorbeeld van hoe context-driven tester de vraag zou beantwoorden: werken met je gevoel en de randvoorwaarden van de vraag aftasten. Je hardop afvragen of dat wat ze van je willen, wel het beste is. Een eigen aanpak In juni 2012 schreef ik een blogpost met de naam ‘Adaptibility vs Context-Driven’ [7], die leidde tot een zeer interessante discussie op mijn blog. Joep Schuurkens schreef een geweldige reactie: ‘Volgens mij is een van de belangrijke aspecten van context-driven een enigszins filosofische testaanpak. Stel vragen, wees sceptisch, zet vraagtekens bij de validiteit (geconstrueerde "geldigheid") van wat er gezegd wordt door jezelf en anderen. Dit betekent dat je jouw aanpak eigen maakt op twee verschillende manieren. Allereerst, het is je persoonlijke, op maat aanpak en van niemand anders. Er is geen externe autoriteit om naar te verwijzen. Jij bent je eigen autoriteit als het gaat om het uitleggen en verdedigen van je testaanpak. Ten tweede, jij kent je aanpak van binnen en van buiten. Wat in die aanpak zit, is er omdat jij dat zo besloten hebt! En je kunt uitleggen waarom. Je kunt een beschrijving geven van je aanpak in drie zinnen, drie uur of drie dagen, afhankelijk van de situatie.’ Waarop Jesper L. Ottosen zegt: ‘ik zeg meestal dat ik zo context gedreven ben als de context toelaat’.

Pagina 6

Lessons learned in software testing Er zijn geen boeken die context-driven testen beschrijven. Met de voorgaande informatie lijkt dat logisch. Het enige boek dat in de buurt komt, is ‘Lessons learned in software testing: a context-driven approach’ door Cem Kaner, James Bach en Bret Pettichord. Geen boek dat de aanpak beschrijft, maar een boek vol met lessen die niet altijd waar hoeven te zijn. Of zoals de schrijvers zeggen in het voorwoord: het zijn hun lessen uit hun context en ze vragen je om vooral kritisch te zijn. Het is ook zeker geen boek dat je in één ruk uit zal lezen omdat de voorbeelden veelal los van elkaar staan. Tip: zie het als een scheurkalender: leg het boek op je bureau en lees één les per dag! Rapid Software Testen Toch is er een prima manier om in aanraking te komen met context-driven testen en het te ervaren: Rapid Software Testing [8]. Een training ontwikkelt door James Bach en Michael Bolton. En de beste training die ik in mijn leven gehad heb. Waarom? Omdat het me fundamenteel anders heeft laten denken over bepaalde dingen in mijn vak. Een bloemlezing van thema’s en onderwerpen die aan bod komen in de training zijn: ken uw missie, wees een dienst en geen belemmering, blijf vragen, ben kritisch, ben empirisch

(beroep

je

resultaten

uit

experimenten

en

niet

op

theorie),

verantwoordelijkheid, aandacht testbaarheid, heuristieken en een heuristische aanpak van testen, exploratie en een exploratieve aanpak, modellen, geloofwaardigheid, veiligheid taal, diversiteit en het gebruik van diverse half-maatregelen, focus op vaardigheden in plaats van procedures, de kunst van het verhalen vertellen over testen, testen is mensenwerk, denken: kritisch denken, maar ook systeemdenken, stilzwijgende en expliciete kennis en nog veel meer. Al deze onderwerpen zouden een heel artikel op zich zelf waard zijn en het gaat te ver om hier nu in detail op in te gaan. Ik adviseer eens op de websites van James of Michael te kijken voor meer informatie. Testen als een sociale wetenschap Ik zie testen als een sociale wetenschap. Testen gaat niet over techniek alleen. Het gaat veel meer over mensen en sociale interactie. Michael Bolton ging hier op in tijdens zijn presentatie ‘Testing Through The Qualitative Lens’ op EuroStar 2012 in Amsterdam waar hij zei: ‘Testen kan in het beste geval alleen beloven wat de sociale wetenschappen leveren: gedeeltelijke antwoorden die nuttig kunnen zijn’. Bovendien zegt hij: ‘Uitstekend testen is niet alleen maar computer wetenschap. Het omvat informatica, wiskunde en technische domeinen. Maar door je alleen te richten op programma's en functies laat je andere vragen over waarde en relaties, waaronder mensen, weg. Voor mij is een uitstekend testen meer als antropologie: interdisciplinair, systeem gericht, onderzoekend en het vertelt verhalen.’ Michael zet in zijn presentatie exacte wetenschappen af tegen de sociale.

Pagina 7

Als je hierover meer wil weten, verwijs ik je graag naar de serie blogposts die ik over dit onderwerp schreef op mijn blog [9]. Leren Ik heb eerder op testnieuws.nl een drieluik column geschreven over met de titel ‘Hoe word ik een software test expert’ [10]. Het gaat over wat een goede tester maakt en geeft tips over hoe je jezelf kunt bekwamen in het mooie testvak. De grote lijn is: blijf leren! Jaarlijks een paar dagen training is niet genoeg. Om echte goed te worden in je vak, zal je veel, heel veel, moeten oefenen! In een blogpost zegt James Bach [11]: ‘Testen is een oplossing voor een moeilijk probleem dat moet worden afgestemd op de context van het project. Testen is daarom een menselijke activiteit die een grote vaardigheid vereist om het goed te doen. Daarom moeten we het serieus bestuderen. We moeten ons vak oefenen. Contextdriven testers streven ernaar om de Jedi Knights van het testen te worden’. Peer workshops Het valt me op dat context-driven testers vaak bloggen. Dit helpt om ideeën uit te wisselen, maar ook om je ideeën aan te scherpen en erover te discussiëren. Continue leren is heel normaal voor context-driven testers. Via twitter worden links uitgewisseld en de community is erg actief. Het beste voorbeeld daarvan zijn peer conferenties. Over de hele wereld worden door kleine groepjes enthousiaste context-driven testers bijeenkomsten georganiseerd die vaak een hele dag of soms zelf een heel weekend duren. Tijdens deze bijeenkomsten wordt er serieus over testen gepraat. Hierover zegt James Bach op zijn blog [12]: ‘Een geweldige manier om de gevaren van best practices te vermijden, is door te praten over je eigen ervaringen en voorkeuren, in plaats van algemene voorschriften te maken. Dit is de reden waarom, in peer-conferenties zoals LAWST, we ons richten op ervarings verhalen (eigenlijk noemde we ze “oorlogsverhalen” tot onze terminologie werd aangevallen door bloeddorstige pacifisten) in plaats van te pleiten voor goede practices.’ Zelf zoek ik de community graag op. In peer conferenties of de reguliere conferenties waar we regelmatig in de avond of de dag voor de conferentie met een groep bij elkaar komen om met elkaar te praten over ons vak en van elkaar te leren. Het is geen kenmerk van de context-driven community, er zijn veel meer mensen die peer conferenties organiseren of bijwonen. Maar het valt me wel op dat er heel veel een context-driven inslag of origine hebben. Mijn persoonlijke ervaring Het boek Lessons Learned prijs ik al jaren aan als een van de beste boeken over testen die ik ooit gelezen heb. Daarnaast was ik al een tijd geïnteresseerd in exploratief testen en de blogs van Michael Bolton en James Bach. De cursus Rapid Software Testen was de aftrap van een grote verandering in mijn denken over testen. Een groot aantal puzzel stukjes die al jaren in mijn hoofd zaten vielen ineens op zijn plek. Bepaalde dingen kregen een naam. Inmiddels ben ik vrij actief op twitter, heb ik ook een blog en heb ik samen met zes andere testers een peer workshop DEWT (Dutch Exploratory Workshop on Software Testing) opgericht.

Pagina 8

Ik heb veel contact met mensen uit de context-driven community, via twitter, Skype en ik spreek hen regelmatig op conferenties. We praten over testen, delen interessante artikelen en boeken, reviewen elkaars artikelen, maar delen ook testware. Met een aantal deel ik een passie voor puzzels en we dagen elkaar regelmatig uit. Met James Bach doe ik Skype coaching [13] en dat is intensief maar bijzonder leerzaam. Ik kies een onderwerp of we praten over wat me bezig houdt en zo komen we op een onderwerp. Sessies duren ongeveer 90 minuten en daarin stelt James vragen of geeft korte opdrachten en ik werk die direct uit, leg uit wat ik denk en geef antwoorden. Zelf ben ik ook coach via Skype. Meer daarover kan je vinden op mijn weblog. En jij? Mogelijk heeft dit artikel je interesse gewerkt en wil je er meer over lezen of verder over praten? Op mijn weblog staat een mooie lijst met links. Bovendien heb ik recent twee blogs gepubliceerd met populaire weblogs en boeken voor testers. Ook de leden van DEWT helpen je graag verder. Neem contact met ons op! (Dit artikel is een bewerking van het artikel dat eerder gepubliceerd is in de TestKrant nr. 2 van testnieuws.nl met de titel: ‘Ik ben een context-driven tester! Joh? Echt waar? Nou en?’) Bronnen [1] Mind map gebruikt tijdens presentatie Context-driven Testing, Michael Bolton & James Bach, TestNet Thema avond Januari 2012 [2] Blogpost DEWT: http://dewt.wordpress.com/2012/02/09/context-driven-testing-testnet/ [3] Blogpost Cem Kaner en James Bach: What is context-driven testing? [4] Website: http://www.context-driven-testing.com [5] If it is not context-driven, you can’t do it here, Michael Bolton, keynote Let’s Test Conference, 2012 [6] Context-driven testing, Michael Bolton, keynote CAST 2011: http://www.developsense.com/presentations/2011-08-CAST-ContextDrivenTesting.pdf [7] Blogpost Huib Schoots: Adaptability vs Context-Driven [8] RST materiaal: http://www.satisfice.com/rst.pdf [9] Blogpost Huib Schoots: What testing can learn from social science [10] Column Huib Schoots: Hoe word ik een software test expert? [11] Blogpost James Bach: The Dual Nature of Context-Driven Testing [12] Blogpost James Bach: The Great Implication of Context-Driven Methodology [13] Website AST over Skype coaching Meer info Website DEWT: http://dewt.wordpress.com/ Links op mijn weblog: http://www.huibschoots.nl/links Website James Bach: http://www.satisfice.com Website Michael Bolton: http://www.developsense.com Website Cem Kaner: http://kaner.com

Pagina 9

CONTEXT DRIVEN TEST PROCESS IMPROVEMENT Door Kees Blokland ● [email protected]

@keesblokland

De uitvoering van Test Process Improvement (TPI) assessments heeft veel overeenkomsten met het testen zelf. Dat begint al bij de doelstelling. Een organisatie wil antwoord op de vraag: ‘Zijn we goed bezig?’ of ‘Op welke gebieden zijn we al goed bezig?’. Om dit doel te bereiken voer je controles uit op zoek naar bevestiging. Net zoals bij confirmation testing. Elke OK is goed nieuws: een bevestiging dat het op dit punt goed zit. Tegelijkertijd wil een organisatie antwoord op de vraag: ‘Hoe en wat kunnen wij verbeteren?’

Meestal is een bepaald knelpunt aanleiding voor het TPI initiatief, zoals te hoge testkosten of te veel bevindingen in productie. Het zoeken naar een antwoord op de hoe-vraag vergt onderzoek dat deels langs gebaande paden verloopt, maar vooral ook daarbuiten. Net als bij exploratory testing. Daarbij kan een TPI assessor niet zonder heuristieken. In de onderzoeksfase is dat bijvoorbeeld kennis van veel voorkomende problemen en knelpunten in allerhande testorganisaties: watervalgeoriënteerde organisaties kennen andere typische knelpunten dan agile teams, bij formele culturen spelen andere zaken dan bij informeel werkende teams. Eigenlijk heb ik persoonlijk alleen ervaring met dit soort context-driven assessments. Aan de hand van een assessment-casus, samengesteld uit diverse TPI trajecten waar ik aan heb meegewerkt, beschrijf ik hoe dat dan precies in zijn werk gaat. Assessment-casus Een organisatie vraagt ons te helpen bij twee vragen. Vraag één: ‘Wij hebben een periode van twee jaar intensieve testverbetering achter de rug. Hoe ver zijn we nu?’ Vraag twee: ‘Als we ons vergelijken met vergelijkbare bedrijven, besteden wij veel meer tijd (en dus geld) aan testen. Hoe kan het dat onze testefficiency zo laag is?’ In overleg is besloten een TPI assessment uit te voeren. Interviews en documentstudie zijn de pijlers voor informatievergaring bij een assessment. Daarnaast is een basislijst met rollen en functies startpunt voor wie we willen spreken. Een eerste interview, met een voor testen verantwoordelijke senior manager, gaat onder meer in op de vraag: ‘Wie moeten we zeker ook spreken?’ Ofwel, bij wie kunnen we goede en betrouwbare informatie verkrijgen om de vragen te beantwoorden die centraal staan bij het assessment? Dit is een belangrijk keuzemoment bij het uitvoeren van assessments. Exploreren De duur van een interview varieert grofweg tussen één en twee uur. Dit hangt onder meer af van het aantal onderwerpen dat met de persoon besproken kan worden. Met een testmanager kunnen in theorie alle aandachtsgebieden besproken worden. Dan is twee uur snel voorbij, zeker als het gesprek gemakkelijk verloopt en veel relevante informatie los komt. In bepaalde gesprekken blijkt dat je ‘beet hebt’. Je raakt de kern van een onderzoeksvraag en belangrijke informatie komt los. Dan is het zaak om een ‘exploratory koers’ in te zetten. Niet vasthouden aan het key area waar je mee bezig bent, maar meebewegen met de geïnterviewde om zoveel mogelijk nuttige informatie te krijgen.

Pagina 10

Met andere gesprekspartners verloopt het soms minder vlot en is het na een uurtje zoeken naar gespreksstof. Dat gebeurt wel eens in de laatste interviews als je al veel weet of spreekt met mensen die minder intensief bij het testen betrokken zijn. Mis-niks-route Bezoekers aan dierentuinen zijn vertrouwd met wegwijzers die je langs alle diersoorten leiden. Dit is de zogenoemde mis-niks-route. Neem een bus mensen van een georganiseerde reis: ze willen zoveel mogelijk van het park zien. Zij verliezen de mis-niks-route niet uit het oog! Met ons abonnement op de dierentuin kiezen we echter met de kinderen vaak voor een thema: vandaag de nachtdieren, of vooral speeltuinen. Dan moet je dus niet vasthouden aan de mis-niks-route, maar een flexibele route kiezen. Zo kijk ik ook tegen de vaste onderwerpen van een TPI-model aan. Als een organisatie agile werkt, vooral real-time software maakt, hele grote of juist hele kleine projecten doet of als de maatschappelijke cultuur doorklinkt in het dagelijkse werk, dan heeft dat invloed op de keuzen die je maakt gedurende het assessment. In onze casus hebben we te maken met een grote organisatie, veel te interviewen mensen en men verwacht van ons een compleet plaatje. Wij moeten aan het eind van het assessment alle paden van de mis-niks-route minimaal een keer bewandeld hebben. Doelstelling Niet in de laatste plaats is de doelstelling van de opdrachtgever van belang. Het efficiencyvraagstuk in de casus is een bijzondere. Langs de TPI-vragen is niet direct duidelijk waar het aan zou kunnen schorten. Tot we een goed plaatje tekenen van de organisatie: de testwerkzaamheden zijn zo versnipperd over verschillende functies dat men heel veel tijd verliest aan overdragen van noodzakelijke kennis. Rapportage lijkt prima geregeld, tot we er achter komen dat er wel drie, soms vier, managers zich met het testen bemoeiden. Ook niet bepaald efficiënt. Als je dus niet buiten de gebaande paden gaat of af en toe een ander gezichtspunt kiest (de helikopter erop), dan kan het knap lastig zijn de doelstelling te behalen. De Fase Van De Grote Verwarring Inmiddels zijn we een flink stuk onderweg in het assessment en het plaatje wordt aardig compleet. We zijn overtuigd dat we het lijk boven water hebben en we willen verder met het inkleuren van details. De PowerPoint voor de eindpresentatie staat al in de steigers en dan gebeurt het. Een interview die het hele bouwwerk aan het wankelen brengt. ‘Risk based testen? Nee hoor, ik maak mijn testgevallen nog net als altijd. Op basis van mijn kennis en gevoel.’ Paf. Er vallen in één keer weer grote gaten in de TPI-matrix… die zich juist zo lekker liet vullen. Hebben we niet opgelet? Hebben we ons zaken op de mouw laten spelden? Self fullfilling prophecies? Deze fase van grote verwarring is normaal en bewijst elke keer maar weer dat je in een assessment belangrijke informatie uit minstens twee bronnen moet halen. Wat je in het vorige interview hoorde in een volgend interview meteen meenemen en controleren. Double checken. Zelfs aan het eind van het assessment kan dit gebeuren. Dan moet je soms zelfs extra interviews regelen (altijd wat marge inbouwen dus). Working in pairs en sessions Een goed assessment uitvoeren doe je met zijn tweeën. Zeker bij lastige vraagstukken, in politieke organisaties of in een andere complexiteit-verhogende context. Je moet als assessors elkaar uitdagen, het met elkaar oneens zijn totdat de conclusies of tussenconclusies ‘staan’.

Pagina 11

Na de eerste sessie van een aantal interviews wordt samen stilgestaan bij de ‘charter’ voor de volgende sessie interviews. Wat weten we al, waar moeten we ons in het bijzonder op richten in de volgende sessie van interviews? In ons assessment zijn we aardig op weg naar de conclusies. Kijkend naar de voorlopige ingevulde TPI-matrix schrikken we een beetje: vol gaten, terwijl we toch echt het gevoel hadden dat veel zaken goed liepen. We moeten in de volgende sessie voldoende tijd in de interviews inruimen om zorgvuldig een aantal details na te lopen. Op basis van die details kunnen we met een gerust hart de vakjes in de TPI-matrix afvinken. Dit noem ik wel eens oneerbiedig checkpoint hunting om witte vlekken in de assessmentdekking te voorkomen. Hoewel in een interview de ene assessor vaak het interview leidt en de andere assessor zorgt voor goede verslaglegging, kunnen de rollen tijdens een gesprek zomaar omdraaien. Elkaar aanvullen geeft extra kwaliteit en zorgt voor een beter resultaat van het interview. Bij het beoordelen van de TPIcheckpoints in de analysefase van het assessment is dat ook van groot belang. Hebben we genoeg bewijs dat het checkpoint akkoord is of hebben we juist argumenten voor het tegendeel? Terugkerende discussies: wat is de begrenzing van de organisatie, wie hoort daar allemaal bij? Wanneer is het goed? Een acht, of een tien? Dat moet je aanvoelen. Wat is passend in de context? Met zijn tweeën kom je daar beter uit dan alleen. Het is van belang dat je aan elkaar gewaagd bent: tegenspraak is gewenst! Rapport De interviews zijn voorbij en de documenten zijn bestudeerd. Nu komt het erop aan de bevindingen en conclusies helder te formuleren. We leveren niet alleen een TPI-matrix op, maar juist ook wat verder is opgevallen. Daar zitten voor een organisatie zeer waardevolle aanvullende aanbevelingen in. In onze casus kan de organisatie tevreden zijn. Veel controlled checkpoints zijn akkoord bevonden, evenals flink wat efficiënt controlepunten. Dit geeft de organisatie de bevestiging dat de verbeteringen hun vruchten af hebben geworpen. Tegelijkertijd moeten we de vinger op de zere plek leggen met betrekking tot de efficiency, of eigenlijk het gebrek eraan. Dat moet met de nodige tact, want een tamelijk hoge manager heeft de verregaande splitsing in rollen, één van de oorzaken, ingevoerd. Conclusie Bij het uitvoeren van TPI-assessments kun je niet om de context heen. Evenals bij testen zelf ligt de kracht van de aanpak in het zoeken van de juiste balans tussen de gestructureerde route en exploreren. Creativiteit, heuristiek, exploreren, logica, overzicht, discussie en structuur zijn sleutelwoorden voor een geslaagde assessment. En het allerbelangrijkste: niet de methode is het startpunt van een assessment maar de context!

Pagina 12

TESTEN IS GEEN ‘KUNSTJE’; ADAPTIVITEIT MAAKT VAN TESTEN IN JOUW CONTEXT EEN ‘KUNDE’! Door Leo van der Aalst en Rik Marselis ● [email protected] ● [email protected]

@rikmarselis

Testen is nooit eenheidsworst. Ongeacht welke aanpak of methode wordt gebruikt, of het nu over ontwikkelaanpakken of over testaanpakken gaat, iedere organisatie en elk project gebruikt ze op een manier die is afgestemd op de context waarin wordt gewerkt. Zo werkt dat ook met het adaptief toepassen van TMap. Maar adaptief toepassen, hoe doe je dat? Wat is de TMap ‘jigsaw puzzle’? Beetje context … Weet jij hoeveel ontwikkel- en testaanpakken er de laatste zeventig jaar (sinds de bouw van de eerste computer) zijn bedacht en gebruikt? Geen idee? In ieder geval: veel! Nog nooit hebben we gezien dat een aanpak volledig (‘as is’) wordt overgenomen door een organisatie. En dat moet ook niet, want iedere organisatie is uniek en daarom past elke organisatie de aanpak aan op de eigen specifieke context. Eind jaren ’80 werkte Leo bij de Belastingdienst. Daar testten ze gestructureerd, Martin Pol had zojuist het Handboek Testen gepubliceerd. Dat handboek was later, in 1995, de basis voor TMap. We hebben dit in 2006 verder uitgewerkt tot TMap NEXT dat steunt op vier essenties, business driven testmanagement, een gestructureerd proces, de complete gereedschapskist en adaptiviteit. Door de jaren merken we steeds duidelijker dat de belangrijkste van deze vier essenties de ‘Adaptiviteit’ is. In de periode van eind ’80 tot heden hebben we bij vele organisaties in vele landen gezien hoe TMap telkens aangepast werd aan de context waarin het werd gebruikt. Het lijkt wel of de situaties waarin we werken steeds diverser worden, waardoor het belang van de adaptiviteit ook steeds groter wordt. Gelukkig zijn veel ervaringen herbruikbaar. Op basis daarvan hebben we voor bepaalde veelvoorkomende situaties zelfs specifieke toepassingsvarianten geschreven, om organisaties een vliegende start te geven. Kijk bijvoorbeeld naar ‘Testen van ketens met TMap NEXT (2009)’, ‘TMap Infrastructuur (2012) en het recent verschenen (en veel geroemde) ‘TMap NEXT in scrum’. Adaptiviteit – de puzzelstukjes In dit artikel laten wij je zien hoe je de essentie ‘Adaptiviteit’ van TMap ten volle kunt benutten. Zo kun je voorkomen dat je in de valkuil van het ‘toepassen van een kunstje’ valt, maar juist toewerkt naar het waarborgen van kwaliteit op een manier die in jouw situatie effectief en efficiënt is. En je zult zien dat je ook in jouw context houvast en nuttige toepassing vindt voor het enorme scala aan onderwerpen, werkwijzen, technieken en hulpmiddelen die in het TMap gedachtegoed bij elkaar zijn gebracht, waardoor testen in elke context een ‘kunde’ wordt! Maar hoe doe je dat dan? Eerst leg je alle puzzelstukjes uit: Testactiviteiten, testtechnieken, testproducten, testorganisatie en testinfrastructuur.

Pagina 13

Figuur 1: De TMap puzzelstukjes Vervolgens kijk je naar de context waar je in werkt. Laten we zeggen, een scrumomgeving. Wat in een scrumomgeving prominent aanwezig is, zijn de scrum events: Project planning, sprint planning, sprint, daily scrum, review en retrospective. Veel organisaties starten een scrumproject met het zogenoemde sprint 0 event, dus die voegen wij ook toe. Hoe passen de TMap puzzelstukjes hier in? Om dit artikel niet te lang te maken, laten we dit alleen voor het puzzelstukje ‘testactiviteiten’ zien, voor de complete inpassing verwijzen we graag naar ons EuroSTAR eBook of het boek (zie literatuurlijst).

Goed, activiteiten dus; TMap kent 53 activiteiten die je kunt

gebruiken, aanpassen, verwijderen of waar je zelf activiteiten aan kunt toevoegen. Testactiviteiten – sprint 0 In sprint 0 worden vaak ‘inrichtingsactiviteiten’ uitgevoerd. Denk aan het houden van een kick-off, het inrichten van tools, het opstellen van een definition of done, de procesinrichting, het opstellen van een communicatieplan en het verzorgen van trainingen. Aangezien het testen in scrum volledig geïntegreerd is met de ontwikkelactiviteiten, is het goed om te bedenken welke testsoorten in een sprint moeten worden uitgevoerd. Verder is testen een rol in scrum, dus ook niet-professionele testers zullen worden gevraagd om te testen. Dan is het goed om deze teamleden de benodigde testkennis en/of testvaardigheden te geven via een training of workshop. Dit event leent zich ook om een begin te maken met het inrichten van de testinfrastructuur (inclusief tooling) en het testwaremanagement. Uiteraard moeten alle (test)afspraken in de definition of done worden opgenomen (zie Figuur 2).

Figuur 2: Testactiviteiten puzzelstukjes in sprint 0 Testactiviteiten – project/sprint planning In de scrum events; project/sprint planning wordt onder andere een product/sprint backlog opgesteld en een inspanningsinschatting in story points van elk backlog item (vaak met planningpoker) gemaakt. Welke restactiviteitenpuzzelstukjes passen hier dan bij?

Pagina 14

Ook in scrum geldt dat je niet de tijd hebt om alles te testen, dus het uitvoeren van een productrisicoanalyse en het opstellen van een teststrategie per backlog item helpt om hierin een goede afweging te maken. Het kennen van het productrisico voordat met planningpoker wordt begonnen, helpt om sneller tot overeenstemming te komen bij het toekennen van de story points. Het productrisico kan met risicopoker worden bepaald en wordt op de storycard gezet, zodat deze bij planningpoker wordt meegenomen in de afwegingen. Degene in de testrol stelt ‘kritische vragen’ aan de product owner over de backlog items (dit zijn bijvoorbeeld user stories). Als de antwoorden bevredigend zijn, is in feite de intake (het toetsen) van de testbasis afgerond en zijn eventuele onduidelijkheden gecommuniceerd (zie Figuur 3).

Figuur 3: Testactiviteiten puzzelstukjes in project/sprint planning Vervolgens kijk je naar de context waar je in werkt. Laten we zeggen, een scrumomgeving. Wat in een scrumomgeving prominent aanwezig is, zijn de scrum events: Project planning, sprint planning, sprint, daily scrum, review en retrospective. Veel organisaties starten een scrumproject met het zogenoemde sprint 0 event, dus die voegen wij ook toe. Hoe passen de TMap puzzelstukjes hier in? Om dit artikel niet te lang te maken, laten we dit alleen voor het puzzelstukje ‘testactiviteiten’ zien, voor de complete inpassing verwijzen we graag naar ons EuroSTAR eBook of het boek (zie literatuurlijst). Goed, activiteiten dus; TMap kent 53 activiteiten die je kunt gebruiken, aanpassen, verwijderen of waar je zelf activiteiten aan kunt toevoegen. Testactiviteiten – sprint en daily scrum In de scrum events; sprint en daily scrum worden de producten gerealiseerd. Hierin vinden de welbekende en veelvoorkomende testactiviteiten plaats. Uiteraard het maken en uitvoeren van testgevallen (hetzij ‘specification based’, hetzij ‘experience based’, en bij voorkeur een combinatie hiervan). Eventuele bevindingen worden gecommuniceerd en waar nodig geregistreerd, testuitvoering wordt al dan niet geautomatiseerd en testware wel of niet geconserveerd. Dit alles is afhankelijk van wat het scrumteam in de definition of done heeft afgesproken. Tijdens de daily scrum wordt over testvoortgang gerapporteerd door het bijwerken van bijvoorbeeld het scrumboard en de burndown charts (zie Figuur 4).

Pagina 15

Figuur 4: Testactiviteiten puzzelstukjes in sprint en daily scrum Testactiviteiten – review en retrospective Tot slot de scrum events; review en de retrospective. Tijdens de review wordt (vaak door degene in de testrol) een productdemo uitgevoerd, waarna de product owner het product wel of niet accepteert. En tijdens de retrospective wordt onder andere een evaluatie van het testproces uitgevoerd (zie Figuur 5).

Figuur 5: Testactiviteiten puzzelstukjes in review en retrospective

De ‘jigsaw’ puzzle is gelegd Door de puzzelstukjes aan elkaar te leggen onder het scrummodel is de puzzel gelegd en heb je precies die onderdelen uit het testgedachtegoed hergebruikt die voor jou toegevoegde waarde bieden. Zie het eindresultaat in figuur 6.

Pagina 16

Figuur 6: De puzzel compleet Conclusie Hiermee hebben we in vogelvlucht laten zien hoe we TMap-testactiviteiten hebben hergebruikt, aangepast, toegevoegd en verwijderd naar aanleiding van de context (in dit geval de scrumomgeving) waarin moet worden getest. Deze benadering is voor elke context mogelijk. En uiteraard werkt dit ook voor de puzzelstukjes testtechnieken, testproducten, testorganisatie en testinfrastructuur. Door over dit alles goed na te denken, hergebruik je op een efficiënte manier de bestaande kennis en ervaring en daarmee maak je van testen geen ‘kunstje’ maar een ‘Kunde’ in jouw context! Adaptiviteit werkt! Literatuurlijst TMap NEXT voor resultaat gericht testen TMap NEXT Business Driven Test Management TMap NEXT in Scrum Testen van ketens met TMap NEXT TMap Infrastructuur EuroSTAR eBook ‘Integrate Test Activities in Agile Projects’

Pagina 17

EXPLORATIEF TESTEN GEDEFINIEERD… HARDNEKKIGE MYTHES ONTKRACHT! ’Het is niet de sterkste van een soort die overleeft, ook niet de intelligentste. Wel degene die zich het beste aan veranderingen kan aanpassen.’ (Charles Darwin) Door Huib Schoots ● [email protected]

@huibschoots

Er is veel gezegd en geschreven over exploratief testen (Engels: exploratory testing). Helaas blijkt dat exploratief testen nog vaak onbegrepen is. Veel te vaak lees ik onjuistheden over exploratief testen. Dit artikel zet kort en bondig uiteen wat exploratief testen is, hoe het kan worden gepland, gestructureerd en hoe het traceerbaarheid biedt. Daarnaast worden enkele onjuistheden gecorrigeerd die gepubliceerd zijn.

Definitie Exploratief testen (ET) is een benadering van het testen van software die bestaat uit simultaan leren, testontwerp en testuitvoering. Cem Kaner, die de term in 1983 voor het eerst gebruikte, definieert het als ‘een manier van testen van software die de persoonlijke vrijheid en de verantwoordelijkheid van de individuele tester benadrukt door voortdurend de kwaliteit van zijn/haar werk te optimaliseren door testgerelateerd leren, testontwerp, testuitvoering en interpretatie van de testresultaten als onderling ondersteunende activiteiten te beschouwen die gedurende het project parallel lopen.’ Het wezenlijke kenmerk van ET is dat de tester actief bezig is met de software. Het testen is een cognitief proces: actief, doelgericht en nieuwsgierig wordt de software onderzocht. Terwijl de software wordt getest, doet de tester kennis op die weer input is voor verdere testen. Test techniek? Exploratief testen wordt vaak gezien als een blackbox-testtechniek, maar de context-driven beweging beschouwt het als een manier van testen, een testaanpak of methodiek die kan worden toegepast op elk testproces, in ieder stadium van het ontwikkelingsproces. Het is niet afhankelijk van gekozen de testtechniek, noch van het object dat wordt getest. Iedere testtechniek kan exploratief of vooraf gescript worden uitgevoerd. Ad-hoc Wikipedia meldt het volgende: ‘Ook is het mogelijk en heel populair om minder gestructureerd (ad hoc) te testen zoals “exploratory testing” of “error guessing”. Voordeel daarvan is dat het weinig voorbereiding kost, nadeel is dat er mogelijk niet volledig getest wordt. Ook kunnen gevonden fouten niet reproduceerbaar zijn, waardoor ze moeilijker te vinden en te herstellen zijn.’ [1] ET is inderdaad ad hoc, want ad hoc betekent letterlijk ‘voor dit speciale geval’ of ‘eenmalig’ of ‘voor één bepaald doel’. Maar dat wil niet zeggen dat het niet gestructureerd is. ET is uitermate gestructureerd. Hier kom ik hieronder op terug in de paragraaf over structuur. Daarnaast beweert Wikipedia dat er mogelijk niet volledig getest wordt. Door ET goed toe te passen, zoals ik beschrijf in dit artikel, zorgt de tester ervoor dat er precies genoeg getest wordt en de belangrijkste testen als eerste worden uitgevoerd. De laatste opmerking in de tekst van Wikipedia zegt dat gevonden fouten niet reproduceerbaar zijn. Door goede bevindingen te schrijven hoeft dit helemaal geen probleem te zijn.

Pagina 18

Betere bevindingen met ET [2] In 2007 is er onderzoek gedaan naar de effectiviteit van het vinden van bugs. Opvallend genoeg bleek dat traditioneel en exploratief testen even effectief waren als je kijkt naar de testuitvoertijd, het aantal en de ernst van de gevonden fouten. Maar het traditionele testen nam vijf (!) maal zoveel tijd in beslag vanwege de voorbereiding. Bovendien werden bij het traditionele testen twee keer zoveel foutieve bugs gemeld. Informatie verzamelen en leren Testen wordt vaak gezien als een exacte wetenschap. Ik denk dat testen veel meer een sociale wetenschap is. Een zoektocht is naar informatie, het verzamelen en vastleggen van informatie over zaken die belangrijk zijn. Jerry Weinberg definieert testen als: ‘het verzamelen van informatie om een beslissing te informeren’. Rikard Edgren (key-note spreker op het komende najaarsevenement) schreef recent een briljante ‘open brief’ waarin hij testen definieert [3]. Testen is veel meer dan bugs vinden en kijken of aan requirements is voldaan. Testen is vooral leren. Een aspect dat in ET centraal staat! Structuur Ik leg ET graag uit aan de hand van de volgende illustratie:

1. Test strategie Ook in een ET traject zal er een test plan worden opgesteld. Ik gebruik hiervoor graag mindmaps en maak daarbij gebruik van het Heuristic Test Strategy Model (HTSM) van James Bach [4]. Mindmaps zorgen dat mijn plannen kort en bondig blijven, het HTSM geeft houvast (structuur) om de juiste zaken te beschrijven. Met de klant bespreek ik de gewenste dekking en leg die vast met behulp van ‘San Francisco Depot’ [5] in een aparte mind map. Dit zal tevens het uitgangspunt zijn van mijn testen. Indien nodig maak ik nog een mind map met de productrisico’s.

Pagina 19

2. Generiek Als input gebruik ik documenten en lijstjes die ik voor meerdere projecten gebruik, je zou ze kunnen zien als een soort van libraries. Een overzicht van alle productrisico’s kan een mooie checklist zijn om te zorgen dat we geen risico’s over het hoofd zien. Een lijst met testideeën uit voorgaande projecten heeft hetzelfde doel, maar dan voor de uit te voeren testen. Testideeën Uit mijn ervaring blijkt dat het bedenken van testideeën één van de moeilijkste dingen is in het testen. Om dit probleem te tackelen, gebruik ik vele bronnen ter inspiratie: •

Heuristic Test Strategy Model - http://www.satisfice.com/tools/htsm.pdf

•

ET dynamics (te vinden in de appendices van Rapid Software testing) - http://www.satisfice.com/rstappendices.pdf

•

The Little Black Book on Test Design http://www.thetesteye.com/papers/TheLittleBlackBookOnTestDesign.pdf

•

Software Quality Characteristics (UK) http://thetesteye.com/posters/TheTestEye_SoftwareQualityCharacteristics.pdf

•

Software Kwaliteit Kenmerken (NL) http://dewt.files.wordpress.com/2013/03/thetesteye_softwarekwaliteitkenmerken1.pdf

•

Test Heuristics Cheat Sheet - http://testobsessed.com/wpcontent/uploads/2011/04/testheuristicscheatsheetv1.pdf

•

Several Checklists - http://sqa.fyicenter.com/FAQ/Software-Testing-Check-List/

•

Touring Heuristic - http://michaeldkelly.com/blog/2005/9/20/touring-heuristic.html

•

You Are Not Done Yet - http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf

•

8-layer testing model - http://www.shino.de/2012/03/23/testbash-an-8-layer-model-for-exploratorytesting/

Heuristieken Een heuristiek is een feilbare methode voor het oplossen van een probleem of het maken van een beslissing. Heuristieken zijn informele, intuïtieve oplossingsstrategieën, die mensen ontwikkelen om bepaalde problemen aan te pakken. In tegenstelling tot algoritmen, die altijd en overal werken, zijn heuristieken specifieke strategieën die we gebruiken in specifieke situaties, maar niet altijd een oplossing garanderen. Het komt dus aan op de vaardigheden van de tester om deze goed en effectief te gebruiken. Meer lezen hierover: http://www.questioningsoftware.com/2007/04/heuristics-in-software-testing.html http://www.developsense.com/blog/2012/04/heuristics-for-understanding-heuristics/

Pagina 20

3. Doorlopende planning Net zoals in agile wordt gebruikt, geef ik de voorkeur aan een dagelijkse planningssessie met behulp van een whiteboard. Zodoende zorgen we dagelijks dat we de meest belangrijke testen uitvoeren. Bovendien is zo’n sessie een uitstekende manier om elkaar op de hoogte te houden.

Op het whiteboard plak ik stickies die testcharters voorstellen. Testcharters zijn missies voor een testsessie beschreven in één tot drie regels. Voorbeelden van charters zijn: ‘Lees hoofdstuk 4 van de productspecificatie. Maak een mindmap en bespreek het met Peter (programmeur) en David (architect). Onderzoek het menu import van applicatie X. Identificeer belangrijke functies, maak een dekkingsoverzicht en een risicolijst. Test de interface van Applicatie A met Applicatie B. Controleer of de schermen van Applicatie C voldoen aan de Windows standaard. 4. Dagelijkse test sessies Testen worden uitgevoerd in onafgebroken sessies van maximaal negentig minuten. Per sessie wordt een charter uitgevoerd. Gedurende de sessie maakt de tester uitgebreide aantekeningen. Indien mogelijk wordt een tester dagelijks gedebrieft door een collega. In deze debriefing ondervragen ze elkaar over de uitgevoerde testen. Deze review/coaching sessies zorgen ervoor dat er niets over het hoofd gezien wordt. Tijdens het testen, maar ook tijdens de debrief kunnen nieuwe charters ontstaan. 5. Issues, bevindingen en session sheets Charters worden zoveel mogelijk na iedere sessie uitgewerkt tot session sheets waarin de volgende zaken worden vastgelegd: charter, tester, datum, geraakte functionaliteit, gebruikte bestanden en data, bevindingen, issues en eerder gemaakte aantekeningen. Net als in ieder ander testtraject worden issues en bevindingen vastgelegd.

Pagina 21

Issues zijn problemen die de voortgang van het testen in gevaar brengen, bevindingen zijn problemen die de waarde van het product in gevaar brengen. ET is lastig Althans als je het goed wilt doen. Zoals eerder gezegd, is goede testgevallen bedenken vaak lastig. Exploratief testen is dus helemaal niet gemakkelijk, maar daarom juist een leuke uitdaging. De grootste uitdagingen in ET zijn goede en bruikbare notities maken, voldoende testideeën verzinnen op het juiste moment, rapportage van de dekking en het managen van het gehele proces. Leren ET is niet gemakkelijk, maar het is te leren. Een cursus is een goed begin en helpt je prima op weg. Maar dan ben je er nog niet. Om het echt onder de knie te krijgen is veel oefening nodig. Door samen met anderen te testen (pair testing), leer je van elkaar en krijg je feedback op jouw werk. Naast allerlei testgerelateerde zaken is het ook nuttig om meer te leren over observeren, experimenten ontwerp, vooringenomenheid en sociale wetenschappen. De kracht van ET ET is een krachtige manier van werken. Door de dagelijkse planning en de constante bijsturing (ook tijdens het testen zelf) wordt voortdurend datgene getest dat het belangrijkste is. De tester is veel meer betrokken, juist doordat kritisch denken constant noodzakelijk is. Daarnaast maakt ET volop gebruik van onbewuste kennis [7]. Iedere test die uitgevoerd wordt, is input voor de volgende. Vaak is vooraf niet te voorspellen hoe de software zal reageren. De uitkomst van een experiment bepaalt de volgende stap van de tester. De creativiteit van de tester wordt hierdoor volop benut. Toekomst Exploratief testen wordt gelukkig steeds serieuzer genomen. Steeds meer mensen passen het succesvol toe en het neemt een steeds belangrijkere plaats in ons mooie vakgebied in. Het is wachten totdat er literatuur gaat verschijnen die het belang van ET onderstreept. De blogs van Cem Kaner, James Bach en Michael Bolton zijn fantastische bronnen van informatie. Ook de blogs van James Lyndsay, Jonathan Kohl en Elisabeth Hendrickson bevatten een schat van informatie. Elisabeth Hendrickson heeft recent een boek gepubliceerd over ET genaamd Explore-it! Dit is een absolute aanrader! •

Cem Kaner - http://Kaner.com

•

James Bach - http://satisfice.com/blog

•

Michael Bolton - http://developsense.com/blog

•

James Lyndsay - http://workroomprds.blogspot.com

•

Jonathan Kohl - http://kohl.ca/blog

•

Elisabeth Hendrickson - http://testobsessed.com

‘If you cannot trust your testers, you do not make them write more detailed test cases. But you train them!’ (Rikard Edgren – EuroStar 2012 & Gitte Ottosen – ATD 2012)

Pagina 22

Bronnen [1] http://nl.wikipedia.org/wiki/Testen [2] ‘Defect Detection Efficiency: Test Case Based vs. Exploratory Testing’ by Itkonen, Mäntylä and Lassenius (proceedings of the International Symposium on Empirical Software Engineering and Measurement, pp. 61-70, 2007) [3] http://thetesteye.com/blog/2013/03/open-letter-to-eurostar-organizers-testing-introduction/ [4] http://www.satisfice.com/tools/htsm.pdf [5] SFDIPOT - structure, function, data, interface, platform, operations and time. [6] http://nl.wikipedia.org/wiki/Heuristiek [7] Onbewuste kennis is bijvoorbeeld ervaring, attitude of een mentale model in je hoofd. Het is vaak moeilijk over te dragen, maar ontzettend belangrijk. Kan je uitleggen hoe je je evenwicht bewaart, terwijl je aan het fietsen bent? Lees het boek ‘Tacit and explicit knowledge’ van Harry Collins over dit onderwerp.

Pagina 23

DE CONTEXT VAN DE CONTEXT-DRIVEN Door Ard Kramer ● [email protected]

@ard_kramer

Als je de context van de context-driven school beschrijft, analyseert of probeert te verklaren, dan zou je in de geest handelen naar het eerste principe van de The Seven Basic Principles of the Context-Driven School: ‘The value of any practice depends on its context’. Het was dan ook deze nieuwsgierigheid die mij verleidde om naar de context van de context-driven te kijken. Hierbij kwam de vraag naar boven: ‘waarom is context-driven school in de VS ontstaan?’. Zulke zoektochten, zo heb ik zelf ervaren, zegt ook veel over degene die een dergelijke context onderzoekt en beschrijft, in dit geval ‘een Nederlandse tester’. Om die reden kwam ik tot een tweede vraag die ik in dit artikel probeer te beantwoorden: ‘Had de context-driven school in Nederland kunnen ontstaan?’. Laat ik echter eerst de contouren van het context-driven testen schetsen. Context-driven testers strive to become the Jedi knights of testing [1] De context-driven school ontstond in 1999 toen enkele Amerikaanse testers, waaronder James Bach en Cem Kaner elkaar troffen op een ‘peer conference’. Ze deelden al langer ervaringen en vormden om die reden een gemeenschap. Ze vormden een ‘school of thought’, omdat ze op een uitgesproken wijze over het testvak dachten. De denkwijze werkten zij uit, onder ander in hun zeven basisprincipes [2], publicaties, presentaties en in cursussen (Rapid software testing). De context-driven school is in de loop van de tijd een wereldwijde gemeenschap geworden en heeft ook in Nederland zijn (schok)effect gehad waar ook context-driven testers opstonden zoals Huib Schoots die hierover regelmatig publiceert [3]. Als je kijkt naar de context-driven school, dan vallen mij twee belangrijke kenmerken op: resultaatgerichtheid en meesterschap. Om te beginnen met de resultaatgerichtheid van de context-driven tester. Het vijfde principe van de context-driven school is hierover volstrekt duidelijk: ‘The product is a solution. If the problem isn’t solved, the product doesn’t work’. Een principe dat afdwing dat wij als testers ons maximaal moeten inzetten om problemen op te lossen of positiever gesteld tot een gewenste oplossing te komen. Er is geen excuus, hoe goed je intenties ook mogen zijn, je dient als tester te worden beoordeeld of je het probleem hebt opgelost. Om die redenering scherper te stellen: je mag als tester worden afgerekend op fouten die je hebt laten zitten die een bedreiging vormen voor een goed gebruik van de software. Het meesterschap komt naar voren in het gegeven dat een context-driven tester in staat moet zijn om zijn eigen heuristiek te ontwikkelen. Wikipedia geeft een mooi omschrijving van heuristiek: ‘de leer of de kunst van het vinden’. Om het naar het testvak te vertalen: op welke specifieke, zelf ontwikkelde wijze ga je op zoek in de software om fouten er uit te halen? Je moet als tester dus in staat zijn op geheel eigen wijze tot een aanpak te komen. Standaard aanpakken of best practices zijn hierbij ongewenst omdat ze onvoldoende rekening houden met de context en omdat ze je niet uitdagen tot kritisch denken.

Pagina 24

Het ontwikkeling van je eigen heuristiek vraagt verdieping van je vak en ook kennis van vele andere vakgebieden waarbij je je door andere wetenschappen laat inspireren. Het testvak is tenslotte geen wetenschap en om die reden laten context-driven testers zich inspireren door wetenschappen als antropologie, sociale psychologie en filosofie. Hieruit blijkt ook dat de mens een belangrijke factor is waar we rekening mee moeten houden, tenslotte is het ook de mens die in zijn verschillende rollen met de software omgaat: van opdrachtgever tot softwareontwikkelaar. Problemen die in de software zitten, worden dan ook veroorzaakt door diezelfde mensen. Als je als tester hen beter begrijpt, dan ben je ook beter in staat om een heuristiek te ontwikkelen die de kans dat je bedreigende problemen in de software vindt, vergroot. Het meesterschap is dus een absolute voorwaarde om het resultaat te behalen. Het summum van resultaatgerichtheid zijn winnaars om die reden doen de bovenstaande kenmerken, mij erg Amerikaans aan. In eerdere presentaties heb ik aan de hand van voorbeelden uit de sport, meermalen onderbouwd hoe resultaatgericht de Amerikaanse maatschappij is. Het land houdt van winnaars. Om die reden kun je bij typische Amerikaanse sporten (honkbal, ijshockey en American football) nooit gelijk spelen: er moet een winnaar zijn. Het resultaat staat boven alles. In een boek trof ik typering van deze mentaliteit aan. Het

zogenoemde

consequentialisme

[4]

(versus

het

non-

consequentialisme). De kern van deze typering gaat over in hoeverre een mens verantwoordelijk is voor zijn handelen. Het

consequentionalisme, dat

aantreffen,

gaat

ervan

uit

we dat

in de

Angelsaksische

landen

mens

geheel

in

zijn

verantwoordelijk is voor zijn handelen. Dit verklaart het vereren van winnaars: je bent verantwoordelijk voor het resultaat en er is geen excuus als je verliest. Het non-consequentionalisme, dat we kennen in de West-Europese maatschappijen (ook wel de Rijnlanden genoemd) gaat er echter van uit dat we de effecten van ons handelen niet voorzien en om die reden zijn de intenties van ons handelen bepalend. Je ziet dit bijvoorbeeld terug in onze rechtsstaat waar je niet alleen op je handelen wordt beoordeeld maar er ook wordt gekeken naar met welke intentie je bijvoorbeeld een misdaad beging (en als verzachtende omstandigheden kunnen gelden). En ‘onze’ mening over voetbal is daar ook een mooi voorbeeld van: we winnen graag maar wel met de goede intentie: mooi voetbal.

De gerichtheid van de context-driven school op resultaat en meesterschap in relatie tot een consequentionlistische maatschappij was voor mij een verklaring waarom de context-driven school in Amerika kon ontstaan. Aan de hand van deze conclusie dat context-driven past binnen het consequentionalisme ging ik ook anders tegen ‘de’ Nederlandse aanpak van testen aankijken: TMap. Een dik handboek dat duidelijk aangeeft hoe het ideale testproces zou moeten verlopen. Een blauwdruk dat in veel organisaties is overgenomen en als uitgangspunt dient voor ‘goed’ testen. De vraag is hierbij in hoeverre het dan zou passen op de non-consequentialistische filosofie die onze maatschappij wordt gevolgd. In TMap ligt een grote nadruk op proces: door het volgen van de stappen ben je met de goede intenties bezig om te testen. Er zijn echter vele andere factoren van invloed op het resultaat, te weten software die voldoet aan de eisen van de klant.

Pagina 25

De vele factoren waar de tester geen invloed op heeft om het resultaat te bereiken zijn verzachtende factoren zoals een slecht ontwerp of onduidelijke requirements. Productieproblemen als gevolg van niet goed testen, kunnen hiermee worden verklaard: ‘we hebben als tester met de goede intentie getest door het proces te volgen wat echter niet uitsluit dat door andere omstandigheden problemen over het hoofd werden gezien’. Dus waar een Amerikaanse tester snoeihard wordt afgerekend op zijn resultaat (en hiervoor aansprakelijk kan worden gesteld: ‘I am going to sue you’) versus een Nederlandse tester die het niet gevonden productiefout bedekt met te verwijzen naar zijn proces (‘Ik had toch alle stappen correct uitgevoerd?’). Discussie In dit artikel heb ik geprobeerd aan de hand van het onderscheid tussen de Amerikaanse en Nederlandse dan wel West-Europese maatschappij filosofie proberen te verklaren hoe het komt dat de context-driven school een gevolg is van de context van de Amerikaanse maatschappij. In navolging hierop heb ik ook een verklaring gegeven waarom TMap een product moest zijn van de Nederlandse maatschappij. Het is aan de lezer van dit artikel om hierover verder te discussiëren. Hiermee heb ik willen bereiken dat u zich bewuster bent geworden over de context waarbinnen u werkzaam bent en dit ten voordele van uw testwerk gebruikt, hoewel dat weer een calvinistische gedachte is. Bronnen en verwijzingen [1] http://www.satisfice.com/blog/archives/565 [2] De zeven principes van Context driven testing - www.context-driven-testing.com [3] ‘Ik ben een context-driven tester! Joh? Echt waar? Nou en?’ in Testkrant, nummer 2, december 2012 [4] ‘Stop de Amerikanen! Tenminste tien goede redenen om gewoon Europees te blijven’, door Hans Versnel & Jaap Jan Brouwer, Houten, 2011, p.18 (In het boek ‘Stop de Amerikanen!’ wordt verder toegelicht welke filosofische gedachten er achter het onderscheid liggen.)

Pagina 26

DE RELATIE TUSSEN ORGANISATIECULTUUR EN TESTEN Door Colin Lek ● [email protected] In verschillende studies is onderzocht dat er specifieke situationele factoren zijn die Business-IT alignment en alignment volwassenheid beïnvloeden in organisaties [1]. Deze factoren hebben ook impact op de manier van testen en hoe dit bijdraagt aan de alignment volwassenheid. Welke factoren bepalen de context (details van de specifieke situatie)? Voorbeeld van factoren zijn: IT outsourcing, strategische oriëntatie, organisatiecultuur en nationale cultuur. Het schrijven van dit artikel heeft als doel om bij te dragen aan het begrijpen van de alignment uitdaging door de relatie tussen organisatiecultuur en de invloed op testen te verkennen. Het is denk ik van belang om al tijdens het acquireren en starten van je opdracht te weten met wat voor organisatiecultuur je te maken hebt en welke aandachtsgebieden in het testen daardoor waarschijnlijk worden beïnvloed. Om te kijken naar de relatie tussen organisatiecultuur en de invloed op testen wordt het X-model [2] en TPI [3] gehanteerd. Organisatiecultuur Het cultuurconcept komt voort uit studies in sociologie, antropologie en sociale psychologie. Uit de literatuur komt naar voren dat de meerderheid gelooft dat er twee niveaus van cultuur te onderscheiden zijn. Het zichtbare niveau en het diepere, verborgen niveau. De zichtbare aspecten omvatten gedragspatronen, de fysieke en sociale omgeving en de geschreven en gesproken taal door de groep. Het diepere, minder zichtbaar niveau heeft betrekking op de waarden van de groep en de fundamentele veronderstellingen. Andere auteurs in de literatuur suggereerden dat cultuur verwijst naar het zichtbare niveau om ‘de manier waarop hier dingen worden gedaan" en op het verborgen niveau naar ‘de manier waarop we denken over dingen hier’. Het X-model suggereert dat de cultuur van een organisatie kan worden beschreven in termen van vijf cultuurelementen, namelijk Leiderschap, Strategie, Aanpasbaarheid, Coördinatie en Relaties. Elk van deze kernelementen bevatten sub-elementen die dienen om de kernelementen in detail uit te leggen. Dit model wordt gebruikt als basis voor de ontwikkeling van een organisatiecultuur diagnose-tool dat is gevalideerd. Het model en met definities van de kernelementen wordt gepresenteerd in Figuur 1.

Pagina 27

Figuur 1: De kernelementen van het X Model Adaptability Aanpasbaarheid wordt gedefinieerd als de mogelijkheid van een organisatie de behoeften van zijn klanten te begrijpen en hierop te reageren. Daarnaast om verandering te creëren op nieuwe verkregen kennis. Op een meer technisch niveau zou een high level van adaptability een hoge level IT-architectuur kunnen vereisen, aangezien flexibiliteit een van beloofde voordelen van architectuur is. Strategy Strategie wordt gedefinieerd als de mogelijkheid van een organisatie om op lange termijn een richting en waarde te creëren en hierbij een visie te concretiseren in tastbare doelen. Relationships Relatie wordt gedefinieerd als de mogelijkheid van een organisatie staf, teams en afdelingen samen te werken als een collectief met een gemeenschappelijk doel. Coordination Coördinatie wordt gedefinieerd als de mogelijkheid van de organisatie om één lijn te vormen tussen de organisatiestructuur, systemen en processen met de behoeften van de klant. Leadership Leiderschap wordt gedefinieerd als de mogelijkheid dat leiders met energie anderen weten te inspireren en in beweging te zetten, waarbij energie in actie en resultaten worden omgezet. Testen en organisatiecultuur In organisaties of projecten die adaptief zijn (Adaptability) denk je al snel aan Agile/Scrum omgevingen en wordt er anders omgegaan met testen dan in traditionele organisaties. Bij de strategie (Strategy) van een organisatie zou je verbeteringen in het testproces kunnen relateren aan de bedrijfsdoelstellingen om optimaal toegevoegde te bieden. In verschillende contexten kunnen verschillende concepten worden gebruikt bij deze verbetertrajecten, zoals de visies van Garvin op productkwaliteit, Deming-cyclus en het EFQM-raamwerk.

Pagina 28

In organisaties waar veel samengewerkt (Relationships) moet worden met andere afdelingen, projecten en stakeholders zijn bijvoorbeeld testcoördinerende rollen meer belangrijk voor onder meer het verkrijgen van acceptatiecriteria die randvoorwaardelijk zijn voor uitrol naar productie. Hier worden bijvoorbeeld het opstellen van testplannen en rapportages over de voortgang van de testen belangrijk. In organisaties kunnen de behoeften van een klant de ene keer wel goed achterhaald worden en de andere keer minder goed (Coordination). Soms sta je rechtstreeks met bijvoorbeeld gebruikers in contact en kun je hen heel effectief op verschillende manieren en momenten in het ontwikkelproces betrekken bij de acceptatie van het te testen systeem. In organisaties kunnen duidelijke leiders aanwezig zijn (Leadership) die zaken voor elkaar krijgen en eventueel tegen heilige huisjes aanschoppen om verbeteringen te kunnen doorvoeren en projecten succesvol te laten zijn. Is de veranderingsbereidheid aanwezig en zijn deze leiders met mandaat in staat de organisatie in beweging te krijgen? Bijvoorbeeld in een Agile omgeving wist een projectleider het ontwikkelproces te optimaliseren door over te schakelen naar Continuous Deployment, waarbij geautomatiseerde regressietesten zeer belangrijk zijn en bugs zo snel mogelijk moeten worden opgelost, alvorens er nieuwe functionaliteit wordt gebouwd. De

voorgaande

voorbeelden

suggereren

dat

er

een

relatie

bestaat

tussen

organisatiecultuur

en

de

testaandachtsgebieden: stakeholder commitment, de teststrategie en testorganisatie. Dit geldt ook voor de communicatie en hoe testprocesmanagement is geregeld. Er zijn voldoende redenen om te vermoeden dat er een relatie tussen de organisatiecultuur en de invloed op testen bestaat. De geselecteerde modellen kunnen helpen deze relaties te verkennen in een conceptueel model. Met vijf variabelen in het X-model voor organisatiecultuur en vijf variabelen in het TPI-model kunnen we 22 specifieke potentiële relaties identificeren zoals weergegeven in Tabel 1. Op basis van een onderzoek dat ik eerder heb uitgevoerd (mapping variabelen tussen SAM en TPI) [3] en het Xmodel is een indicatie te geven van een relatie tussen organisatiecultuur en testen dat kan worden verwacht (mapping tussen 3 modellen: TPI-SAM-X-model). TESTMANAGEMENT

Stakeholder

Test

Communi-

Test

process

commitment

Test strategy

organisation

cation

management

Adaptability

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

Strategy

aannemelijk

aannemelijk

aannemelijk

Relationships

aannemelijk

Coordination

aannemelijk

Leadership

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

aannemelijk

Organisatiecultuur

aannemelijk

Pagina 29

De tabel laat zien dat de Testmanagement aandachtsgebieden Stakeholder commitment, Testorganisatie en Test process management het meest waarschijnlijk een relatie hebben met de cultuurvariabelen. Tot slot, als tester zou je eens de organisatiecultuur kunnen analyseren van eerdere opdrachten en bekijken welke invulling je aan het testen hebt gegeven in deze testaandachtsgebieden. Wellicht ben je in toekomstige opdrachten dan beter in staat om situaties in de praktijk te herkennen en ben je in staat om er een oplossingsgerichte invulling aan het testen te geven. Bronnen [1] (2012) Silvius, A.J.G., Proefschrift Business en IT alignment in context, Utrecht University - http://igiturarchive.library.uu.nl/dissertations/2013-0419-200507/silvius.pdf [2] (2008) Smit et al., Organizational Culture in the South African Context: The X Model, The International Journal of Knowledge, Culture & Change Management, 7(10). [3] (2009) Marselis, R. et al. (2009), TPI Next, Business Driven Test Process Improvement. Den Bosch: UTN publishers [4] (2010) Lek, C., Thesis Business and IT alignment (BIA) vanuit een Test Management perspectief, HU - Master of Informatics http://www.linkedin.com/redir/redirect?url=http%3A%2F%2Fesmanron%2Ehome%2Exs4all%2Enl%2FColinLek%2 FThesisColinLek-final%2Epdf&urlhash=YIyw&trk=prof-publication-title-link

Pagina 30

MEER CONTEXT DRIVEN WORDEN; EEN PERSONAL STORY Door Jan Jaap Cannegieter ● [email protected]

@jjcannegieter

Toen ik een aantal jaren geleden voor het eerst werd geconfronteerd met context driven testing (CDT) was mijn eerste gedachte: ‘Ja, logisch toch, niets nieuws onder de zon!’ Ik vond het eigenlijk alleen maar vanzelfsprekend dat je de aanpak die je hanteert, aanpast aan je situatie. Zo ben ik een aantal jaren geleden kort na elkaar projectleider van een groot project bij een bank en projectleider van de realisatie van een kleine online marktplaats voor drukwerk op internet geweest. Bij de bank had ik zo’n veertig tot zestig medewerkers in mijn project, bij de drukwerkmakelaar misschien vier tot zes. Bij beide organisaties paste ik Prince2® toe, maar de wijze waarop was compleet verschillend. Ik weet dat de CDT-principes meer behelzen, maar het voorbeeld geeft wel aan dat ik mijn aanpak varieerde afhankelijk van de context. Terugkijkend ben ik alleen de eerste paar jaren na mijn studie van mening geweest dat ik me strak aan een methode moest houden. Logisch toch? Al met al vond ik de CDT-principes (zie http://context-driven-testing.com/) dus behoorlijk vanzelfsprekend. Daar ben ik toch wat van teruggekomen. Laat ik dat met een ander voorbeeld toelichten. Bug-hunts als testaanpak Mijn eerste opdracht als tester was bij een organisatie die heel strak het zogenoemde scripted testing hanteerde. Bij scripted testen worden voorafgaand aan de testuitvoering, op basis van documentatie, testscripts gemaakt die de basis vormen voor de testuitvoering. De meesten van jullie zullen dit wel herkennen. Jaren later was ik als requirementsanalist/QA-medewerker/tester ingezet op een project waarvan de ontwikkeling was uitbesteed aan een softwarehuis. Wekelijks werd software opgeleverd die binnen een paar dagen getest moest zijn. Bij die opdracht had ik helemaal geen tijd om testscripts te maken en zelf tests uit te voeren. Samen met de projectmanager heb ik een aanpak bedacht die nu bekend staat als bug-hunts. Iedere vrijdagochtend kwamen een aantal projectmedewerkers (gebruikers, lijnmanagers, projectmanagers) bij elkaar. Iedereen kreeg een A4-tje met een testdoelstelling, een aantal logische testgevallen en de set requirements die voor hem of haar relevant waren. Vervolgens ging iedereen, soms in tweetallen, een uur of twee testen waarna we de uitkomsten (bevindingen, kwaliteit van het geteste deel) met elkaar bespraken. Let wel, ik promoveer mezelf hierbij niet tot uitvinder van bug-hunts, dat zou te veel eer zijn. Waar het mij in dit voorbeeld om gaat, is dat we gegeven de situatie een hele andere aanpak bedachten. En dat is voor mij context driven: afhankelijk van het systeem, de organisatie of het project (de context dus) de aanpak aanpassen (project bij grote bank versus project bij kleine pionier) of een nieuwe aanpak bedenken (bug-hunts bedenken). Situationeel testen Is daarmee CDT het hoogste goed? Nee, voor mij niet. Ik ben het helemaal eens met de principes, maar voor mij is het niet concreet genoeg. Nu is het niet de doelstelling van de context-driven community om CDT heel concreet te maken. CDT is een gedachte, uitgangspunt, houding; het is juíst geen aanpak. Maar daarmee blijf je als testprofessional wel in verwarring achter. Wat moet je nu concreet doen om meer context driven te worden? Ik kan die vraag alleen vanuit mijn eigen ervaring beantwoorden. Voor mij is het essentieel om je testkennis te verbreden om meer context driven te worden.

Pagina 31

Zelf ben ik veel meer context driven geworden toen ik in aanraking kwam met non-scripted testing. Bij nonscripted testing wordt de testuitvoering veel meer gebaseerd op de kennis en vaardigheden van de tester, die de prioriteiten in het testen flexibel aanpast aan de uitkomsten van eerdere

tests. Voorbeelden van non-scripted

testing zijn exploratory testing, testtours en bug-hunts. Toen ik kennis nam van en ervaring opdeed met nonscripted testing werd mijn ‘gereedschapskist’ veel beter gevuld en kreeg ik veel meer manieren van testen tot mijn beschikking. Deze kon ik afhankelijk van de situatie inzetten. Dit inzicht heeft een aantal testers van SYSQA ertoe bewogen ‘situationeel testen’ te ontwikkelen. Situationeel testen is een flexibele aanpak waarbij de tester afhankelijk van het systeem, de organisatie en het project de optimale mix van scripted en non-scripted testen kiest.

Factory based testing

Globale scripts

Session based testing

Bug hunts

Test tours

Freestyle exploratory

Non-scripted testing Scripted testing

Situationeel testen is dus een concrete, toepasbare invulling van CDT en bevat een aantal testvormen waarvan ik persoonlijk vindt dat iedere tester ze moet kennen en moet kunnen toepassen. Ik zal ook nooit roepen dat situationeel testen dé oplossing is voor al je testproblemen, al ben ik wel van mening dat iedere tester situationeel testen moet kennen. Context Driven Testen Het is volgens mij niet zo dat je of wel een context driven tester bent of niet een context driven tester bent. Voor mij is CDT geen on/off-concept. Ik ben overtuigd dat iedereen context driven is, ook als je nog nooit van CDT hebt gehoord. Maar het is wel zo dat de ene persoon meer context driven is dan de ander. Zo ben ik van mening dat iemand die binnen een methode keuzes maakt op basis van de context al in enige mate context driven bezig is. Iemand die methodes gaat combineren vind ik echter meer context driven. Er zijn zelfs mensen die geheel buiten bekende (test)methoden om op zoek gaan naar de ideale oplossing voor hun project! Ik zie in de praktijk dat testers functioneren op een aantal niveaus van context driven testing, niveaus die ikzelf ook heb doorlopen. Als jij van jezelf weet op welk niveau van CDT je zit, kun je daaruit afleiden wat je moet doen om meer context driven te worden. Als je wilt weten welke niveaus van CDT ik onderken en wat je moet doen om hoger op die ladder te komen, dan verwijs ik je graag naar mijn presentatie op het TestNet najaarsevenement 2013, te downloaden van de TestNet site. SYSQA heeft een boekje over situationeel testen gepubliceerd. Met de combinatie van de niveaus van context driven en dit boekje is de stap naar meer context driven testen makkelijk te zetten!

Pagina 32

PRESTATIE-INKOOP BIJ DE OVERHEID: EISEN OP HOOFDLIJNEN, (TEST)EXPERTISE OP NIVEAU Door Rik Teuben ● [email protected]

@Rteuben en André Roosendahl

De provincie Noord-Holland heeft – net als steeds meer bedrijven

–

gekozen

voor

Prestatie

Inkoop

bij

haar

aanbestedingsronde. Dat betekent dat er veel expertinbreng wordt gevraagd en de opdrachtgever zich bewust beperkt tot het kenbaar maken van de opdracht op hoofdlijnen. Ook de testopdracht. Wat kwam er van terecht? Opdrachtgever en opdrachtnemer kijken terug in dit praktijkverhaal! Een tweede kans krijg je maar één keer! De

provincie

Noord-Holland

heeft

bij

de

tweede

aanbesteding

van

haar

Informatie

Systeem

(beheer

kapitaalgoederen) gebruikgemaakt van een inkoopfilosofie, die meer verantwoordelijkheid bij de toeleveranciers van producten en diensten neerlegt dan gebruikelijk is. Ook de provincie Noord-Holland was eerder gewend om aanbestedingstrajecten zodanig dicht te timmeren dat de opdracht gegund werd aan de leverancier die het best in staat was een mooi verhaal te bieden. Dat was dan vaak een verhaal dat punt voor punt de eisen en wensen uit de aanbestedingsaanvraag afwerkte door een suboptimale oplossing te bieden tegen een zo laag mogelijke prijs. Die aanpak had echter in 2009 tot een project geleid dat beheerst werd door meerwerk, budgetoverschrijdingen en juridisch gekonkel. Een fiasco dus, juist omdat eisen en wensen in aanvang vergaand werden uitgewerkt en de opdrachtnemer en opdrachtgever precies dachten te weten waar ze aan begonnen, en beiden van meet af aan de controle stevig in handen wilden houden. Een uitgebreide evaluatie maakte duidelijk dat niet zozeer de controle tekortschoot, maar dat de mate van controle overschat werd. Het roer moest dus duidelijk om en daarom werd gekozen voor een aanbestedings- en inkoopaanpak volgens de methode van Best Value Procurement, oftewel Prestatie-inkoop. Context: Prestatie-inkoop Prestatie-inkoop is een methode die de relatie tussen klant en leverancier op een andere manier benadert. De aanpak is geïntroduceerd door Dean Kashiwagi (Arizona State University) en in Nederland op de kaart gezet door Sicco Santema en Jeroen van de Rijt. BVP gaat ervan uit dat je aanbieders die boven het maaiveld uitsteken de ruimte moet geven om zich ook als zodanig te profileren. Zo krijgt deze de kans om oplossingen aan te bieden waar de opdrachtgever zelf mogelijk niet aan gedacht had. In dit klimaat moest de testopdracht uitgevoerd worden. Geen

afvinklijstjes,

Stappenplan geen

uitgewerkte

specificaties,

een

kritische

1. Test Intake

opdrachtgever, een scherp budget en een project dat zich een volgende

2. Begrip & training

uitglijder niet kon permitteren. Een flinke uitdaging, maar voor een

3. Voorbereiding & timeboxing

testexpert het mooiste wat er is, want de opdrachtgever gaf ook aan

4. Procesbegeleiding (uitvoering)

ons – geheel in de lijn van Best Value Procurement – de ruimte om een

5. Happy testing: ‘Om-testen’

testoplossing te presenteren die bij de organisatie past, de risico’s

6. Administratie & rapportage

beperkt maar de kansen uitbuit, en rekening houdt met het begrensd

7. Debriefing & decharge

budget. Kortom, een omgeving waar met recht gesproken mag worden van Context Driven Testing.

Pagina 33

Context leidend voor testaanpak Bij analyse van de aanvraag hebben de testbegeleiders (supervisors) zich niet laten leiden door het aantal functiepunten en de specificaties. Daar werd immers het succes maar deels aan afgemeten. Het doel was breder en vroeg een aanpak die paste bij de doelstellingen van het project: •

operationeel (inclusief gemigreerde data) bij voorkeur 1 juli 2013, eerder is beter;

•

realisatie, actualisatie, beheer en onderhoud van het systeem voor drie jaar (met een optie van drie maal één jaar verlenging), volgend op de ontwikkelingen in de markt conform de richtlijnen;

•

het provinciale areaal integraal te kunnen programmeren (plannen), beheren, budgetteren en rapporteren (plaats- en tijdonafhankelijk);

•

waarbij de kosten en inzet voor de provincie minimaal zijn;

•

zo eenvoudig mogelijk, schaalbaar en aansluitend op de in de Provincie Noord-Holland aanwezige informatie en applicatie-architectuur;

•

ruimtelijke informatie uit systeem is via kaarten benaderbaar;

•

digitale data-uitwisseling met ketenpartners (op geldende standaarden).

Geheel in lijn van de context driven aanpak oriënteerden we ons op de projectomgeving, voordat we de testaanpak definieerden. Intake en belangenweging De ‘intake’ gebruikten we niet om onze eigen kwaliteiten als testexperts over het voetlicht te brengen, maar om meer informatie te krijgen over het project en om het vertrouwen te krijgen van de opdrachtgever. Omdat ook de gebruikersorganisatie en ICT bestonden uit vakmensen die ieder hun eigen accenten legden binnen het testvraagstuk, was het vanaf aanvang duidelijk dat een eenduidige kwaliteitsopvatting een illusie was, en dat we optimaal gebruik moesten maken van de kennis die in de hoofden van deze experts zaten. Daarom besloten we de kwaliteitsopvattingen (de specs) niet in lijn te brengen of te kanaliseren via een product owner of in gestolde vorm via een functioneel ontwerp; we wilden juist de veelkleurigheid weerspiegelen in het testproces. In plaats van op zoek te gaan naar een functionele verdeling richtten we ons op de wijze waarop iedere gebruikersgroep de globale eisen en wensen weerspiegeld wilde zien en wat het belang ervan voor iedere groep afzonderlijk was. Geheel volgens onze verwachtingen werd het een bont pallet van belangen en inzichten. Wat de objectbeheerders van Landschap en Milieu als essentieel betitelden, was voor het areaal Verkeersvoorzieningen minder – of helemaal níet – van belang. Dat was een situatie die we weerspiegeld wilden zien in onze aanpak en dus brachten we de verschillende opvattingen juist in kaart in plaats van te proberen ze glad te strijken. Daarbij waakten we er wel voor dat er geen eenzijdige besluiten werden genomen. We spraken af dat een persoonlijke opvatting géén opvatting was. Besluiten over wat belangrijk was (en wat niet!) moesten gesteund worden door meerdere personen binnen de gebruikersgroep (=areaal). Met deze kennis gewapend traden we in contact met de leverancier van het product. Deze wist immers aan welke eisen zij nog niet tegemoet konden komen. Zo was het duidelijk dat bij aanvang van de test nog niet aan de planningsbehoeften kon worden voldaan, terwijl dat voor meerdere gebruiksgroepen van groot belang was.

Pagina 34

Begrip en training Bij de testvoorbereiding en -uitvoering maakten we geen gebruik van getrainde testers. De reden daarvoor was enerzijds budgettair van aard en anderzijds hadden eerdere ervaringen ertoe geleid dat er weerstand was ontstaan tegen een testaanpak die voor belanghebbenden lastig te doorgronden was, weinig herkenningspunten bood en het acceptatieproces frustreerde. Ook bood de documentatie onvoldoende aanknopingspunten om voorafgaand aan de testuitvoering testscripts op te stellen. Daarom kozen we al snel voor exploratory testing. Omdat onervaren ‘explorers’ ook wel eens verdwalen, gaven we hen een aantal technieken mee. Geen technieken die hielpen om een zo groot mogelijke dekkingsgraad af te dwingen, maar strategieën die op een onderhoudende manier de ‘gaten’ in het systeem blootlegden. Daarmee oefenden we aan de hand van de eerder geïnventariseerde testitems.

Voorbeeld van een teststrategie

Pagina 35

Strakke hand, duidelijke afspraken De grootste uitdaging was om de grote hoeveelheid

‘Om-testen’

testers (stakeholders) gelijktijdig tot het uitvoeren van

De positieve en resultaatgerichte stemming in de

testen

‘war room’ sloeg om, toen al vrij snel na aanvang

te

bewegen.

Natuurlijk

was

de

grootste

bedreiging ook bij ons ‘de hectiek en dynamiek’ van

bleek dat

alledag. Ook daar zijn we niet in verzet gegaan, maar

tekortschoot in de ogen van de gebruikers. Dat

hebben we geïnvesteerd in vertrouwen. We probeerden

leidde tot frustratie bij zowel de gebruikers als de

de feiten te nemen zoals ze werden opgediend en

leverancier. In overleg hebben we toen besloten een

mogelijke bezwaren tegen deelname weg te nemen.

middag te reserveren voor ‘Om-testen’. Niet op zoek

Afdelingsmanagers werden geïnformeerd, de leverancier

gaan naar fouten, maar naar de goede dingen van

van de programmatuur was de gehele dag aanwezig, en

het systeem. De gedachte hierachter was, dat niet

binnen

het aantal fouten bepalend is voor de testmotivatie,

de

strakke

dagindeling

en

‘timeslots’

was

voldoende tijd om in contact te treden met de (zakelijke

op

onderdelen het

informatiesysteem

maar het evenwicht tussen ‘tops’ en ‘flops’.

of private) achterban als dat nodig bleek. Verder verwenden we alle testers met afwisselend taart en fruit. Zodra er ook maar iets tegenzat (‘impedements’ in agile termen) probeerden we de hindernis en ergernis weg te nemen. Op sommige momenten betekende dat, dat we een duidelijk gesprek met de leverancier aan moesten gaan, in andere gevallen dat het onze taak was om de testers te beschermen tegen hun eigen collega’s, die zonder mededogen de testkamer in liepen om vragen te stellen. Met de nodige overredingskracht en humor was het uiteindelijk zo, dat niemand zonder kloppen de ‘war room’ betrad en dat de leverancier zich de vingerkootjes uit zijn hand typte om belemmerende bugs op te lossen. Heel verstandig … De resultaten De context driven aanpak die gekozen werd tijdens het testtraject bij de provincie Noord-Holland had ten opzichte van eerdere testbegeleiding grote voordelen. De gebruikers voelden zich gehoord en herkenden in de testaanpak een werkwijze die hun belangen veiligstelden en hun belangrijkste vragen beantwoordden. De opgebouwde kennis tijdens het testtraject bleef beschikbaar binnen de Provincie en de applicatie werd met een groot draagvlak en inzicht op tijd en binnen budget geïmplementeerd.

Grondslagen

De context driven aanpak blijkt op hoofdlijnen makkelijk te

1.

Paired testing in plaats van individueel

transponeren naar andere projecten, hoewel de detailinvulling

2.

Timeslots in plaats van planningen

natuurlijk altijd maatwerk blijft.

3.

Exploratory testing in plaats van

Het doel om een testteam met veel verantwoordelijkheid, op een

scripted testing

natuurlijke en plezierige manier door het testproces te loodsen onder begeleiding (maar niet onder leiding!) van een testexpert, is behaald. Door ook binnen het testtraject de regie en sturing te minimaliseren tot een begeleidingstaak en testverantwoordelijkheid te beleggen bij domein- en ICT-experts werden uitzonderlijk goede resultaten bereikt.

Pagina 36

PRODUCTRISICO’S VRAGEN OM DE JUISTE FOCUS Door Jos van Rooyen ● [email protected] Zo’n tien jaar geleden is risk based testen in de markt gezet. In die tijd was dit een geweldig stap in de ontwikkeling van het testvak. Een van de onderdelen van risk based testen is de productrisico-analyse. Het gebruik ervan is tegenwoordig gemeengoed. Echter, waar loop je tegenaan bij de toepassing van pra's? Hoe kun je het

oplossen?

Ik

publiceerde

daarover

onlangs

in

Computable.

In

deze

TestNetNieuws een samenvatting. Vergeten stakeholders Een stap waar vaak lichtzinnig over wordt gedacht betreft de selectie van de stakeholders. Geregeld worden groepen vergeten, bijvoorbeeld de beheerafdeling of de auditdienst. Zonder deze stakeholders zal de productrisicoanalyse niet compleet zijn, met als gevolg dat de teststrategie niet dekkend is. Een simpele oplossing is om aan de hand van het bedrijfsproces in kaart te brengen wie welke stappen in het bedrijfsproces uitvoert. Te generiek Regelmatig worden productrisico’s te generiek opgesteld. Voorbeeld: functioneel beheer is niet mogelijk. Daar kunnen we geen adequate testgevallen voor ontwikkelen. Ze zijn te hoog over, we slaan de plank mis of we missen simpelweg delen. Je zult stakeholders continu een spiegel moeten voorhouden: wat bedoel je hiermee, hoe kun je dit aantonen? Situaties voorstellen, deelnemers prikkelen, kijken of je testgevallen voor het productrisico kunt ontwikkelen. Scope te beperkt De scope van de productrisico-analyse ligt regelmatig alleen op de wijzigingen die doorgevoerd worden, vooral bij releasematig werken. Uiteraard ligt de nadruk op de risico’s die worden geïntroduceerd door de betreffende wijziging. Dat is stap één. Echter, als een bestaand bedrijfsproces wordt aangepast, moet je ook vaststellen welke bestaande risico’s als regressie meegenomen dienen te worden. Prioritering Een van de resultaten van de workshop is de prioritering. De stakeholders vinden hun eigen productrisico het allerbelangrijkste. Vaak is de impact van die toekenning niet duidelijk. De testinspanning zal groter worden en wellicht zijn er meer resources nodig. Voor een goede prioriteitstelling kan de moderator vragen stellen. Wie heeft er last van? Al onze klanten of een beperkte groep? Werkvorm Een goede werkvorm is het halve werk, ook bij een productrisico workshop. Naast de genoemde selectie van stakeholders is het bepalen van de juiste aanpak van groot belang. De moderator zal zich in de voorbereiding moeten verdiepen in de materie en vragen verzamelen die kunnen leiden tot mogelijke productrisico’s. Deze vragen kan de moderator gebruiken op het moment dat de creativiteit stokt, om de deelnemers weer te inspireren tot het genereren van nieuwe productrisico’s.

Pagina 37

Het vervolg Wat je veel ziet, is dat de productrisico’s worden opgesteld, teruggekoppeld en opgenomen in een testplan. Veelal blijft het daarbij. Dat doet onrecht aan de kracht van productrisico’s. De productrisico’s vormen een perfecte basis voor rapportage. Richt je testproces zo in dat aan de hand van de productrisico’s gerapporteerd wordt naar alle stakeholders. Dan kan het de basis vormen voor het vrijgaveadvies en de sturing van de implementatie. Het hele artikel vind je op http://www.computable.nl/artikel/opinie/development/4697087/1277180/productrisicos-vragen-om-de-juistefocus.html

Pagina 38

CONTEXT-DRIVEN TESTING: HOE WERKT DAT? Door Jurgen van Amerongen ● [email protected] Vraag aan een aantal testers of zij bekend zijn met Context-Driven Testing (CDT) en het merendeel zal aangeven dat zij dit al in meer of mindere mate toepassen. Vraag nogmaals wat het precies inhoudt en zij zullen een antwoord geven waaruit je kunt afleiden dat dit is gebaseerd op hun interpretatie en niet vanuit de theorie. Velen van ons hebben in de dagelijkse praktijk te maken met omstandigheden waarbij de gekozen traditionele testaanpak zoals TMap, TestFrame en RRBT niet meer volledig voldoet. Een goede testbasis ontbreekt, gebrek aan testcapaciteit, planningen die schuiven, slechte acceptatiecriteria, een scope die wijzigt, et cetera. En dan moeten wij ons aanpassen en gaan we concessies aan de kwaliteit doen of improviseren om het beste ervan te maken, want tenslotte blijft de opleverdatum staan en is uitstel onbespreekbaar. De testaanpak wordt bijgesteld, waarmee vaak flink wordt afgeweken van de oorspronkelijke opzet. Een typisch voorbeeld van wat ‘vanuit de context is gedreven’, maar zijn we dan ook context-driven aan het testen? Oorsprong Volgens Van Dale betekent context: ‘samenhang’ en Wikipedia beschrijft het als: ‘het grotere, betekenisgevende kader waarbinnen iets plaatsvindt.’ Daar word je nog niet veel wijzer van. De theorie over Context-Driven Testing omschrijft dit anders. Hier wordt uitgegaan van een aantal principes, waarbij het nog steeds niet duidelijk is wat CDT dan wel precies is. In dit artikel geef ik een eigen invulling aan CDT vanuit mijn praktijkervaring zonder de principes geweld aan te doen. Een invulling die wellicht verder gaat dan hoe CDT oorspronkelijk is bedoeld. Tenslotte gaat het om het eindresultaat dat ermee wordt bereikt. De wijze waarop dat succes kan worden bereikt, wil ik graag met jullie delen. Wie de literatuur erop naslaat (lees: googled; veel is er niet over geschreven), komt al snel uit bij de CDT-pioniers: James Bach en Cem Kaner. Zij vonden elkaar rond dit onderwerp en kwamen al snel met ‘De zeven basis principes van de Context-Driven School’, een ‘school’ die deze theorie uitdraagt. In het boek: ‘Lessons Learned in Software Testing’, samen geschreven met Bret Pettichord, wordt hier nog specifiek aandacht aan besteed. Wat is dan die theorie? Het is geen testmethode, standaard aanpak, testtechniek of wat dan ook. Dat kan ook niet want context-driven is per definitie uniek en zal dus ook situationeel, dus uniek, ingevuld moeten worden. Wel komen enkele testtechnieken terug zoals exploratory testing, maar dan ben je al met de ‘hoe’ vraag bezig en niet met de ‘wat’ vraag. The Seven Basic Principles of the Context-Driven School 1. The value of any practice depends on its context. 2. There are good practices in context, but there are no best practices. 3. People, working together, are the most important part of any project’s context. 4. Projects unfold over time in ways that are often not predictable. 5. The product is a solution. If the problem isn’t solved, the product doesn’t work. 6. Good software testing is a challenging intellectual process. 7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Pagina 39

Wie de principes op zich in laat werken, komt tot een aantal bijzondere elementen van CDT. Zonder dieper op de principes in te gaan, wil ik wel een paar elementen benoemen en deze nader toelichten waarin een aantal principes terugkomen. Tenslotte is mijn invulling van CDT hierop gebaseerd. Elementen Een van de elementen is de rol van de mens, die als de kern van een ‘context’ wordt gezien, of beter gezegd de samenwerking tussen mensen (synergie). Mensen vervullen verschillende complementaire rollen en de invulling hiervan valt of staat met zijn gereedschapskist of bagage, die bestaat uit kennis, vaardigheden en ervaring. Hoe meer bagage men heeft, hoe beter men kan inspelen op de specifieke situatie. Door mensen (rollen) samen te laten werken ontstaat er synergie. Voor mij een belangrijke reden om met multidisciplinaire teams te werken waarin alle relevante rollen of disciplines zijn vertegenwoordigd. Bij voorkeur ketenbreed. Elkaar kennen en zogenoemde korte lijntjes verhogen bovendien de efficiëntie. Een ander element is het product dat moet worden gerealiseerd. Is het product nog opportuun? Om dit goed te kunnen beoordelen moet je niet terug naar het ontwerp, maar naar de oorspronkelijke doelstelling, vastgelegd in de business case. Hierbij gaat het dus om de essentie. Volgens een van de principes moet het product een oplossing bieden voor het probleem. Als het probleem niet is opgelost, dan werkt het product dus niet. Dit is het verschil tussen ‘is het een goed product’ (oplossing) en ‘is het product goed’ (kwalitatief). Het zogenaamde ‘probleem’ kon wel eens achterhaald zijn of tussentijds veranderd waardoor het pure geldverspilling is geworden en men beter kan stoppen. De essentie is hiermee komen te vervallen. Anekdote Zo heb ik zelf meegemaakt dat ik mijn team met de feestdagen tot groot ongenoegen moest binnenhouden, omdat een nieuwe versie van een softwarerelease beschikbaar kwam die in vele talen moest worden getest. Op mijn vraag voor welke talen er al belangstelling was, zodat ik kon prioriteren, moest de projectmanager na enig uitzoekwerk met schaamrood bekennen dat er alleen voor de Engelse versie potentiële belangstelling bestond. Hiermee kwam de urgentie en relevantie in een ander daglicht te staan. De hoeveelheid werk werd enorm teruggebracht en mijn teamleden konden de feestdagen heerlijk thuis doorbrengen. Dit was tevens aanleiding om het proces (gewoonte) ook eens kritisch onder de loep te nemen wat uiteindelijk nog meer werk, dus veel tijd en geld, bespaarde.

De duivelsdriehoek van projectmanagement is ook een belangrijk element dat niet expliciet naar voren komt uit de principes, maar ook niet genegeerd kan worden. Hierbij gaat het om het krachtenveld tussen de invloedsfactoren: tijd, capaciteit en scope met als constante factor kwaliteit. Vanuit een gekozen projectaanpak, dus ook testaanpak, wordt initieel een balans gevonden tussen bovengenoemde invloedsfactoren om binnen de gestelde tijd met bepaalde middelen een afgebakende hoeveelheid werk te realiseren. Hiervoor wordt een projectplan opgesteld en dat vervolgens uitgewerkt in een planning: een reeks van activiteiten gekoppeld aan resources, uitgezet in de tijd. Een belangrijk middel waarmee de voortgang kan worden bewaakt en waar nodig bijgestuurd.

Pagina 40

Als de tijd niet toereikend blijkt, kan men de scope verkleinen of de capaciteit vergroten met behoud van kwaliteit. Ook hier zijn grenzen aan verbonden waardoor men op een gegeven ogenblik op zoek moet naar alternatieven of met minder kwaliteit genoegen moet nemen. In de praktijk betekent dat vaak dat er concessies worden gedaan aan de kwaliteit terwijl men daar eigenlijk niet aan wil tornen. Vasthouden aan het oorspronkelijke testplan is dus duidelijk geen optie. Het element product behoeft ook nadere toelichting. In de praktijk heeft product veelal alleen betrekking op de ICT-component en niet het geheel dat benodigd is om deze middelen probleemloos in productie te kunnen nemen. In mijn CDT benadering staat het proces centraal waarmee de klant iets wil bereiken. De ICT-middelen zijn hieraan ondersteunend. De vernieuwing of verandering heeft veelal gevolgen voor de organisatie en deze zal zich hierop goed moeten voorbereiden. Uitsluitend een goed product is dus niet voldoende. Dit verbrede aandachtsgebied is niet specifiek voor CDT maar wel essentieel om succesvol in productie te kunnen. Als laatste element wil ik de klant benoemen. De klant bepaalt uiteindelijk wat hij belangrijk vindt en wat voor hem goed genoeg is. Maar doen we dat al niet bij bijvoorbeeld de productrisicoanalyses (PRA) waar de stakeholders ook bij betrokken zijn? Dat klopt, in die zin dat vanuit het product wordt gekeken naar de risico’s voor de verschillende gebruikersgroepen (stakeholders) op basis waarvan een teststrategie wordt opgesteld. In het kader van CDT zou ik liever willen spreken van een procesrisicoanalyse, waarbij dus niet het product maar het te ondersteunen bedrijfsproces het vertrekpunt vormt. Door middel van bijvoorbeeld simulatiesessies wordt al snel duidelijk waar de knelpunten en de risicovolle onderdelen zitten. Dus niet alleen ICT-gerelateerd maar ook procesmatig en organisatorisch. Zonder alle elementen te benoemen biedt bovenstaande al voldoende aanknopingspunten hoe gegeven een bepaalde context toch een acceptabele oplossing kan worden bereikt door middel van het toepassen van CDT. Toepassing Om te beginnen zal de toegepaste testmethode en daaruit volgend de aanpak moeten worden losgelaten. Dit voldoet blijkbaar niet meer en geforceerd hieraan vasthouden leidt alleen maar tot nog meer vertraging. Bovendien is de methode/aanpak een middel en geen doel op zich zelf. Daarnaast kies ik voor een ketenbrede en integrale invalshoek. Hierbij wordt niet meer stroomopwaarts gekeken naar wat er nog moet gebeuren om een product te realiseren, maar wordt er vanuit het einddoel teruggeredeneerd welke onderdelen essentieel zijn, de relatieve relevantie en urgentie, voor het bedrijfsproces waartoe het dient. Hierbij staat de vraag centraal: ‘Kan ik verantwoord in productie met een aanvaardbaar risico’? De volgende figuur illustreert deze invalshoek.

Pagina 41

Invalshoek Traditioneel versus CDT

Wat betekent bovenstaande voor CDT en hoe ziet dat er dan uit? Een eenduidig antwoord hierop heb ik niet. Een bruikbaar handvat is de Context CDT mind map die je niet alleen ondersteunt bij het vaststellen van de huidige situatie, maar nog belangrijker; bij het bepalen van wat er moet gebeuren op basis van essentie, relevantie en urgentie. Focus is cruciaal, maar dan moet je wel weten waarop.

Mindmap Context CDT

Aan de hand van de mindmap wordt de context helder. Met de klant wordt de essentie bepaald van het ‘product’ ten aanzien van de oorspronkelijke doelstelling. De relevantie heeft betrekking op de onderdelen waarvan ook de urgentie moet worden vastgesteld. Een handig hulpmiddel hiervoor is een context schets, een modelleertechniek om de onderdelen en de onderlinge samenhang te visualiseren. Op deze wijze ontstaat een nieuwe ‘roadmap’ over wat en wanneer te bereiken. Hierdoor krijgt men focus.

Pagina 42

De ‘wat’ en ‘wanneer’ vragen zijn hiermee beantwoord waarna vervolgens de ‘hoe’ en ‘wie’ vragen kunnen worden ingevuld. Afhankelijk van het onderdeel zijn hier verschillende technieken voor te bedenken zoals exploratory testen, simulatiesessies, procesverificaties, et cetera. Hier komt de gereedschapskist weer om de hoek kijken en nog meer het gezonde boerenverstand. Wat wil ik, wat heb ik en wat doe ik ermee? En dat zonder tijdrovende voorbereidingen en uitgewerkte testscenario’s maar heel pragmatisch. Tot slot In vogelvlucht heb ik jullie meegenomen in mijn wereld van CDT. Het is een mindshift; een andere manier van denken en een andere manier van doen. Is dit de ultieme oplossing en vervanger van de huidige testmethoden? Ik ben van mening van niet. Zodra een project start is het goed om de kwaliteit te borgen door hiervoor de benodigde activiteiten in het plan op te nemen. CDT is mijns inziens een perfecte aanvulling hierop. Sterker nog, als het project onder druk komt te staan en de gekozen aanpak niet meer voldoet dan is CDT het enige alternatief.

Pagina 43

COMPLEMENTING TRADITIONAL SOFTWARE-TESTING THROUGH CROWDTESTING Door Markus Steinhauser ● [email protected] The IT industry, and therefore the software quality management and testing, has been subjected to tremendous change. Examples of this are new technologies (e.g. mobility), new requirements as in policies and processes (e.g. agility), changes to regulations and standards (e.g. SEPA) and numerous other challenges such as the user's perspective on IT systems. These have all made software testing even more complex and demanding than it has ever been before. In addition, the diversity of devices, operating systems, screen resolutions and configurations is steadily increasing. Software must be tested properly on all kinds of devices. As a result, this change requires new ways of testing: A relatively new method called crowdtesting, which addresses many of the challenges development teams still face today. Crowdtesting - Software testing through internet users Crowdtesting combines testing with the principle of crowdsourcing, which is used in many other areas as well. Crowdtesting is a form of outsourced testing, which is undertaken by a mass of internet users (the crowd). The crowd is working on a defined problem and supports the company with its proposed solutions. Crowdtesting uses this concept to test websites, mobile apps, games, or enterprise software in order to get rid of bugs and to optimize the user experience. This way, software can be tested under real conditions on a variety of devices by a desired target group - even before the release. The advantages, challenges and necessary steps that need to be taken for crowdtesting to work will be outlined in this article. The Basics of Crowdtesting The basic concept of crowdsourcing proposes the idea of distributing a specific problem to a certain group of people without much prior knowledge, in order to solve the task. The people involved are motivated to contribute their feedback and commitment, either through monetary or non-monetary rewards. In Europe, there are a few crowdtesting providers who have built platforms to handle crowd-based test projects for software. The range of possibilities varies from a full service functional and usability test to self-service concepts, where the provider only gives access to its platform and crowd. Either way, maintaining high quality results is crucial. Since the testers are working remotely, the setup and documentation need to be done thoroughly for the development team to make use of the results. This can be monitored either by the crowdtesting provider or the client itself. In the following passages, the focus will be on the former in order to highlight the challenges and benefits of a dedicated project manager. Crowdtesting Processes The first step of each crowd-based test should be a briefing that defines the conditions of the test. What does the client need and how can the project manager realize this in the test? This includes, among other things, the focus of the project (Bug-finding, usability testing or combined testing), the target group of the software and the devices, as well as operating systems that should be part of the test. Using this information, the project manager sets up the test on the online platform and makes the software available for the carefully selected testers. For web-based tests this usually works through some kind of access data. Mobile applications can be distributed through a dedicated app store on the same platform before release, whether it is Android or iOS.

Pagina 44

The users are then able to test in their familiar surroundings, using their own devices, and are therefore more able to provide unbiased information than the developers or in-house testers. Each tester documents his or her work in the form of process descriptions and screenshots or screencasts. In addition, they might have to answer qualitative and quantitative questions, which are evaluated by a project manager and provided to the client as a final report with recommendations for improvements. A list of all found defects can be either exported or directly pushed into several bug-tracking systems.

Benefits of crowd-based software testing The most obvious benefits of crowdtesting are given by the fact that the crowd consists of real users who test software flexibly, which means they are available on demand. Consumers can also reflect reality better than traditional in-house testing methods. In addition, the crowd has various combinations of devices, operating systems and browsers already at hand, which would be almost impossible simulate or to supply for an internal lab. This large pool of thousands of different testers allows the selection of specific target groups, as well as recreational testers or even certified testers. Since the testing process is fast and flexible in itself, it can be integrated into existing release cycles and identified shortcomings can be corrected immediately. Ideally, software is tested before release. Crowdtesting allows testing in different stages of the development ranging from the evaluation of prototypes to a final check at the end of the beta-phase. Both aspects, the availability of real users and devices, allow for a significant reduction in development costs. As a result, the quality of the software increases while giving the client more internal resources for further development. Project management crucial for high quality For the success of crowdtesting projects, the availability of the crowd is just as important as a professional and high-quality project- and process-management. The client needs to be certain that at any time in the test phase, the transmitted data will be treated confidentially - especially for previously unpublished software.

Pagina 45

It is the duty of the service provider to ensure that all information and content will be kept confidential. While the testers are obliged to keep confidentiality though the terms and conditions, other precautions can be taken as well. An example of this is the signing of additional non-disclosure agreements. Project managers are required to select the crowd according to the customer requirements, which can be a very complex task. Choosing the correct crowd includes considering variables such as demographic data, devices, operating systems and testing experience. Much of this selection process is therefore automated and done by the crowdtesting platform itself, after all the requirements have been entered. The issue of maintaining quality is crucial for crowdtesting. Since everybody can sign up to become a crowd tester, new testers have to pass a qualifications test in order to participate in paid projects. This test is similar to a normal project and serves as a means for testers to get to know the platform and its requirements. In each test, a project manager reviews all reports and bugs submitted by the testers for completeness, traceability and quality. Only then will they be accepted and cleared for customers to see on their backend. Otherwise the tester has to revise the submitted content until the desired quality is reached. Test protocols also include screenshots or even screencasts in order to ensure test coverage. Crowdtesting as an addition to internal testing In summary, there are several requirements for crowdtesting to be successful: 1. The setup has to fit a remote test; 2. The right testers need to be selected (target group and/or experts); 3. Documentation is crucial to ensure test coverage. If these conditions are met, crowdtesting can supplement traditional software testing methods and offer valuable results that many companies did not have access to before. Since the crowd is not involved in the development of the application itself, unbiased feedback is one of the benefits. In short, user acceptance is a critical factor. Due to the diverse coverage of various device combinations, bugs can be identified on almost all devices. In a traditional environment, this testing would be immensely time-consuming and expensive. Activities such as the so-called Bug Approval allow to verify bugs found by a single tester on all other devices taking part in the test. As a result, major defects can be separated from those only appearing on very specific device configurations. It is important to note that in-house testing as well as automated tests are still vitally important for the success of the software. However, an ever-growing spectrum of devices combined with rising user expectations make for a tight race among competitors in any market. As a result, it can be the little things deciding over the success or failure of an application. Under the right conditions, crowdtesting can secure a competitive advantage and become a continuous part of the testing process. Crowdtesting is not an alternative to existing testing methods, but rather an additional level of quality assurance, which addresses many current issues. In the smartphone industry, several providers offer remote access to physical devices, which are controlled by means of software. However, this can only simulate the real situation. In addition to in-house and automated tests, as well as quantitative methods such as A/B Testing, the qualitative method used for crowdtesting relieves internal resources and delivers valuable results before release.

Pagina 46

WIPM - HEURISTIEK VOOR EEN CONTEXT-DRIVEN TESTAANPAK Door Joep Schuurkes ● [email protected]

@j19sch

Als je vraagt: ‘Wat is context-driven testen?’, dan word je vaak doorverwezen naar de zeven principes. Jammer genoeg zijn die vrij abstract en daarmee moeilijk toe te passen. In mijn eigen zoektocht hierin heb ik een heuristiek bedacht, afgekort WIPM om een beter houvast te geven voor een context-driven testaanpak. (Een heuristiek is een feilbaar middel om een probleem op te lossen of een beslissing te nemen, James Bach). Stel, je hebt het één en ander gehoord over context-driven testing en nu wil je graag je volgende testopdracht context-driven aanpakken. Wat je zou kunnen doen, is naar www.context-driven-testing.com gaan, de zeven principes van context-driven testen doornemen en die dan toepassen. Het probleem is alleen dat die zeven principes vrij abstract zijn. Principe 3 bijvoorbeeld: ‘People, working together, are the most important part of any project’s context.’ Ok, mensen die samenwerken zijn dus heel erg belangrijk, maar wat moet je daar concreet mee, bijvoorbeeld als je met de projectmanager aan het praten bent? Daar geven de principes zelf niet echt een antwoord op. Een andere mogelijkheid is dat je de blogs van een aantal context-driven testers gaat lezen, ze gaat volgen op twitter of met ze gaat praten op een congres of een Testnet-evenement. Probleem hiervan is dat je op deze manier wel een groot aantal puzzelstukjes kunt verzamelen, maar je moet ze zelf in elkaar passen. En misschien ben je toevallig nog niet tegen dat ene puzzelstukje aangelopen dat je nodig hebt voor je huidige opdracht. Je zult dus moeten vertrouwen op serendipiteit, wat niet de meest gestructureerde aanpak is. (Serendipiteit is iets nuttigs of goeds vinden, terwijl je er niet naar op zoek was.) Nu heb ik zelf wel gedaan wat ik hierboven beschrijf. En na ongeveer tweeënhalf jaar puzzelstukjes verzamelen en in elkaar proberen te passen, zag ik ineens dat ik een groot stuk van de puzzel af had. Misschien wel het belangrijkste resultaat was mijn persoonlijke samenvatting van context-driven testen, de WIPM-heuristiek die ik hier ga beschrijven. Het is daarmee niet de magische sleutel waarmee iedereen gelijk context-driven kan testen (het heet niet voor niets een heuristiek), maar het kan wel helpen om te begrijpen waar context-driven testen over gaat. Hopelijk help ik met mijn heuristiek dus de zoektocht van een aantal mensen wat korter te maken. Waarde-Informatie-Processen-Middelen De WIPM-heuristiek begint als een model: Waarde - Informatie - Processen - Middelen. Om het gelijk op iets concreets toe te passen: dit artikel is een Middel. Door het Proces van lezen creëer jij als lezer Informatie: jouw interpretatie van dit artikel en alle vragen en bedenkingen die je erbij formuleert. En hopelijk is die Informatie van Waarde voor je. Mocht dit niet zo zijn, dan stop je waarschijnlijk vrij snel met lezen. Dit WIPM-model kunnen we natuurlijk ook toepassen op testen. De middelen zijn

alle

dingen

die

we

gebruiken:

een

scrum

board,

een

requirementsdocument, een bevindingenadministratietool. Die middelen op zich doen niets; het zijn dingen. Wil er iets gebeuren, dan hebben we processen nodig. En ik bedoel processen in de ruime zin van het woord: alles wat gebeurt, is een proces. Iemand die netjes zijn werkinstructies volgt, is dus evenzeer een proces als iemand die koffie haalt. Voorbeelden van typische testprocessen zijn lezen, analyseren, modelleren en communiceren.

Pagina 47

Processen leveren informatie op. Informatie zit in je hoofd; het is je kennis, je gedachten, je vragen, enzovoort. Informatie is dus alleen te delen als je het via een proces transformeert tot een middel: tekst, spraak, gebaren. Vandaar ook dat ik bij middelen het requirementsdocument noemde en niet de requirements. Het document is een middel; de requirements zijn de informatie. Andere vormen van informatie zijn het testplan, testideeën, vragen en bevindingen. Tot slot is er waarde. Sommige informatie is van waarde en andere niet. Als we naar testen als geheel kijken, wat is dan waardevolle informatie? Simpel gezegd: inzicht bieden in wat doet het wel, wat doet het niet en waarvan weten we het nog niet. Context-driven testen versus best practices Voor zover het model WIPM. Om van het model een heuristiek te maken, is nu de vraag: wat is het verband tussen WIPM en context-driven testen? Je kunt je op twee manieren door het model bewegen: van onder naar boven, dus van Middelen naar Waarde of andersom, van boven naar beneden, waarbij je vanuit Waarde vertrekt. Als je van onder naar boven werkt, dan werk je met best practices. Je vertrekt van een bepaald Middel in de hoop daarmee de gewenste Waarde af te dwingen. Jammer genoeg werkt dit vaker niet dan wel. Een goed voorbeeld is bevindingenafhandeling. Je kunt een tool nemen met voorgedefinieerde statussen (nieuw, open, et cetera) en rollen (developer,

tester,

et

cetera).

Daarna

koppel

je

bepaalde

statusovergangen aan bepaalde rollen. Je richt je tool dus zo in, dat je mensen dwingt bepaalde processen te volgen, zodat de informatie correct is en er dus Waarde gegenereerd wordt. Dit heb ik echter nog nooit op die manier zien werken. Wat ik wel heb gezien, is dat mensen de bevindingenadministratie waardevol vinden en dus goed bijhouden, ofwel het gevoel hebben tegengewerkt te worden en dus zo goed en kwaad als het kan om de tool heen werken. De kwaliteit van je bevindingenadministratie heeft dus niets (of weinig) te maken met het gekozen Middel, maar wel met de vraag of de mensen die ermee werken, de Waarde ervan inzien of niet. Ga je daarentegen van boven naar beneden door WIPM, dan begin je met de vraag welke Waarde je wilt realiseren. Je kijkt welke Informatie hiervoor nodig is, wat er moet gebeuren (Processen) om die informatie te produceren en welke Middelen hiervoor nodig zijn. Deze manier van werken ligt aan de basis van een context-driven testaanpak. Jij, als vakman, doet wat je doet, omdat je begrijpt wat er moet gebeuren om de gewenste Waarde voort te brengen. Dit is ook de reden dat het zevende principe van context-driven testen het heeft over ‘judgment and skill’. Een context-driven testaanpak vraagt meer van een tester dan het (al dan niet) pragmatisch toepassen van een set Middelen en Processen. Het vraagt om een fundamenteel andere kijk op testen.

Pagina 48

Epistemologische complexiteit (Epistemologie is de tak van de filosofie die de aard, oorsprong en reikwijdte van kennis en het weten onderzoekt.) Om één aspect van die fundamenteel andere kijk te illustreren, moet ik terug naar mijn uitleg over het lezen van dit artikel aan de hand van WIPM. Hoewel die uitleg klopt, is wat er in werkelijkheid gebeurt veel ingewikkelder. Als we alleen al kijken naar het aantal transformaties: het artikel weerkaatst licht in je oog, je oog zet dit om in elektrische impulsen, je hersenen herkennen die impulsen als een Nederlandstalige tekst in het Romeinse schrift en die tekst wordt geïnterpreteerd op basis van je kennis en je eerdere ervaringen. Kortom, wat er gebeurt tijdens iets dat we 'lezen' noemen, is erg complex. Het besef van die complexiteit is erg belangrijk binnen context-driven testen. En met lezen heb ik dan nog een erg eenvoudig voorbeeld gekozen. Als we kijken naar andere mentale processen die gebeuren tijdens het testen (analyseren van een bevinding bijvoorbeeld) en hoe complex die zijn, dan is stellen dat testen ‘a challenging intellectual process’ is (principe 6), misschien nog wel een understatement. Hoe dan ook, als we goed willen testen, als we ‘judgment and skill, exercised cooperatively’ (principe 7) willen gebruiken, dan zullen we moeten begrijpen wat dat precies inhoudt. We moeten dus naar disciplines als de filosofie (epistemologie, logica, wetenschapsfilosofie), de psychologie, de gedragseconomie en de sociologie kijken om te weten wat onze menselijke mogelijkheden en beperkingen zijn en hoe we die het beste inzetten tijdens het testen. En mensen dan? En dit brengt me op een ander belangrijk punt: mensen. Als we naar de WIPM-heuristiek kijken, dan komen mensen hier nergens expliciet in voor. En dat terwijl het derde principe van context-driven testing zegt: ‘People, working together, are the most important part of any project’s context.’ De reden hiervoor is dat mensen onderdeel zijn alle vier de onderdelen van WIPM. Ten eerste kunnen mensen Middelen zijn. Als je iets bij iemand anders navraagt, dan gebruik je hem als middel. Ten tweede zijn er mensen nodig om Processen te laten ontstaan en nog belangrijker om ze te observeren. Wat gebeurt, maar waarvan we nooit iets zullen merken, had net zo goed niet kunnen gebeuren. Ten derde, Informatie. Informatie bestaat alleen in de hoofden van mensen, dus zonder mensen geen Informatie. Tot slot, mensen zijn nodig om ergens Waarde aan toe te kennen, want Waarde is altijd Waarde voor een bepaalde persoon. Daarnaast - om tegengewicht te bieden aan het gebruik van mensen als middel - zijn mensen op zich altijd van Waarde. Je kunt ze dus niet puur en alleen als Middel gebruiken. Zonder mensen blijft er van de hele WIPM-heuristiek dus weinig over. Tot slot Om af te ronden, welke aspecten van context-driven testen hebben we nu teruggevonden in de WIPM-heuristiek? •

Ten eerste is er het feit dat WIPM een heuristiek is, het is een feilbaar middel. Deze keuze voor heuristieken in plaats van technieken binnen context-driven testing, hangt nauw samen met het besef van de epistemologische complexiteit van testen.

•

Een tweede aspect is het belang van mensen en van het menselijke perspectief.

•

Ten derde is er het vereiste om eerst de context te verkennen, te bepalen welke waardevolle informatie nodig is en dan pas over te gaan op de keuze van processen en middelen.

Tot slot zou ik natuurlijk de zeven principes van context-driven testen erbij kunnen pakken en afvinken welke er in de WIPM-heuristiek terug te vinden zijn en welke niet, maar dat laat ik graag over als oefening voor de lezer.

Pagina 49

TESTSCHOLEN, KIEZEN OF MIXEN? ‘To be or not to be, that is the question; whether 'tis nobler in the mind to suffer the slings and arrows of outrageous fortune, or to take arms against a sea of troubles, …’ (Hamlet) Door Wim ten Tusscher ● [email protected]

@WimtenTusscher

Een oud verhaal, maar erg toepasbaar op de hedendaagse situatie binnen de testwereld. Waar de testwereld in Nederland groot is geworden door gestructureerd testen, timmert de laatste jaren de Context Driven school of testing nadrukkelijk aan de weg. De andere visie die de Context Driven school op testen heeft, roept vragen op bij bedrijven waar getest wordt, maar ook binnen de testwereld zelf: •

Moeten we anders gaan testen?

•

Hebben we het altijd verkeerd gedaan?

•

Of is onze traditionele aanpak beter?

Er zijn krachten in de media die ons willen doen geloven dat de enige goede tester een Context Driven geschoolde tester is en dat alle ISTQB- of TMap-geschoolde testers niet goed bezig zijn. Ik durf te stellen dat dit niet waar is, goed zijn in een school is namelijk geen garantie voor succes. Want wie kent hem niet, de briljante student die cum laude is afgestudeerd in meer dan één studierichting, maar die totaal niet succesvol is in het bedrijfsleven. Daarnaast ben ik ervan overtuigd dat elke goede tester Context Driven denkt en handelt. Hiermee bedoel ik, dat hij een open oog heeft voor zijn omgeving en dat hij binnen de context van zijn omgeving de juiste testaanpak kiest om zijn testklus succesvol te voltooien. Daartoe heeft hij een goed gevulde gereedschapskist met de juiste mix van aanleg, kennis en ervaring. Testscholen en hun kenmerken Laten we eens even stilstaan bij de verschillende testscholen. Er zijn vier verschillende scholen: de Analytical, de Factory, de Quality en de Context Driven school. Elke school heeft zijn eigen kijk op testen. Zo heeft de Analytical school een wiskundige benadering waarbij code coverage en gebruik van testtechnieken voor het bereiken van een gedefinieerde testdekking centraal staan. De Factory school legt de nadruk op testen volgens een gedefinieerd testproces met oog voor beheersing van tijd en geld. De Quality school legt de accenten weer heel anders, hier is testen de bewaker van de kwaliteit en deze school deelt testen daarbij een veel meer directieve rol toe dan de andere scholen. Last but not least legt de Context Driven school het accent op het testen zelf, de testdaad, de rol die de tester als persoon daarin heeft, het belang van vragen stellen en een creatieve benadering. Het klopt dat TMap en ISTQB niet in dit rijtje staan. Het zijn geen testscholen pur sang, maar visies op testen die kenmerken uit verschillende scholen combineren. Ze hebben het meest weg van de Factory school maar er zijn ook kenmerken van de andere scholen in terug te vinden.

Pagina 50

Tussen de aanhangers van de verschillende scholen ontstaat wel eens discussie over wat de betere school is. Ik vind dit zelf een zinloze discussie, want elke school maakt keuzes in zijn benadering van testen en heeft daardoor zowel sterke als zwakke punten. Zo geeft een goed beschreven testproces houvast en helpt het je geen zaken over het hoofd te zien. Ook is het makkelijk uitlegbaar aan bijvoorbeeld het management. Maar is er ook het risico, dat testers zich achter het proces gaan verschuilen, dat het volgen van het proces het hoofddoel wordt en er niet meer wordt gelet op de kwaliteit van het testen. Kies je voor het niet volgen van een proces, dan is er veel keuzevrijheid

maar

weinig

houvast.

Zeker

voor

de

beginnende, minder ervaren, tester is dit lastig. Ook is moeilijker uitlegbaar hoe je als tester te werk gaat en doordat er minder houvast is, ontstaat eerder het risico dat je als tester iets vergeet. Naast het hebben van sterke en zwakke punten, is er het een feit dat een context waarin moet worden getest en/of de tester die het werk moet uitvoeren, bijna nooit voldoet aan alle randvoorwaarden die elke school, impliciet of expliciet, stelt. Als je te strikt in de leer bent en je het testen niet kunt aanpassen aan de (on)mogelijkheden van jezelf of van de actuele omstandigheden, ga je al snel suboptimaal testen of, nog erger, word je gezien als een zeurpiet die continue vraagt om het invullen van de randvoorwaarden voordat hij zijn werk kan doen. Al snel wordt dan de toegevoegde waarde van de tester in twijfel getrokken en terecht! Laten we eens kijken naar wat deze (on)mogelijkheden bepaalt: de context. De context van testen De context van testen is heel divers. De branche waarin het bedrijf opereert speelt een belangrijke rol. Consumentensoftware vraagt namelijk een andere benadering dan een professionele applicatie, zeker als deze laatste safety critical is. Maar ook zaken als de ontwikkelmethodiek en de projectmanagementvorm hebben grote invloed op de testaanpak. Denk alleen al aan het verschil tussen de agile/scrum en de traditionele watervalaanpak, twee totaal verschillende contexten waarbinnen een tester zijn werk moet kunnen doen. Ook het kennisniveau van testen, de organisatievorm van de testafdeling (competence centre of gedecentraliseerd), het wel/niet outsourcen van testen, de hoeveelheid testbudget, de beschikbare testtijd en de kwaliteit van de testbasis spelen allemaal een rol bij de keuze van de optimale testaanpak. En dan is deze context ook nog continu in beweging, zelfs binnen eenzelfde organisatie. Goed stilstaan bij de vraag in welke context je je werk als tester moet doen en beschikken over voldoende gereedschap om in verschillende situaties tot een goed testresultaat te komen, zijn dus essentieel. De gereedschappen van de tester Een goede tester moet slim zijn en beschikken over een goed analytisch vermogen. Daarnaast is hij leergierig en nauwkeurig. Allemaal zaken die in aanleg bepaald zijn en maar tot op zekere hoogte trainbaar zijn. Het helpt dus als iemand van nature over deze eigenschappen beschikt. Kennis doet de tester op tijdens zijn schoolopleiding en tijdens zijn testopleiding, beide kunnen zeer divers van karakter zijn. We zien in de testwereld zowel alpha- als bètageschoolde testers en ook in testscholing is de variatie groot: ISTQB, TMap, Context Driven, Agile tester.

Pagina 51

Ervaring doet de tester op tijdens zijn werk, liefst in veel verschillende situaties. Daarbij is de wil om te leren (ook van fouten) erg belangrijk: alleen dan leert de tester zich aan te passen en pragmatisch te zijn. Dit is makkelijker gezegd dan gedaan. We hebben allemaal door vallen en opstaan leren fietsen, maar naarmate we ouder worden rust er meer en meer een taboe op fouten maken. Ons hele schoolsysteem is zo ingericht, dat fouten maken wordt bestraft met een slecht cijfer. Ook in het bedrijfsleven is er meestal geen cultuur die fouten tolereert. Het is dus niet vanzelfsprekend dat we leren van onze fouten, liever voorkomen we dat we fouten maken. Daarmee verdwijnt echter ook meteen de mogelijkheid tot leren! Gelukkig beschikt iedere tester

loslaten een belangrijke rol, de

nog

perfecte match met de Context

over

een

ander,

zeer

veelzijdig, stuk gereedschap, zijn brein. Kijkend naar het brein zien we twee helften die elkaar aanvullen. De linkerhelft is sterk in

orde

en

patronen,

logica,

feiten, theorie en controle. De perfecte

match

procesmatige Factory

aanpak

school

Analytical uitstekend!

met

en

school De

de

van

de

ook

de

past

hier

rechterhelft

maakt ons creatief, hier spelen zaken

als

gevoel,

verkennen,

Driven school. De natuur heeft ons niet voor niets

twee

hersenhelften

gegeven, ze vullen elkaar aan. Dit is nodig omdat onze wereld ook niet alleen maar links of rechts is. Elke situatie waarin we terecht komen, is anders en de ene keer vraagt hij om een linker aanpak en de andere keer heeft een rechter aanpak of een mengvorm van links en rechts het meeste succes.

risico, verbeelding, praktijk en

Ondanks dat elk mens over twee hersenhelften beschikt, heeft iedereen in aanleg een voorkeur voor links of rechts. Deze voorkeur ontstaat doordat beide helften niet even sterk ontwikkeld zijn. Dit is echter geen status quo, het meest krachtige kenmerk van ons brein is namelijk dat we het kunnen trainen. Op die manier kunnen we beter worden in zaken waar we minder goed in zijn of ons minder zeker bij voelen. Een goed ontwikkelde linker- en rechterhelft schept de mogelijkheid om je maximaal aan te passen aan elke context en daarin het meest succesvol te zijn. Mijn eigen ontwikkeling Dat bovenstaande stelling klopt heb ik door schade en schande aan den lijve ervaren in zowel mijn professionele als ook mijn privésituatie. In beide heb ik een drietal fasen doorlopen met verrassende overeenkomsten en een grote mate van synchroniciteit.

Fase 1: Ericsson – de alleenwonende single Deze fase werd gekenmerkt door mijn natuurlijke voorkeur voor mijn linker hersenhelft. Ik werkte voor Ericsson en deze telecomgigant kenmerkte zich door een heel gestructureerde, procesmatige aanpak van soft- en hardware-ontwikkeling. We hebben het hier over midden jaren negentig van de vorige eeuw en we werkten op CMM level 2 niveau met een sterke wens om level 3 te worden.

Pagina 52

Testen binnen deze omgeving was dan ook sterk procesmatig en gestoeld op een uitgebreid pakket gereviewde requirements, die vertaald werden naar een handmatige en geautomatiseerde testset. Bevindingen- en changemanagementprocessen waren strak ingeregeld en een product ging alleen naar de markt als het foutloos was. Een perfecte wereld voor een jonge engineer met een sterk ontwikkelde linker hersenhelft. Structuur was er zeker ook in mijn thuissituatie, ik was een alleenwonende single dus ik hoefde met niemand rekening te houden. Mijn hang naar structuur en perfectionisme vertaalde zich thuis naar een gepland leventje in een opgeruimd huis waar alles een vaste plaats had. Kortom, een voorspelbaar leventje waar ik me prima in thuis voelde.

Fase 2: Echostar – het gezinsleven Door twee ongeplande omstandigheden werd mijn leven ruw verstoord: de Ericsson vestiging waarvoor ik werkte werd gesloten en ik ging werken voor een nieuwe baas, Echostar. Voor de tweede verandering koos ik zelf, ik nodigde een vriendin uit voor een etentje en binnen no-time woonden we samen. Nu wilde het lot dat zowel mijn nieuwe werkgever als mijn nieuwe huisgenoot een nogal andere kijk op de wereld hadden dan ik. Het grote verschil zat hem in een, althans zo kwam het op mij over, totaal gebrek aan structuur. Dat was wennen! Echostar was een Amerikaanse firma en een voorloper in nieuwe technologie. Time-to-market was het meest belangrijk en ten tijde van introductie van een nieuw product gold de regel ‘goed is goed genoeg’, als eerste in de markt heb je toch geen concurrenten! De puntjes op de i kwamen later wel. Er werd niet procesmatig gewerkt. Testen ging op een exploratory / error guessing manier en requirements lagen vast in het product zelf! Thuis was het niet anders, mijn vrouw kon prima overweg met weinig structuur en vond mijn georganiseerde leventje maar saai en ingewikkeld. De huisdieren die er al snel kwamen, zorgden ervoor dat mijn hang naar perfectie op de proef werd gesteld, want zij hadden andere eisen aan een perfecte omgeving dan ik. De komst van kinderen maakte, dat ik mijn geplande leventje helemaal moest loslaten. In het begin heb ik me verzet tegen alle veranderingen, maar gaandeweg werd duidelijk dat dit tot een suboptimaal resultaat leidde, waar zowel ik als mijn omgeving niet blij van werden. Het heeft geruime tijd gekost, voordat ik mijn rechter hersenhelft zover had ontwikkeld, dat ik goed kon omgaan met mijn veranderde wereld. Maar op zeker moment raakte ik eraan gewend en begon ik zelfs de voordelen ervan in te zien. Er deden zich ineens onverwachte kansen voor, die zich vroeger niet hadden aangediend.

Fase 3: Consultant – met pubers Kleine kinderen worden groot en ook Echostar had niet het eeuwige leven, dus fase drie diende zich aan. Professioneel koos ik ervoor om de wereld van de testconsultancy in te gaan, ondenkbaar in mijn jonge jaren want elke klant is anders en vraagt een andere aanpak om succesvol te zijn in testen, dus allesbehalve een gestructureerde situatie. Maar inmiddels was ik zover dat ik de continue veranderingen niet meer als een bedreiging zag, maar als een uitdaging tot verdere persoonlijke ontwikkeling. Ditzelfde geldt voor de omgang met mijn nu puberende kinderen. Soms kun je ze behandelen als een volwassene en vrij laten (rechterhelft), maar even later zijn ze nog het onvolwassen kind dat duidelijke structuur nodig heeft (linkerhelft). Zowel op het werk als thuis moet ik dus nu continu schakelen tussen mijn linker en rechter hersenhelft om steeds het maximale resultaat uit de situatie te halen. Professioneel betekent dit, dat ik het ene moment bij een procesgeoriënteerde klant werk die test volgens TMap en het andere moment werk bij een klant die niet procesmatig werkt en waar een sterk beroep wordt gedaan op je creativiteit.

Pagina 53

Recentelijk heb ik bijvoorbeeld gewerkt bij een klant waar een testproject was vastgelopen in een TMap-aanpak en waar ik met een paar creatieve aanpassingen als pairwise testen met materiedeskundigen, breedte-eerst aanpak en exploratory testen het project heb vlot getrokken en tot een goed einde heb gebracht. Ben ik nu de perfecte tester en huisvader? Nee, verre van dat. Er is nog een lange weg te gaan, want thuis maakt de emotionele betrokkenheid bij je vrouw, kinderen en huisdieren dat je gauw terugvalt in gedrag dat past bij je voorkeurshersenhelft. Ditzelfde zie je op het werk: in stress-situaties merk je dat je terugvalt op je voorkeur en is het moeilijker om je nieuw ontwikkelde vaardigheden te blijven toepassen. Ik ben er dus nog lang niet. Wel kan ik uit eigen ervaring stellen, dat ik blij ben met mijn meer ontwikkelde rechterhersenhelft. Ik ben daardoor zowel thuis als op mijn werk meer succesvol en kan meer genieten van de situaties die zich voordoen. Even terug naar de vraag ‘Testscholen, kiezen of mixen?’ mag duidelijk zijn dat ik een voorstander ben van niet kiezen en altijd mixen. Hoe meer gereedschap je in je koffer hebt, des te meer succesvol je bent in de praktijk van alledag. Deze is namelijk ook nooit extreem links of rechts maar vertoont een veelvoud van kenmerken in alle gradaties tussen uiterst links en rechts. Een goede tester lijkt veel op een kameleon, in staat om zich aan te passen aan elke situatie om daarin maximaal succesvol te zijn in het vangen van bugs. Wel verschilt de moderne tester op één belangrijk aspect van de kameleon: hij is allesbehalve onzichtbaar voor zijn omgeving!

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.