Story's toets je, klanttevredenheid test je

Testen en toetsen, het zijn binnen de testwereld op dit moment veelgebruikte woorden. Toetsen kan iedereen en is letterlijk de eisen controleren. Maar bij testen gebruik je je eigen kennis en vaardigheden om meer te controleren, dan in de eisen vermeld staat. Zo ongeveer heb ik het altijd begrepen. De afgelopen weken kwam ik echter tot een ander kennisinzicht.

Hoe goed geschreven, een story zijn woorden. Het zijn geformuleerde zinnen, die meestal vrij letterlijk te controleren zijn. Daarmee wordt een story een checklist, die je afvinkt. Wat is in de story gebouwd en wat niet.

Een story probeert te omschrijven wat een klant wil, maar doet het vaak niet. Hoewel officieel bij zowel Scrum als Agile een directe communicatie met de klant wordt gepromoot, zijn er heel veel Scrum en Agile teams, die de klant bijna nooit spreken. Een story is te vaak een vertaling van een vertaling van een vertaling van de wens van de klant. Daarnaast is de klant vaak geen ervaren wensschrijver. Werkelijk stilstaan bij alle schermen, instellingen en invoervarianten kan je vaak niet van een klant vragen. Stilstaan bij alles wat met kwaliteit te maken heeft: foutafhandeling, leerbaarheid, consistentie, performance, enz. al helemaal niet.

Wat de klant wil is dan ook niet te vatten in een kort tekstje. Zelfs heel moeilijk in een document van 5 pagina's. Om te weten wat de klant wil, moet je weten hoe de klant nu met je applicatie werkt. En omdat dat vaak moeilijk is te achterhalen, moet je minimaal kennis hebben van de applicatie. Hoe werkt de functionaliteit nu? Wat is het gevolg van de wijziging op de huidige functionaliteit? Wat is het gevolg van de wijziging op vervolgstappen? Maar ook standaard vragen als: wat zijn de verplichte gegevens, wat is de foutafhandeling, welke gegevens worden gebruikt in vervolgstappen? Niet elke vraag is bij elke stap even belangrijk. Maar elke vraag is altijd voor de klant belangrijk, omdat het voldoende beantwoorden van deze vragen de applicatie werkbaar en betrouwbaar houdt. Als een klant vraagt om een wijziging, maar deze wijziging zou verkeerde bedragen op facturen opleveren, wil de klant de wijziging niet. Als een klant vraagt om een wijziging op scherm 1, maar scherm 2 kan hetzelfde en wordt ook veelgebruikt, wil de klant ook de wijziging op scherm 2. Als de klant vraagt om bij het adres straat en huisnummer op te slaan, wil hij ook postcode en plaats. Meestal tenminste.

Waar het als tester om gaat, is dat je niet blind geloofd dat als het niet in de story staat, de klant het ook niet wil. En dat als wat in de story staat de werking van de applicatie slechter maakt, de klant dat toch wil. Een klant wil een goed werkende, betrouwbare applicatie. Een goede tester probeert hiervoor te zorgen. Soms ondanks de beschreven story's, soms zelfs tegen de beschreven story's in. En dat is testen!

Het Agile test manifest

Wij laten zien dat er betere manieren zijn om software te testen door in de praktijk d.m.v. testvoorbereiding, testen en testanalyse  te wijzen op kwaliteitsrisico’s in zowel de te testen applicatie als het testproces. Hiermee willen we anderen helpen de juiste keuzes te maken en ze daarnaast de benodigde informatie te geven om de kwaliteit van de applicatie de verbeteren. Daarom verkiezen we:

Samenwerken met het team boven uitgebreide bevindingenregistratie

Geteste software boven allesomvattende (geautomatiseerde) testscripts

Herhaalbare testen boven snel testen

Kwaliteitsrisico’s melden boven planningen volgen

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.

Dit manifest is een beoogd antwoord op de Agile en Scrum principes en richtlijnen, die in de praktijk voor vele testers vele worstelingen opleveren. Het doel is om, ongeacht een wel of niet goede toepassing van Agile of Scrum, als tester aan te kunnen geven waar je voor staat in een wereld, die zowel flexibiliteit als voorspelbaarheid vraagt.

Ik wil later tester worden!!

Ik test nu ruim 10 jaar. In juni 2006 startte ik als tester. En ik vind testen heerlijk. Toch heb ik altijd een haat-liefde verhouding met mijn vak gehad. Ik ben regelmatig een goede tester, omdat kwaliteit ligt in mijn hart en in mijn ziel. En ik ben regelmatig een slechte tester, omdat kwaliteit ligt in mijn hart en mijn ziel.

Waar het probleem is? Ik doe datgene, wat ik het beste vind voor de kwaliteit van het product. Vaak is dat testen of testautomatisering. Soms is dat documenten schrijven. Of gesprekken voeren. Of data analyseren. Of productkennis opdoen. Wat het beste is, bepaal ik door niet alleen het product te testen. Al meer dan 10 jaar test ik naast het product ook altijd het proces. Omdat ik weet, dat alleen een goed lopend proces kan leiden tot een goed werkend product. Dus als ik zie, dat de kwaliteit van opgeleverd werk slecht is, wil ik weten waarom dit het geval is. Als ik zie, dat een onderdeel niet of nauwelijks getest wordt, wil ik weten waarom die test wordt overgeslagen. Dus bedenk ik naast testen voor het product ook testen voor het proces. En probeer de oorzaak te achterhalen. En vervolgens een oplossing in gang te zetten

Wat is hier dan het probleem? Als ik het product test, zie ik zaken, die een ontwikkelaar gemist heeft. Als ik het proces test, zie ik zaken, die een Scrum Master, Manager, Project manager of Product Owner gemist heeft. Melden van bugs in het product is officieel mijn werk, dus dit mag altijd. Maar hoewel bijna iedereen aangeeft, dat ze open staan voor het melden van problemen in het proces, gaat dit in de praktijk zeker niet altijd makkelijk.

Is dat werkelijk zo'n probleem? Gelukkig niet altijd. Aan de ene kant zijn er altijd wel mensen te vinden, die open staan aan voor verbeteringen, die de kwaliteit ten goede kunnen komen. En aan de andere kant heb ik in de loop der jaren een hele trukendoos ontwikkeld: prototypes, proefperiodes, verdelen in heel veel taken van minder dan een uur (minder dan een uur tijdsbesteding hoef je vaak niet te verantwoorden), onderdeel maken van testvoorbereding (werkt uitstekend voor het bijwerken van documentatie) en nog veel meer. Het vreemde is: hoewel ik van tevoren vaak geen of zeer beperkte toestemming kreeg, heb ik naar aanleiding van het resultaat van deze veranderingen bijna nooit kritiek gehad op mijn werk. Wat begon als een tussendoorklus of bijklus, is later zelfs vaak een officieel onderdeel van mijn werk geworden. Soms zelfs mijn functie.

Maar soms is het echt wel een probleem. En dat blijkt vooral bij de volgende vraag: "Wat wil je later worden?" Denk hierbij aan varianten als: "Wat wil je het komende jaar bereiken?", "Wat voor werk wil je over drie jaar doen?", "Wat kan je voor ons bedrijf betekenen?". Als ik deze vraag eerlijk beantwoord, blijken mijn problemen pas echt. Ik wil later tester worden. Ik wil later de kwaliteit bewaken, op de beste manier mogelijk. En dan komen de vervolgvragen: "Hoe wil je dat doen?" of "Hoe heb je dit in het verleden gedaan?". Vervolgens praat ik mezelf te vaak vast. Ik weet precies wat ik wil doen. Ik wil bugs in zowel product als proces constateren, analyseren en vervolgens helpen bij het oplossen. Maar ik krijg het gewoon niet altijd verkocht.

Elke applicatie heeft andere bugs in het product, dus ik kan niet precies aangeven hoe ik de bugs precies ga vinden. En hoe ik kan helpen bij de oplossing. En elke organisatie, zelfs elk team, heeft andere bugs in het proces, dus ik kan niet precies aangeven hoe ik de bugs precies ga vinden. En hoe ik kan helpen bij de oplossing. Ik kan je succesverhalen vertellen over gevonden bugs in vorige geteste applicaties, maar  ik weet dat deze manier van testen voor jullie totaal zinloos kan zijn. En daarmee het gevolgde oplossingstraject ook. Ik kan je succesverhalen vertellen over gevonden bugs in vorige processen, maar ik weet dat die manier van testen voor jullie totaal zinloos kan zijn. En daarmee het gevolgde oplossingstraject ook. Ik kan je vertellen hoe ik bugs wil vinden in jullie product of in jullie proces, juist op de plekken waar nu problemen zijn. Maar als jullie zouden geloven, dat dit zou werken, hadden jullie dit zeer waarschijnlijk allang zo gedaan.

De boodschap, die ik breng, ongeacht of het over testen van product of over testen van proces gaat, is gewoon moeilijk te geloven. De stap zetten om te geloven in een oplossing, die gewoon volkomen onlogisch klinkt (want als het logisch was, had je het zelf al bedacht), is vaak al zeer moeilijk. Te geloven in een bepaalde aanpak of in een onbekende maatwerk oplossing, in plaats van in duidelijke, concrete, eerder gebruikte oplossingen, komt ook vaak over als vragen om geld te investeren in een verrassingspakket. Je weet niet wat je krijgt.

Waarom ik toch vaak succesvol ben? Ik heb zo mijn tovertrucjes. Uitproberen. Kijken. Niet opgeven. Luisteren naar collega's. Mijn eigen mening vormen. Niet opgeven. Kennis opbouwen. Tools gebruiken. Niet opgeven. Praten. Overtuigen. En vooral niet opgeven! Dus al mijn trucjes in het kort samengevat: testen, analyseren, werken aan de oplossing, evalueren en vooral niet opgeven!!

Soms duurde het een week, soms duurde het een jaar, soms duurde het zelfs nog langer. Soms werkte oplossing 1, soms werkte oplossing 3. Soms had een collega gelijk, soms had ik gelijk. Mijn doel is tenslotte niet om gelijk te krijgen of de snelste oplossing te vinden. Mijn doel is de kwaliteit te verbeteren. Stap voor stap, elke dag steeds beter. Of het nu om proces of om product gaat. En als het vandaag niet lukt, proberen we het morgen weer.

Mijn kracht als tester is, dat ik je niet direct vertel wat voor jou het beste is om de kwaliteit te verbeteren. Mijn zwakte als tester is, dat ik je niet direct vertel wat voor jou het beste is om de kwaliteit te verbeteren. Mijn kracht als tester is, dat ik kwaliteitsverbeteringen zoek, die aansluiten bij jouw product, proces en organisatie. Mijn zwakte als tester is, dat ik je geen standaard pakket met oplossingen biedt, die al 20 keer eerder heeft gewerkt. Ik heb daarom je vertrouwen nodig, een kans nodig, om mijn kracht te bewijzen. Ik snap dat ik die niet altijd krijg. Maar ik hoop dat je dan ook snapt, dat ik me niet altijd tester voel, omdat ik me niet met hart en ziel kan inzetten voor kwaliteit. En daarom soms zal blijven zeggen: "Ik wil later tester worden!!".

Angst voor statistieken: Statistieken als stok v.s. Statistieken als testcase

Ik had deze week een gesprek met een collega. We bespraken een statistiek gegeven dat erg slecht uitviel. Onmiddellijk ging het gesprek een bekende kant op. Er werd geprobeerd mij te overtuigen dit statistiek gegeven vooral niet te delen. Maar deze eerst uitgebreid te checken en controleren. Want dit kon niet correct zijn. En waarschijnlijk onuitgesproken: dit kon gebruikt worden om mensen te beschuldigen van slecht werk.

Statistieken worden vaak gebruikt als stok om mensen mee te slaan. Om mensen te beschuldigen van het leveren van slecht werk. Om mensen te vertellen dat ze niet genoeg verbeteren of niet voldoende verbeteringen doorvoeren. De gevolgen hiervan kunnen zeer groot zijn. Mensen houden geen statistieken bij, omdat ze managers geen stok willen geven om mee te slaan. Of nog erger: mensen gaan statistieken manipuleren. Maar wat als we nu de statistieken niet meer als stok zouden zien, maar als testcase?

Statistieken manipulatie

Om hier het nut van te bewijzen, eerst even twee situaties, die ik werkelijk heb gezien. De meest bekende is: gewoon geen statistieken maken. Statistieken maken kost tijd, soms veel tijd. Het aantal fouten meten of de gemiddelde oplostijd van een fout berekenen is zeker niet altijd eenvoudig. Als dit voordeel voor je heeft, zal dit geen reden zijn om het te laten. Maar als een manager ze wil (of zal gebruiken) om te ontdekken of jij je werk goed doet of niet, zal de motivatie heel erg laag zijn. Hoewel niemand ooit openlijk toegeeft hierdoor geen statistieken te maken, heb ik genoeg managers meegemaakt, waar dit bijna wel het geval moet zijn geweest. Statistieken werden gebruikt om onderscheid te maken tussen goede en slechte medewerkers. En tussen goede en slechte afdelingen of teams. Soms zelfs om een zondebok te kunnen vinden.

Statistieken manipuleren lijkt minder voor te komen, maar gebeurt regelmatig. En je zou denken, dat de gevolgen ook niet zo erg zouden zijn. De gevolgen kunnen echter zeer groot zijn. Neem nu bijvoorbeeld een veelvoorkomende manier van statistieken manipuleren: het veranderen van definities. Stel je hebt een bugregistratie en je krijgt te horen dat er teveel bugs zijn. Een oplossing hiervoor kan dan een andere definitie van een bug zijn. Normaal is een bug vaak omschreven als een handeling of groep handelingen, dat een fout resultaat of een ongewenste situatie oplevert. Maar je kan een bug ook zo omschrijven: een melding van een fout resultaat of ongewenste situatie voor goedkeuring (acceptatie) van de wijziging door de klant. De redenatie hierachter: als de klant geaccepteerd heeft, is de software dus goed. Alles wat ervan afwijkt kan daarom geen bug zijn. Wat is het nadeel hiervan? Bugs bijhouden doe je onder andere om na te gaan of je testprocessen goed werken. Als je de bugs maskeert als wijzigingen, zie je veel minder goed of je testprocessen goed genoeg zijn.

Een andere veelvoorkomende manier van statistieken manipuleren, is correcties toevoegen. Als ik 40 uur in de week werk en ik krijg er elke week onverwachts 10 uur bij, dan plan ik 30 uur week in. Dat zal niemand vreemd vinden. Maar als ik deze eenheid vervang door een andere eenheid, bijvoorbeeld taken, mensen, storypoints, wordt het verhaal regelmatig anders. Als ik elke week 40 taken in plan en ik krijg er elke week onverwachts 10 bij, dan plan ik voor de week erna niet 30 taken in. Nee, ik plan weer 40 taken in. Want ik weet dat ik 40 taken heb afgerond: 30 geplande en 10 onverwachtse. Dus ik kan 40 taken in een week uitvoeren. Dus ik plan 40 taken in. Want stel je voor dat mijn manager denkt, dat ik maar 30 taken kan uitvoeren in een week. Gevolg: heel veel niet gehaalde planningen.

Statistieken als testcase

Stel nu dat je statistieken als testcase zou beschouwen, wat houdt dat dan in? Een testcase is een serie van handeling, waarbij gecontroleerd wordt of het resultaat gelijk is aan het beschreven resultaat. Als een testcase faalt, kijkt een goede tester naar 3 mogelijkheden:

• De testcase is fout
• De eisen, waarop de testcase gebaseerd is, zijn fout
• De software is fout

Als ik dit vertaal naar statistieken, krijg ik de volgende mogelijkheden bij slecht uitvallende statistieken:

• De statistieken hebben een probleem
• De stappen voorafgaande aan de gemeten situatie hebben een probleem
• De gemeten stap heeft een probleem

Een goede tester gaat niet over tot de aanval, maar heeft geleerd om falende testcases te bespreken. In samenwerking met alle betrokkenen wordt bepaalt of er sprake is van een fout in de testcase, de eisen of de software. Daarnaast bepaalt de tester zelf of verder onderzoek nodig is.

Dus in mijn ogen pak je statistieken op de volgende wijze goed aan: je bespreekt ze met de betrokken om na te gaan of de statistieken, de voorafgaande stappen of de situatie zelf een probleem heeft of hebben. Daarnaast bepaal je zelf of verder onderzoek nodig is.

Het grote verschil: statistieken zijn nu niet meer om te bepalen wie goed werk heeft geleverd of wie niet. Net als een testcase niet tot doel heeft om te bepalen of een programmeur goed werk heeft geleverd of niet. Een testcase is een hulpmiddel om de kwaliteit van de software te bewaken. En statistieken worden zo een hulpmiddel om de kwaliteit van het proces te bewaken.

Statistieken moeten geen angst oproepen. Er moet geen neiging zijn statistieken te vermijden of te manipuleren, om te voorkomen, dat je op het matje geroepen wordt. Statistieken moeten gebruikt worden om het proces te bewaken en te verbeteren. Om problemen te vinden, door ze met mensen te bespreken, niet door de cijfers te laten spreken. Pas dan leiden ze tot een verbetering en niet tot stilstand of zelfs een verslechtering.

Playing the Blame Game

Welke tester kent het niet? Een deadline of sprint wordt niet gehaald. En vervolgens is er een oorzaak nodig. Wat vaak neerkomt op het vinden van een dader. Omdat het werk rond het einde van een sprint of deadline vaak bij de tester ligt (die zit tenslotte aan het eind), is de tester vaak de eerste persoon waarnaar gekeken wordt. Je testte te langzaam, te veel, enz. Of er zijn klachten van klanten over de kwaliteit gekomen. Dan is het misschien niet eens vreemd, dat er naar het testen gekeken wordt. Maar ook niet altijd terecht. In dat geval testte je juist te snel, te weinig, enz. .

Het zoeken naar de oorzaak van problemen is op zich een goed proces en een belangrijke stap, om problemen in de toekomst te verbeteren. Maar hoewel hierbij steeds wordt vermeldt, dat er niet naar personen gekeken moet worden, is dit erg moeilijk. Als je de conclusie trekt, dat het testen te lang heeft geduurd, kijk je daar al snel de testers op aan. Maar als je de conclusie  trekt, dat de testers te laat konden starten, kijk je al snel naar developers.

Toch merk ik in de praktijk, dat het kijken naar 1 of meer personen bij het probleem meestal niet het de oorzaak van een Blame Game is. Waar het mis gaat, en wat het tot een echt Blame Game maakt, is als de ander jou gaat vertellen wat de oorzaak of oplossing van het probleem is. Constateren dat testen te lang duurt, kan terecht zijn. Maar te vaak gaat de brenger van de boodschap een stap verder. Hij of zij vertelt je ook waarom het testen te lang duurt. Bijvoorbeeld: "Je test teveel". Zo'n opmerking is vaak het startschot van een volledige Blame Game ronde. Want de neiging is zo ontzettend groot om daarop te reageren met bijvoorbeeld "De developers willen gewoon mij niet de juiste informatie geven, waardoor ik niet kan weten wat ik moet testen".

Stopping the blame game

Hoe voorkom je dit? Hoe groot de neiging ook is, schiet niet in de verdediging. Het heeft ook weinig zin, want je wordt toch niet geloofd. Je gesprekspartner heeft vaak wel degelijk tijd en aandacht besteed aan het probleem en is tot deze conclusie gekomen. Hoe onterecht de conclusie ook is, jij bent niet in staat om in 1 gesprek de ander te overtuigen door deze achterstand. Jij hebt tenslotte niet de tijd en aandacht kunnen besteden aan dit onderwerp, waardoor jij geen feiten tegen de genoemde conclusie in kan brengen. En dat is wat je nodig hebt: feiten. Alleen met feiten kan je een einde maken aan een Blame Game.

Dus daarom: geef wel degelijk aan dat je het er niet mee eens bent. Maar geef daarnaast vooral aan dat je mee wil werken om het probleem op te lossen. Probeer erachter te komen, waar deze conclusie op gebaseerd is. En, ongeacht of dit lukt op niet, vraag de tijd om dit probleem goed in beeld te krijgen. Probeer er ook voor te zorgen, dat je het eisenpakket in beeld krijgt. Hoelang mag het testen duren? Dan weet je waar je mee kan vergelijken.

Er zijn nu twee mogelijkheden: je krijgt de kans om zelf alsnog tijd aan de oplossing te besteden of je wordt gedwongen tot een oplossing van de ander. In het tweede geval: leg tijdens het gesprek de verantwoordelijkheid van de oplossing bij de ander. Maak heel erg duidelijk: dit is geen goed besluit. Maar probeer niet meer te overtuigen.

Wat er ook gebeurt: neem na het gesprek zelf de tijd en aandacht om naar het probleem te kijken. Als er bijvoorbeeld gezegd wordt, dat je langzaam test en je weet dat dit waar is, leg dan de oorzaken vast. Leg per story, RFC, enz. vast waardoor de vertraging veroorzaakt wordt: voor de test is veel voorbereiding nodig, er zijn veel varianten om te testen, je moet eerst informatie achterhalen, vragen aan anderen staan erg lang open, er zijn tijdens de test wijzigingen, waardoor het testen overnieuw moet, enz. Als het probleem niet waar is, leg dan vast hoelang je over het testen doet.

Als jou een oplossing is opgedwongen, leg dan ook de risico's van deze oplossing vast. Waarom wil jij deze oplossing niet? Bij het gedwongen inkorten van testen kan je bijvoorbeeld bang zijn voor meer fouten bij klanten, omdat je testen moet inkorten. En bedenk hoe je dit risico kan bewaken. Je kan bijhouden hoeveel fouten klanten melden bij een acceptatietest. Maar je kan ook duidelijk aan gaan geven, wat jij in de aangegeven tijd niet kan testen. Mensen zeggen snel: "test gewoon wat sneller". Maar als je aangeeft: "OK, dan test ik X en Y en Z niet", is het enthousiasme over de oplossing vaak een stuk minder.

Wanneer je de feiten over het aan jou gemelde probleem verzameld heb, maak een nieuwe afspraak. Leg de feiten voor en vertel daarbij wat volgens jou het probleem is. Wat is de belangrijkste oorzaak van het langzame testen? Wat is de werkelijke doorlooptijd van het testen? Wat zijn de risico's van de genoemde oplossing? Hoe kunnen we dat bewaken? In veel gevallen is een gesprek als dit de finish van een Blame Game. Omdat dit gesprek ervoor zorgt, dat je samen werkt aan een oplossing. Je staat niet meer tegenover elkaar.

Een Blame Game ontstaat vaak, doordat de twee kampen beiden het gevoel hebben, dat de ander niet naar ze luistert. Ze niet serieus neemt. De truuk om een Blame Game te stoppen, is om niet toe te geven dat de ander gelijk heeft, maar tegelijkertijd wel duidelijk te maken dat je de ander serieus neemt. Ook jij wil deze situatie oplossen. Daarom wil je weten wat er aan de hand is, wat eraan gedaan kan worden en wil je best een oplossing uitproberen. Mist er bij die oplossing wel naar de risiso's wordt gekeken.

De extra truck is om feiten te vinden, die in jou ogen een goed beeld geven van het probleem. Om tot een beeld te komen, waar jullie het over eens zijn. Want als jullie het over de feiten eens zijn, wil je beiden hetzelfde probleem oplossen. Wat het vinden van een oplossing, waar jullie beiden achter staan, een stuk eenvoudiger maakt.