Een andere vorm van waardering

Ik heb gisteren afscheid genomen van mijn huidige baan. Het was een vreemd afscheid, duidelijk anders dan je als buitenstaander zal verwachten. Wel met veel waardering. Maar voor het grootste deel een andere vorm van waardering. Geen verhalen over mijn grote successen als tester. Weinig verhalen over hoe fijn ik was als collega. Betekent dit dat ik geen successen heb gehaald? Dat mijn huidige collega's nooit meer met me samen willen werken? Ik weet wel zeker van niet. Want de waardering voor wat ik heb gedaan was er wel degelijk. Alleen anders.

En van mijn kant was het trouwens niet anders. Ik heb veel waardering voor de collega's en managers, met wie ik in de afgelopen 3+ jaar heb samengewerkt. Toch zal je ook van mijn kant niet veel verhalen horen over succesvolle projecten of gezellige momenten met collega's. Niet omdat ze er niet waren. Ze waren er. Maar de waardering voor een andere kant van de baan was voor mij veel en veel hoger.

Wat ik waardeer in mijn collega's en managers van de afgelopen jaren, gaat voor mij over groei. Ik heb de kans gekregen binnen een groep mensen te werken, waar ik kon groeien. Een groep mensen, waar ik fouten kon maken en vervolgens erop kon vertrouwen toch nog een kans te krijgen. Een groep mensen, waar ik een verkeerd gesprek later nog een keer over kon doen. Waar ik een verkeerde keuze kon en mocht herstellen. Door de fouten, de verkeerde gesprekken, de verkeerde besluiten heb ik het mijn collega's en managers niet altijd makkelijk gemaakt. En dat zijn ze niet vergeten. Dat ben ik ook niet vergeten. Ze vormden een grote bron van verhalen om uit te putten tijdens het afscheid, maar altijd met de bijbehorende boodschap: "Het is goed gekomen!"

De waardering van collega's en managers naar mij toe is ook op een wat onverwachter gebied hoger, dan de waardering voor mijn testwerk. Vaak als waardering werd uitgesproken, werd verwezen naar gesprekken, die ik heb gevoerd. Gesprekken waarin het adviseren, kennis overdragen, aankaarten van problemen of gewoon luisteren centraal stonden. En als het daar niet over ging, ging het over de groei, die ze bij mij gezien hebben. Hoe ik met ups en downs mijn groeipad heb afgelegd en steeds ben doorgegaan.

We leven in een wereld, waar waardering voor elkaar heel belangrijk is. Juist omdat samenwerking bij vormen van Scrum en Agile niet kan zonder waardering voor elkaar. Maar waar het bij samenwerking om gaat, is juist ook verder kijken dan de functie. Waardering hebben voor groei en waardering hebben voor de kans om te groeien. Waardering hebben voor de vorm en inhoud van gevoerde gesprekken. Waardering voor samenwerken in plaats van tegenwerken. Ik merk dat dit vaak mist. Daarom hoop ik, dat deze door mijn ontvangen en gegeven vorm van waardering ook voor anderen tot voorbeeld kan dienen.

De eeuwige uitzondering

De eeuwige uitzondering. Dat zou ik omschrijven als een vrij algemeen probleem. Waarom dan in een testers blog? Als er 1 onderwerp is, waar de eeuwige uitzondering vaak op wordt toegepast, dan is het wel: kwaliteit.

Testen kost tijd. Goed testen kost zeker tijd. Bugs fixen kost tijd. Veel bugs fixen nog meer. Als het om kwaliteit gaat, gaat het dan ook vaak om tijd. En als tester moet je begrijpen, dat soms de tijd ergens anders aan besteed moet worden. Dat de tijd soms niet naar kwaliteit kan gaan. Of dit waar is, is een andere blog. Waar het hier om gaat, is dat deze situatie vaak een eeuwige uitzondering creëert.

Als je namelijk aan een bedrijf of een manager vraagt: "Is kwaliteit voor jullie belangrijk?", zal je niet vaak "Nee" te horen krijgen. Officieel ondersteunen bedrijven en managers altijd initiatieven om de kwaliteit te verbeteren. Een goede kwaliteit zorgt voor een betere klanttevredenheid. Opleveren met minder bugs zorgt voor minder onderhoud. Maar als je zo'n initiatief in de praktijk wil gaan brengen, wil er wel eens iets veranderen. Dan moet je soms begrijpen, dat dit moment niet het juiste moment is. Dat de tijd nu even niet beschikbaar is. Dat de prioriteit nu even anders ligt.

Nu kan deze situatie natuurlijk echt een uitzondering zijn. Dus wat maakt een eeuwige uitzondering? Daarvoor wil ik eerst verwoorden wat ik als een echte uitzondering zie. Een echte uitzondering is gebaseerd op tijdelijke argumenten. Als een collega normaal altijd tijd heeft, maar het even druk heeft, is dit tijdelijk. Als er plotseling een project met een hele snelle deadline komt, terwijl de projecten normaal altijd ruim gepland zijn, is dit tijdelijk. Tijdelijke argumenten zijn argumenten, die op een bepaald moment niet meer geldig zijn. En hiermee bedoel ik niet: het argument is opeens niet meer belangrijk. Nee, hiermee bedoel ik: het argument bestaat niet meer.

Dan is de eeuwige uitzondering waarschijnlijk te raden. Als een collega het al jaren druk heeft, is uitstel om de drukte van deze collega vaak een eeuwige uitzondering. Het argument is morgen, over een week, over een maand en over een jaar nog steeds geldig. Wanneer je daarom op dezelfde manier een beslissing neemt, zal het besluit hetzelfde blijven. Een initiatief tot kwaliteitsverbetering wordt hiermee keer op keer een beetje op de lange baan geschoven.

Waarom dan niet gewoon toegeven: "Dit gaat niet lukken"? Je kan en mag eigenlijk geen besluit definitief nemen dat ingaat tegen een "goed doel". Als je weet dat de kwaliteit beter moet, kan en mag niemand toegeven, dat hier geen tijd voor is. Een bedrijf niet, een manager niet en zeker een medewerker niet. Ook al is hier in de praktijk toch echt geen tijd voor. Tegelijkertijd kunnen de argumenten voor de besluiten om de kwaliteit nu niet te verbeteren, niet zomaar veranderen. Je kan niet zomaar zeggen: "Vanaf nu nemen we geen projecten met krappe deadlines meer aan" of "Vanaf nu heeft deze collega tijd voor je".

Wat maakt de eeuwige uitzondering nou zo gevaarlijk, naast het feit dat problemen blijven bestaan? Hij is heel demotiverend en beschadigd het vertrouwen tussen mensen. Als iemand steeds beweert dat hij/zij kwaliteit belangrijk vindt, maar al je voorstellen tot verbetering steeds opnieuw naar achteren schuift, raak je het vertrouwen in deze persoon kwijt. Hij/zij zegt "Ja", maar doet steeds "Nee". En daarnaast motiveert het niet om nog een keer een voorstel te doen. Het gaat toch niet lukken. Tenslotte staan er als X ideeën in de eeuwige wachtrij.

Een extra probleem is, dat eeuwige uitzonderingen moeilijk bespreekbaar zijn. Omdat officieel het streven is en blijft om kwaliteit te verbeteren, kan je niet zeggen "Dit bedrijf/deze manager/deze collega vindt kwaliteit niet belangrijk". Nee, het is officieel het doel de kwaliteit te verbeteren en dat blijft. En staat daarmee niet ter discussie. De besluiten om het niet nu te doen, worden ook elke keer goed beargumenteerd genomen, met een goede afweging van voor- en nadelen. Dus wat voor argumenten hou je over om dit probleem aan te kaarten?

Kan het niet anders? Natuurlijk wel. Eeuwige uitzonderingen voorkom je door de bereidheid negatieve gevolgen te accepteren en zowel aan lange en korte termijn doelen aandacht te geven. Om met het laatste te beginnen: eeuwige argumenten zijn vaak gericht op korte termijn doelen. Nu een deadline halen, nu de klant tevreden stellen met het opleveren van extra werk, nu extra uren bij een collega voorkomen. Door alleen hier aandacht aan te besteden, zal de situatie niet veranderen. Dus blijven er altijd krappe deadlines, zal de klant altijd om extra werk vragen en blijft de collega het druk houden. Alleen door tijd vrij te maken voor lange termijn oplossingen, kan je dit veranderen. Tijd vrijmaken, om te kijken of het werk van de collega sneller of minder kan. Of misschien dat het werk gedeeltelijk kan worden overgenomen. Tijd vrijmaken om een beter afwegingstraject te maken voor krappe deadlines. Wat zijn de echte kosten? Hoeveel is bijvoorbeeld het kwaliteitsverlies door de krappe deadline in geld uitgedrukt? En soms is het: tijd vrij maken voor een kwaliteitsverbetering in product of proces, waardoor de collega meer tijd over houdt. Of waardoor de krappe deadline opeens haalbaar wordt.Of waardoor de klanttevredenheid toeneemt.

Maar dit heeft nadelen. Als je ergens tijd voor vrijmaakt, dan blijft er ander werk liggen. Wat deadlines in gevaar kan brengen, extra geld vraagt voor extra mensen of klagende klanten geeft, omdat ze minder krijgen. Wanneer je niet bereidt bent deze gevolgen te accepteren, ben je zo weer terug bij de eeuwige uitzondering. Ik heb zo vaak gezien dat de eerste de beste klacht van een collega, klant of manager goede initiatieven weer deed stoppen. Verbeteren heeft nu eenmaal ook nadelen! Waarom je het toch moet doen: als je doorzet zijn de voordelen later groter dan de nadelen nu. En dat zijn ook de enige verbeteringen, die je uit moet voeren. Diegene waar de voordelen op lange termijn groter zijn dan de nadelen op korte termijn.

Een goede lezer heeft door: maar als je dit volgt, zal er niet altijd meteen een kwaliteitsverbetering wordt bereikt. Nee, dat klopt. Soms moet eerst het probleem van te krappe deadlines worden opgelost, voordat er tijd beschikbaar komt voor kwaliteitsverbetering. Het grote verschil? Omdat er nu gewerkt wordt aan een oplossing, is te krappe deadlines wel een tijdelijk argument. Je kan nu zeggen: "Zodra we dit probleem hebben opgelost, komt er tijd beschikbaar voor jouw ideeën." Dit kan zelfs het vertrouwen versterken. Door "Probleem 1" goed op te pakken en net zo lang door te gaan tot het opgelost is, komt er vertrouwen dat, als "Probleem 2" aan de beurt is, dezelfde inzet getoond zal worden. En daarmee de kans op slagen flink toeneemt.

Voorkom eeuwige uitzonderingen. Maar nog belangrijker: herken ze. Besef wanneer de argumenten van nu, later niet veranderen. Tenzij je de problemen, die de argumenten veroorzaken, gaat aanpakken. En besef dat dit niet alleen geld gaat kosten, maar ook andere nadelen oplevert. Accepteer deze, als hierdoor de voordelen op langere termijn groter zijn.

Kwaliteit is belangrijk, ik kan als tester niet anders zeggen. Maar niemand heeft er iets aan als kwaliteit belangrijk is, maar toch nooit belangrijk genoeg om te verbeteren. Als dit kan veranderen, door eerst ergens anders tijd aan te besteden, dan ben ik voor! Mits dit tijdelijk is.

Testdata: Het klinkt simpel, maar wat als het niet zo simpel is?

Je kan zelf geen testdata aanmaken. Je hebt niet de luxe om een database terug te zetten. Je data voor vandaag kan morgen niet meer bruikbaar zijn. Je testdata kan maar 1 keer gebruikt worden en daarna nooit meer. Als je minimaal een van deze situaties herkent, is deze blog interessant voor je.

Testdata management wordt vaak beschreven vanuit de ideale omgeving. Je hebt een database, waarin je de testdata inricht. En vervolgens, elke keer als je de testdata opnieuw wil gebruiken, zet je een kopie van de ingerichte database terug. Daarna kan je al je testdata opnieuw gebruiken. Zelf heb ik nooit gewerkt in een omgeving, waar de testdata zo ideaal was. Zelfs als het mogelijk was een kopie van de database terug te zetten, was testdata in de verloop van tijd niet meer bruikbaar. De testdata lag teveel in het verleden.

Maar goed omgaan met testdata kan onder alle omstandigheden, niet alleen bij het ideaal. Ja, soms is het eenvoudiger, soms moeilijker, maar het is altijd mogelijk om een goed testdata proces te hebben. Mijn belangrijkste criterium: elke testcase moet zeer eenvoudig herhaald kunnen worden, waarbij het herhalen van de testcase hetzelfde testresultaat oplevert. En dit kan alleen met een goede keuze van testdata.

De belangrijkste problemen zijn als volgt samen te vatten:

1. Het is niet mogelijk een database terug te zetten
2. Testdata kan niet aangemaakt worden
3. Testdata heeft een beperkte geldigheid door een tijdsaspect
4. Testdata kan slechts 1 maal gebruikt worden, doordat het te testen proces de data verandert of blokkeert
5. Testdata kan niet aangemaakt worden (2) EN heeft een beperkte geldigheid (3) of bruikbaarheid (4)

Database terugzetten niet mogelijk

In nog heel veel organisaties zijn er geen volledig professionele testomgevingen. Hierdoor is de mogelijkheid om een database terug te zetten soms niet aanwezig. In dit geval is het belangrijkste, om testdata aan te maken of te vinden, die herbruikbaar is. Het meest ideaal is, om je eigen testdata aan te maken. Maar soms kost dit heel veel tijd of heb je de kennis niet om dit te doen. In dit geval kan je ervoor kiezen om bestaande data te gebruiken. Het belangrijkste is echter: leg vast welke testdata je gebruikt voor een testcase. En leg daarnaast vast waarom je deze testdata hebt gekozen. Met dat laatste bedoel ik: aan welk criterium moet de testdata voldoen?

Waarom is het vastleggen zo belangrijk? Een van de belangrijkste nadelen als je geen testdatabase kan terugzetten, is dat iedereen de testdata kan aanpassen. Mocht dit gebeuren en je test faalt daardoor, dan moet je heel simpel kunnen nagaan of je testdata nog klopt. Maar als je niet meer weet, waarom de testdata gekozen was, wordt dit een hele klus. Stel je hebt een relatie uitgekozen, omdat deze in Duitsland is gevestigd. Iemand anders heeft echter een test, waarbij het land gewijzigd moet worden. Dus zonder dat je het weet, is je relatie opeens naar Frankrijk verhuist. Wanneer je je gegevens goed hebt vastgelegd, kan je bij het falen van je test snel nagaan: "Wacht even. De relatie is niet meer in Duitsland, maar in Frankrijk".

Testdata kan niet aangemaakt worden

Meestal gebeurt dit, doordat testdata van een externe leverancier komt. Soms is het een beperking in de te testen applicatie. Maar er zijn situaties, waar je niet alle testdata zelf kan aanmaken. In dat geval ben je verplicht om te kiezen uit bestaande testdata.

In deze situatie is het heel handig zijn om je testcases in heel kleine testcases te schrijven. Combineren kan later. Dus als je moet testen op relaties in verschillende landen, met wel of geen fax en waarvan al wel of geen contracten bekend zijn, maak de testcases klein. Maak geen testcase voor een bepaald land, met faxnummer en contracten. Nee, schrijf alle varianten los van elkaar uit. Maak een lijst met de landen, die je wil testen. Maak een aparte lijst voor wel of geen faxnummer. En nog een lijst met wel of geen contracten. Kies daarna een relatie. En streep alle varianten af, waaraan deze relatie voldoet. Noteer ook bij de relatie aan welke criteria deze voldoet. Kies daarna nog een relatie. Streep opnieuw af. En ga zo door, totdat je alle criteria hebt gedekt.

Testdata beperkte geldigheid of 1 x te gebruiken

Sommige testdata is erg gerelateerd aan een bepaalde periode. Denk hierbij bijvoorbeeld aan aanbiedingen met een uiterste geldigheidsdatum, contracten met een einddatum, dagplanningen of reisaanbod. Voor deze testdata heeft het altijd de voorkeur om zelf de data aan te maken. Als het mogelijk is, creëer je testdata zo, dat deze heel lang te gebruiken is.

Data, die slechts 1 x te gebruiken is, vraagt eigenlijk om dezelfde oplossing. Het meest duidelijke voorbeeld is hierbij factureren. Als een opdracht eenmaal gefactureerd is, is het vaak onmogelijk deze nogmaals te factureren. Ook deze testdata moet daarom bij voorkeur steeds opnieuw aangemaakt worden.

Als het nodig is de data steeds opnieuw aan te maken, is er 1 ding heel belangrijk: leg genoeg informatie vast. Hierbij gaat het om alle gegevens, die nodig zijn om snel invoeren mogelijk te maken. Als het niet uitmaakt welke relatie je kiest, hoef je dit niet vast te leggen. Maar moet de relatie uit Duitsland komen, leg dan vast welke relatie uit Duitsland je hebt gebruikt. Als het niet uitmaakt, welke datum je invoert, hoef je niets vast te leggen. Maar als de datum minimaal een week in de toekomst moet liggen, leg dit dan vast. Leg je testdata en (indien nodig) de criteria zo vast, dat je zonder veel tijd de benodigde testdata opnieuw kan aanmaken. Maar leg niet vast, wat niet uitmaakt. Dat zorgt ervoor dat overtypen alleen nodig is, als dit voor de test nodig is.

Beperkte geldigheid of 1 x te gebruiken, maar geen aanmaken mogelijk

Heel soms kom je in de situatie, waarin je zowel niet kan aanmaken, maar je testdata ook nog eens beperkt geldig is of niet aangemaakt kan worden. Dit is vooral het geval, als je testdata afkomstig is van externe bronnen, waar je geen invloed op hebt, maar je wel te maken hebt met een wisselend assortiment of een geheel te testen proces. Wat doe je dan?

Dit zal altijd een wat langer proces blijven. Wat hier het belangrijkst is: maak het jezelf zo simpel mogelijk. Probeer zoekcriteria vast te leggen, die het vinden van juiste testdata simpeler maken. Als je een zonvakantie zoekt, heb je in Spanje een grotere kans, dan in Noorwegen. Grote klanten hebben vaker een geldig contract, dan kleine klanten. Maar elk domein heeft zijn eigen zoekcriteria.

Leg deze zoekcriteria goed vast. En leg ook vast aan welke eisen je testdata moet voldoen. Probeer deze eisen zo laag mogelijk te houden, zodat het vinden niet te moeilijk is. Door deze combinatie kan je je testtijd flink beperken. Echt snel is en blijft moeilijk. Maar verbeteren kan zo wel.

Waarom testers soms worstelen met Agile of Scrum

Een van de meest onbesproken onderwerpen binnen de testwereld zijn de worstelingen, die testers ondervinden, als ze gaan werken in een Agile of Scrum omgeving. Waar kan je als tester tegenaan lopen? En is dit op te lossen?

Ontwikikelaars
Bij Scrum wordt bijna alleen gesproken over ontwikkelaars. Het Scrumteam bestaat uit ontwikkelaars. Verkeerd vertaalt, houdt dit in dat testers geen of slechts gedeeltelijk deel zijn van het ontwikkelteam. Dit kan verschillende gevolgen hebben. Zo heb ik meegemaakt, dat er met testers geen rekening werd gehouden bij het plannen of bespreken van story's. Ook redenaties, dat in een Scrumteam geen testers nodig zijn, kan ik niet helemaal los zien van deze "Scrum = ontwikkelaars" redenatie.

Voor de duidelijkheid: Een Scrum ontwikkelteam bestaat uit ALLE leden, die bijdragen aan een eindproduct. Het verschil is alleen: binnen Scrum wordt niet gekeken of er een lid is dat kan programmeren, een lid dat kan ontwerpen en een lid dat kan testen. Er wordt gekeken of het team kan programmeren, ontwerpen of testen. Alle leden zijn gelijkwaardig en dienen in alle meetings ook gelijkwaardig behandeld te worden.

Planningspoker
Een veelgebruikte techniek is planningspoker. Hierbij worden story's met elkaar vergeleken op basis van complexiteit. En vaak lijkt de nadruk hier te liggen op de complexiteit van de te bouwen code. Testers kunnen hier zelfs zo van overtuigd zijn, dat ze niet echt meedoen met planningspoker. Ze kopiëren gewoon de waardes van anderen. Want wat kunnen zij nu als testers zeggen over de complexiteit? Of er komt een manier om testen apart te pokeren (eerst alleen code door programmeurs, dan alleen testen door testers), want je kan toch niets zeggen over de andere groep?

De kracht van planningspokeren is het uitwisselen van informatie. Juist door de informatie van twee hele verschillende specialisten (zoals programmeur en tester) bij elkaar te nemen, kan je een goed beeld krijgen van de complexiteit. Een tester kan bijvoorbeeld stilstaan bij de raakvlakken met andere processen, waar de programmeur bijvoorbeeld meer kan aangeven over de complexiteit van de aanpassing in de code. Ook is het zo, dat de complexiteit tussen het testen en het programmeren niet vaak grote verschillen heeft. Als iets 2x zo moeilijk is om te bouwen, is het vaak ook 2x zo moeilijk om te testen. En als laatste argument: een goede programmeur is in staat zijn werk te testen en weet daarom ook hoe complex het testen is. En een goede tester weet in grote lijnen hoe complex code aanpassingen zijn, omdat hij/zij hierbij rekening moet houden met de teststrategie. Ja, als team werkelijk aan planningspoker doen is moeilijk, maar als je het lukt, levert het veel op.

Functionele documentatie
De functionele documentatie wordt steeds vaker teruggebracht. Steeds meer informatie wordt mondeling doorgegeven en besproken. Op zich is daar niets mis mee. Het probleem is alleen, dat deze besprekingen niet altijd met alle betrokken leden zijn. Omdat het vaak de ontwikkelaar is, die het eerst aan het werk gaat, is deze vaak ook de eerste, die gaat overleggen. Met iemand, die antwoorden kan geven, dus niet met de tester. Dat is het meest eenvoudig, snel, enz. Deze informatie wordt vervolgens niet of slecht vastgelegd. En de tester krijgt later de taak om deze informatie alsnog te achterhalen.

Overleggen over de functionele werking moeten bij voorkeur minimaal met de programmeur en de tester gevoerd worden. Als dit niet kan, moet de afwezige direct op de hoogte worden gesteld. Bij voorkeur mondeling, anders schriftelijk. En dit moet gebeuren op een waarneembare manier. Dus niet met een wijziging in een stuk bestaande tekst. Maar met een duidelijke "dit is gewijzigd" mededeling.

Het eind van de sprint
Het meest beruchte deel van Scrum voor testers is misschien wel het eind van de sprint. Met de grote vragen:

• Is het testwerk eerlijk verdeeld over de sprint of is het meeste aan het eind?
• Tot wanneer mag het team in de sprint functionaliteit toevoegen?
• Gaan andere leden van het team mee testen of niet?
• Wat doen de teamleden, die niet mee testen, met de rest van hun tijd?

Als de tester pech heeft, leidt deze fase tot veel werk aan het eind van de sprint, door teveel testwerk. Of door de vele begeleiding, die nodig is om anderen ook te laten testen.

Ik heb mijn voorkeuren, maar waar het hier vooral om gaat, is samenwerken. Als je als tester te maken hebt met anderen, die ook testen, moet je als tester ervoor zorgen, dat je hun testwerk vertrouwd. Dit kan door eenvoudig te testen werk het eerst bij anderen neer te leggen of door via testscripts/testcases alvast het belangrijkste voorbereidingswerk te doen. En heb je zelf veel werk aan het eind, bespreek dan hoe je je hier zo goed mogelijk op kan voorbereiden. Bijvoorbeeld door eerder de informatie te krijgen, die nodig is voor de voorbereiding. Waarmee je tijdens de uitvoering tijd kan besparen.

Samenvatting

Scrum en Agile zijn niet tegen testers, al lijkt dat soms wel. Het grote probleem is dat zowel Scrum als Agile uitgaan van een samenwerking tussen alle teamleden, ongeacht specialiteit, functie of discipline. Ondanks de jaren Scrum en Agile merk je dat deze samenwerking nog te vaak tussen alleen programmeurs of alleen testers is. Ik ben hier verantwoordelijk voor en jij bent daar verantwoordelijk voor. Sommige testers denken zelf nog zo. Anderen werken in een team, waar deze gedachte nog aanwezig is. We moeten leren als team te denken. Dus een probleem van een programmeur, is ook het probleem van een tester. En het probleem van een tester, is ook het probleem van een programmeur. Want alle taken, en daarmee alle problemen, zijn de verantwoordelijkheid van het team als geheel. En niet slechts van 1 persoon. Ik hoop dat iedereen, tester of niet, dat ooit eens zal leren.

Agile testen is testen met openheid, eerlijkheid en respect

Agile testen wordt vaak omschreven als een vorm van testen met testautomatisering, exploritory testing of vermindering van testscripts. Maar voor mij gaat het bij Agile testen niet om de middelen, die je als tester wel of niet gebruikt. Agile testen gaat om de samenwerking. De samenwerking met je team, de samenwerking met je manager, de samenwerking met je klant. Een samenwerking, waarin je als tester open, eerlijk en respectvol wil omgaan met alle betrokkenen. En een samenwerking, waarin je wil dat de betrokkenen zich vrij voelen om open en eerlijk tegen jou te zijn.

Wat houdt open, eerlijk en respectvol in voor een tester? Als tester ben je vaak de enige in een Agile team. Het is daarom van belang dat jen binnen je team open en eerlijk leert praten over de problemen en obstakels, waar je als tester tegenaan loopt. Deze zijn namelijk regelmatig voor je andere teamleden onbekend. Je moet leren om te verwoorden, waarom iets belangrijk voor je is.

Bij het maken van bevindingen moet je respectvol met je teamleden omgaan. Het is je doel om als tester de fouten van het team te vinden. Maar de communicatie hierover, moet niet verwijtend overkomen. Als basis moet je een vorm van communicatie kiezen, die ervan uitgaat dat je teamleden goed werk willen opleveren en fouten niet expres maken.

Agile is erg klantgericht. En dat moet Agile testen ook zijn. Het moet als Agile tester je doel zijn om te testen of er een product gebouwd is, waar de klant blij van wordt. En als je werkelijk een goede Agile tester wil zijn, begin je hier al mee bij de eerste bespreking van de wijziging, vaak al voor de bouw begint. Is dit echt wat de klant wil? Hebben we de klant goed begrepen? Als we dit bouwen, heeft dit nadelen voor de klant? Of misschien voor andere klanten?

En als laatste je manager. Hoewel vaak weggelaten in Agile verhalen, weet ik ondertussen dat de manager een van de belangrijkste factoren is in het falen of slagen van een Agile team. Een manager heeft binnen Agile de moeilijke taak om een evenwicht te vinden tussen het team loslaten en het team sturen. Uit ervaring weet ik, dat als je een team teveel loslaat, er zeker in het begin al vrij snel weinig Agile meer over is. Bij tegenvallers valt een team regelmatig terug op het oude bekende. De oude manier van plannen, de oude manier van overleggen, de oude manier van samenwerken. Maar bij teveel sturing, krijg je net zo min een Agile team. Je krijgt een team, dat in naam zelfstandig beslissingen kan nemen, maar in de praktijk doet wat de manager zegt.

Aan dit goede evenwicht kan je bijdragen door met je manager open en eerlijk te communiceren. Zorg ervoor dat je manager op de hoogte is van de belangrijkste problemen rond testen in het team. En het kan vaak ook verstandig zijn hem of haar op de hoogte te brengen van je plan van aanpak om die problemen op te lossen. Maar besef ook, dat je manager soms doelen heeft, die boven een team uitgaan. Zelfs in een Agile team kan een manager je dwingen tot een taak, een handeling, een tool, waar je zelf niet achterstaat. Dat is het moment om ook richting je manager respectvol te blijven. Je kan wel degelijk open en eerlijk vertellen, waarom jij dit eigenlijk niet wil. Maar toon wel respect voor datgene wat je manager wil bereiken. Misschien weet je zelfs wel een alternatief.

Als je dit leest kan openheid, eerlijkheid en respect heel eenvoudig lijken. Maar ik ken genoeg mensen, die open en eerlijk zijn, maar vaak respectloos omgaan met mensen. Hun open en eerlijke opmerkingen kwetsen mensen en schaden daarmee het vertrouwen. En daartegenover zijn er mensen, die proberen altijd respectvol te zijn. Maar zich daarom niet meer vrij voelen open en eerlijk te communiceren. Zeker als tester, met een uitzonderingsrol in het team en de taak om fouten te vinden, is dit evenwicht soms moeilijker dan je zou denken. Kort geleden ging ik zelf de mist in, door iemand in mijn team respectloos te behandelen. Maar weet je wat het heerlijke is van deze drie? Als je iemand respectloos hebt behandelt, kan je dit vaak oplossen door over de oorzaak hiervan open en eerlijk te zijn. En als blijkt dat je niet open en eerlijk genoeg bent geweest, kan je veel ergernis wegnemen, door respectvol te luisteren.

Het belangrijkste voordeel: openheid, eerlijkheid en respect kan je niet echt goed bij jezelf meten. Het is hoe anderen tegen je aankijken. Agile, en daarmee Agile testen, draait om het team en om samenwerking. En is naar mijn mening dan ook beter meetbaar in een beoordeling, die door het team of door alle betrokkenen gegeven moet worden. Niet in zaken, die (hoe belangrijk misschien ook) uiteindelijk niets te maken hebben met communicatie of groei. Alleen maar met "anders werken". En "anders werken" is niet automatisch "Agile werken".

Agile testen draait natuurlijk ook om kwaliteit. Maar als je respectvol omgaat met je klant, met je manager en met je team, kan je niet anders dan de kwaliteit goed bewaken. Je klant en je manager willen een kwalitatief goed product. En je team en je manager wil een kwalitatief goed proces. En met openheid, eerlijkheid en respect kan je binnen het team de kwaliteit bewaken, het proces bewaken, maar ook jezelf bewaken. Zodat anderen van hun fouten kunnen leren, maar jij ook.

Agile is geen toestemming voor het opleveren van onbruikbaar materiaal

Agile en Scrum zijn gericht op het snel krijgen van feedback door klanten. Met o.a. het idee dat, als je iets bouwt wat de klant niet wil, je hier in een veel vroeger stadium achter kan komen. Dat klopt. Maar als je in de situatie terecht komt, dat je een tafel hebt gebouwd, terwijl je klant een stoel wil, is het niet slim om te zeggen: "Daarom werken we Agile". En vervolgens door te gaan alsof er niets gebeurd is. Nou OK, je bouwt alsnog de stoel, maar meer is niet nodig. Want je werkt Agile en dan hoort dit er gewoon bij.

Naast het vroeg ontdekken van problemen, zijn zowel Agile als Scrum ook bedoeld om van je fouten te leren. Zie het als een bewaking tegen inbraak. Je beveiligt je huis en als onderdeel installeer je een inbraakalarm. Vervolgens wordt er, ondanks al je maatregelen, toch ingebroken. Dan ben je blij dat je je inbraakalarm hebt, als hierdoor je inbreker uiteindelijk veel minder steelt. Maar ondanks dat je inbraakalarm zijn doel perfect heeft bereikt, ga je toch kijken hoe de dief binnen is gekomen. Is dat door het kelderraam? Dan beveilig je dat raam ook.

Zowel Agile als Scrum hebben delen, die gericht zijn op het in een vroeg stadium ontdekken van problemen. Net als bij een inbraakalarm kan de schade van het probleem hierdoor ingeperkt worden. Maar er is wel een probleem. En dat probleem moet opgelost worden. Het moet je doel zijn om dat inbraakalarm nooit meer nodig te hebben. En zo moet het ook je doel zijn om te begrijpen wat je klant wil, voor je ook maar op enige manier start met development.

Agile, Scrum, handmatig testen, automatisch testen, documenten reviews, demo's aan de klant: het zijn allemaal middelen, die je kunnen helpen om er in een zo vroeg mogelijk stadium achter te komen, dat je product niet geschikt is om aan de klant op te leveren. Maar het allerbelangrijkste is om deze momenten vooral te beschouwen als leermomenten. Momenten om te leren hoe je je proces of je communicatie zo aan kunt passen, dat problemen niet nog een keer gebeuren. Een huis vol met de juiste alarmen, kan je zeker (en terecht) een veiliger gevoel geven. Maar als je een inbraak kan voorkomen met een extra slot op het kelderraam, blijft dat extra slot altijd een terecht streven. Voorkomen is en blijft beter dan genezen. Ook als je werkt volgens Agile en/of Scrum.

Testen in het grote onbekende

De kennis van de applicatie is te vaak niet aanwezig. Wat wel bekend is: het is ingewikkeld. Een voordeel: je test slechts wijzigingen. Bijbehorende nadeel: veel ontwikkelaars kennen ook slechts de wijzigingen. Maar hoe test je berekeningen, processen, imports, enz., als je slechts de wijziging kent?

Het allerbelangrijkste in deze situatie: voer je testen twee keer uit. Normaal bereid je je testen voor en zodra de ontwikkelaar klaar is, voer je ze uit. In deze situatie voer je ze twee keer uit. Een keer voordat de wijziging is opgeleverd. Een keer nadat de wijziging is opgeleverd.

Waarom twee keer? De eerste keer kan je zien als de basismeting. Zodra je weet hoe de applicatie nu werkt en je weet wat er gaan wijzigen, kan je voorspellen hoe de applicatie na de wijziging gaat werken. Bijvoorbeeld als er 20% van het totaalbedrag afgehaald moet worden, kan je van tevoren nagaan wat het totaal bedrag is voor de wijziging. En vervolgens moet het totaalbedrag na de wijziging 20% lager zijn. Als er via een import een persoon moet worden aangemaakt, kan je de gegevens handmatig invoeren en het eindresultaat vastleggen. Tenslotte zal in veel gevallen het resultaat gelijk moeten zijn.

Daarnaast heeft dit nog een ander voordeel: de snelheid. Als je voor de oplevering van de wijziging al precies weet wat de wijziging is, welke gegevens ingevoerd moeten (maar vooral ook kunnen) worden, en wat het eindresultaat moet zijn, kan je zeer snel testen. De kans op onverwachte invoerproblemen of op extra vragen is een stuk kleiner. En hierdoor is de testuitvoering opeens een stuk sneller.

Deze manier van testen is even wennen. Je voorbereiding voelt zeker minder Agile aan, vooral omdat het vraagt om meer documentatie. Maar wat je behoudt is je flexibiliteit. Je bent in staat te testen, ongeacht kennisproblemen. En als het moet, kan je snel testen. En nog een extra: problemen komen eerder naar voren, waardoor je meer tijd hebt om ze op te lossen. Grootste obstakel: jij en je team. De bereidheid te testen op een manier, die werkt. En niet op een manier volgens het boekje.

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.

Is waterval testen de redding van Scrum?

Waterval testen, oftewel eerst testen voorbereiden en vastleggen en veel later uitvoeren, hoort niet bij Scrum of Agile. Toch doe ik het. En vele testcollega's met me. Ik moet wel. We moeten wel. Het is de enige manier waarop we in een Scrum omgeving enige garantie op kwaliteit kunnen geven. Hoe is dit gekomen? Waar is het misgegaan? Of is er wel iets mis gegaan? Omdat deze blog niet alleen door ervaren testers gelezen wordt, eerst wat waterval testen informatie. De testvoorbereiding en testuitvoering is ontstaan in een manier van werken, waarbij ontwikkelaars weken of maanden achter elkaar programmeerden. Nadat een product "af" was, werd het op een testomgeving gezet. En daarna was het voor de ontwikkelaars wachten op feedback van de testers. Met een duidelijk verzoek: geef ons deze feedback zo snel mogelijk. Om dit voor elkaar te krijgen, is de testvoorbereiding ontstaan. Van tevoren werd nagegaan welke knoppen geklikt moesten worden, welke velden ingevoerd moesten worden en welke waardes hierin moesten staan. En wat hiervan het eindresultaat moest zijn. Dit werd allemaal vastgelegd in een zeer gedetailleerd testscript. Tijdens de testuitvoering had je hierdoor geen voorbereiding meer nodig. Een extra voordeel was, dat het script zo uitgebreid was, dat werkelijk iedereen het uit kon voeren, zelfs als je totaal geen kennis had. Gewoon doen wat er staat en kijken of je ziet wat er staat. Met als einddoel: heel veel tijd steken in de testvoorbereiding, zodat de testuitvoering snel kan worden uitgevoerd. Toen kwam er een behoefte aan kortere opleverperiodes. Om het bij Scrum termen te houden: sprints. Vaak opleveren, zodat de klant eerder resultaat ziet en hierdoor ook beter en eerder bij kan sturen. Maar er was een groot nadeel: de huidige manier van testen was hier niet geschikt voor. De sprints waren te kort om zulke lange testvoorbereiding uit te voeren. Niet voor niets werd bijna tegelijkertijd een streven ingevoerd naar veel minder documentatie. De oplossing: testen zonder testvoorbereiding. De testuitvoering werd misschien wel langer. Maar doordat veel meer tijd werd bespaart door het weglaten van de testvoorbereiding, was de totale testtijd veel korter. En een kortere totale testtijd paste veel beter in de nieuwe flink kortere sprints. Maar wat gebeurde er? Te vaak werden de sprints alsnog kleine watervallen. De ontwikkelaars namen een groot deel van de sprint om 1 story te bouwen. Met als gevolg dat vlak voor het einde van de sprint het meeste werk pas opgeleverd werd naar de testomgeving. De wens "Geef ons zo snel mogelijk feedback" werd alleen maar sterker. Tenslotte moest het werk nu niet over 2 maanden, maar over 2 dagen afgerond zijn. Dus om enige kans te hebben de sprint te halen, moest de testuitvoering razendsnel. Een razendsnelle testuitvoering was en is niet mogelijk zonder testvoorbereiding. Dus grijp ik, en vele andere testers met mij, terug naar de testvoorbereiding en het testscript. En maken we de langere testdoorlooptijd maar zo passend mogelijk. Hoe het zou moeten werken? Binnen een goed ingedeelde sprint wordt door de sprint verspreid regelmatig werk opgeleverd. Terwijl de tester dit werk test, ontwikkelt de ontwikkelaar het volgende werk. De tester heeft zo een zeer regelmatig aangeboden hoeveelheid werk. Aan het eind van de sprint is er vervolgens niet opeens een grote hoeveelheid. Nee, er is een behapbare hoeveelheid werk, dat makkelijk in de laatste dagen van een sprint getest kan worden. Zo kom je op een van de grootste struikelblokken van Scrum: het kleiner maken van story's. Om dit voor elkaar te krijgen, moeten grote story's, met de grootte van (bijna) een sprint, kleiner gemaakt worden. In de eerste plaats zijn hier vaardigheden voor nodig, waar de gemiddelde ontwikkelaar niet over beschikt. In de tweede plaats staat ook een ontwikkelaar vaak onder druk. Als Scrum niet goed loopt, zijn er vaak managers, scrum masters, enz. die zeggen dat er meer werk sneller moet worden opgeleverd. De snelste manier van opleveren voor een ontwikkelaar is heel simpel: geef hem een grote klus en wacht tot die klaar is. Dit is volledig in tegenspraak met het opsplitsen van story's. Het opsplitsen van story's zorgt ervoor dat de ontwikkelaar minder snel ontwikkelt, meer tijd kwijt is en zelfs dubbel werk oplevert. De ontwikkelaar gaat dus trager werken en minder opleveren. Waarom je het dan toch moet doen? Omdat het team sneller en beter gaat werken. Omdat het team naast elkaar kan gaan werken en niet op elkaar hoeft te wachten. Nee, waterval testen is niet de redding van Scrum. Het streven om hiervan los te komen is volledig terecht. Maar waterval testen is een waardevolle reddingsboei in het woelige water dat men Scrum noemt, maar niet Scrum is. Zolang de snelheid van een individu nog blijft gaan boven de snelheid van het team.

Agile testen is meer dan stories testen

Bij Agile testen staan stories (al of niet user-stories) vaak centraal. En dat is terecht. Het is en blijft het doel om te controleren of gemaakte wijzigingen goed doorgevoerd worden. Maar Agile testen is meer. Er is al de discussie over testen v.s. toetsen. Niet alleen specificaties controleren, maar als tester ook verder kijken. Toch zie je dat veel tester binnen Agile nog een stap verder gaan. Ze gaan niet voor goed gebouwde wijzigingen. Ze gaan voor kwaliteit. En dat is een trend waar ik me graag bij aansluit. Naar mijn mening wil een goede Agile tester niet alleen goed testen. Een goede Agile tester wil kennis opbouwen. En voornamelijk op twee gebieden. Het eerste meest logische gebied is de testtools. Om de kwaliteit te bewaken, en soms om het testproces ook in kwaliteit te verbeteren, wil een Agile tester het beste uit zijn of haar tools halen. Het leren van de tools en het experimenteren met tools is iets wat elke Agile tester als streven moet hebben. Hierbij gaat het niet alleen om automatisch testen, maar ook om bijvoorbeeld tools rond testomgevingen en bevindingenregistratiesystemen. En ja, de realiteit slaat soms toe. Je kan niet alles leren. Soms moet je vertrouwen op de kennis van anderen. Maar de wil moet aanwezig zijn. Het tweede gebied is eigenlijk heel logisch, maar komt vaak niet het eerste op. Een goede Agile tester moet domeinkennis en softwarekennis opbouwen. Een Agile tester mag niet alleen afhankelijk zijn van de input van de storyschrijver om goed te kunnen testen. Op basis van eigen kennis (al of niet vastgelegd in documentatie) moet hij/zij kunnen bepalen of er geen paden, varianten, schermen, enz. vergeten zijn. Kennis over hoe de software werkt, welke gegevens vaak gebruikt worden, welke schermen vaak gebruikt worden, welke schermen op elkaar lijken, welke schermen dezelfde gegevens gebruiken, enz. Maar ook weten wat veel voorkomende opdrachten zijn binnen het domein. Wat voor facturen worden vaak gestuurd en wat voor facturen minder. Wat voor klanten zijn er? Zijn deze in duidelijke groepen in te delen? Wat zijn de grootste klanten? Deze informatie kan gebruikt worden om tot goede testdata te komen. Testdata, die lijken op de praktijk en daarmee een goed beeld geven van de kwaliteit. Daarnaast is te merken, dat veel testers deze kennis al gaan gebruiken bij de backlog refinement, waardoor ook bijvoorbeeld developers en storyschrijvers ervan kunnen profiteren. Scrum en Agile streven beiden niet naar goed opgeleverde wijzigingen, maar naar een kwalitatief opgeleverd product. Om dit te bereiken streven beiden naar verbetering in proces. Hoewel specialiteiten niet ontkent worden, wordt vooral de onderlinge samenwerking (ongeacht functie) centraal gesteld. Een goede Agile tester gaat hierin mee door niet alleen te kijken naar kwaliteitsbewaking op korte termijn (testen en toetsen), maar op lange termijn (tools en processen). En door zijn/haar kennis uit te breiden en later in te zetten om zowel de inhoud van de story als de uitwerking in code en testuitwerking beter te krijgen.

Testverbetering als 1 organisatie

Stel je werkt voor een bedrijf met meer dan 1 ontwikkelteam. En elk team test anders. Andere tools, andere processen. Je organisatie wil dat veranderen. Allemaal dezelfde tools, allemaal een zelfde manier van werken. En jij krijgt de opdracht dit voor het testen als geheel of voor een testonderwerp te regelen. Hoe pak je dit aan? Maar vooral: hoe pak je dit niet aan? Om dit goed aan te pakken, wil ik eerst een vooroordeel de wereld uit helpen. Bedrijven willen vaak gezien worden als 1 organisatie en niet als een organisatie, bestaande uit verschillende teams. De veel gevolgde manier om dit te bereiken is gelijktrekken van tools, processen en taalgebruik. Er is niets mis met gelijktrekken van tools, processen en taalgebruik. Dit kan zorgen voor betere samenwerking tussen teams, meer vrijheid in het indelen van teams, kostenbesparing en een algehele verbetering in efficiëntie, effectiviteit en kwaliteit. Maar wat het niet doet, is losse teams omvormen tot 1 organisatie. Helaas is dit wel een voorwaarde om het gelijktrekken te bereiken. Je kan iemand dwingen een proces te volgen en zolang je dat tot in detail controleert, zullen ze het volhouden. Maar als ze er zelf niet achterstaan, zelf niet in geloven, dan zal dit veranderen zodra jij deze tijd niet meer kan vrijmaken. Bij het eerste de beste obstakel zal gezegd worden "We zeiden het toch: Dit werkt niet bij ons". 1 organisatie is niet een organisatie, die hetzelfde werkt. 1 organisatie is een organisatie, die hetzelfde wil werken. Hoe bereik je dit? Om dit duidelijk te maken, zal ik gebruik maken van een onderwerp waar ik zelf veel kennis van heb, vooral van het invoeren: testautomatisering. Stel je organisatie heeft 10 teams. Nu heb jij de opdracht om testautomatisering in alle teams in te voeren. Een veel gevolgde aanpak: pak het probleem per team aan. Doe eerst team 1, dan team 2, dan team 3. Deze aanpak verkleint je kans op slagen enorm, als dit ook inhoudt dat alle andere teams geen enkele betrokkenheid hebben bij de testautomatisering, totdat zij aan de beurt zijn. Ik weet niet of jij ooit iemand heb gesproken, die jou precies verteld hoe je moet gaan werken en wat je moet veranderen, terwijl die persoon nog nooit eerder enige interesse in jou of je team heeft getoond. In de meeste gevallen is dan de eerste reactie: "Wie denk je wel niet dat je bent?". Wat zich later vertaalt in "Dit gaat voor ons niet werken, want wij zijn anders.". Het is belangrijk dat elk team vanaf het begin betrokken wordt bij de verbetering. Daarom is het in de "ontwerp" fase van belang dat elk team zijn input kan geven en dat deze input ook zichtbaar is in het eindresultaat. De "ontwerp" fase is de fase waar bepaalt wordt in welke stappen de verbetering ingevoerd wordt, maar ook met welke tools gebruikt gaan worden en welke processen gaan veranderen. Zorg ervoor dat elk team de gelegenheid heeft de volgende vraag te beantwoorden "Gaat dit werken voor mijn team?". En als het antwoord is: "Nee, want...", neem die problemen serieus. Neem die problemen op in je plan. Noem ze minimaal als risico. Maar als het mogelijk is: geef aan hoe je het probleem op wil lossen. Dan komt het invoeren. Hoewel de neiging groot zal zijn om je te richten op 1 team, is dit niet verstandig. De verbetering wordt voor de andere teams dan "een verhaal van een andere wereld". Tegen de tijd dat een ander team aan de beurt is, ben je de bij de "ontwerp" fase gecreëerde betrokkenheid en draagvlak alweer kwijt. Het is zeker niet erg om 1 team de meeste tijd te geven, maar vergeet de andere teams niet. Zorg ervoor dat er bij elk team gewerkt wordt aan een obstakel, dat de verbetering in de weg staat. Dit zal ik aan de hand van de testautomatisering wat duidelijker maken. Testautomatisering is meer dan starten met het maken van automatische testen. Maar dit is vaak wel de grootste klus, waar mensen veel hulp en ondersteuning bij nodig hebben. Maar er moet ook een goede, stabiele testomgeving zijn. Men moet in staat zijn goede regressietesten te schrijven. De testdata moet op orde zijn. Gevonden bugs moeten snel opgelost worden. Bevindingen moeten goed en snel worden geanalyseerd en beschreven worden.Enz. Enz. Enz. Veel van deze verbeteringen zijn ook verbeteringen, die handmatig testen ten goede komen. Maar ze vragen zeker niet allemaal evenveel tijd en begeleiding. Zorg ervoor dat elk team bezig is met een verbetering, die nodig is voor een goede testautomatisering. Om ervoor te zorgen, dat dit je niet veel tijd kost, kan je de teams zelf laten kiezen welke verbetering voor hun het belangrijkste is. Als zij mogen werken aan de verbetering, waarin zij de meeste resultaten zien, zal er nauwelijks controle nodig zijn. De motivatie om door te zetten zal bijna automatisch aanwezig zijn. Je hoeft er alleen voor te zorgen, dat je beschikbaar bent voor problemen, waar de teams zelf niet uitkomen. Bijvoorbeeld omdat ze de kennis nog niet hebben of omdat ze geld, tijd of mensen nodig hebben. En als laatste de communicatie. Goede communicatie over verbeteringen is belangrijk. Als je meetings houdt of informatie rond stuurt, houdt je dan altijd aan de volgende regels: * Zorg ervoor dat je van elk team een succes noemt * Zorg ervoor dat je voor elk team de veranderingen op korte termijn voor dat betreffende team noemt Dit geeft het laatste steuntje in de rug. Je laat merken, dat je niet alleen met mensen praat, maar dat je ook echt naar ze luistert. Dat wat zij vinden belangrijk voor je is. En dat wat er met ze gebeurt belangrijk voor je is. Dat jij ze deel vindt van die ene organisatie. Testverbetering door verschillende teams heen bereik je door alle teams bij de testverbetering te betrekken. Door ze te betrekken bij het opstellen van het plan over de testverbetering. Door ze in een vroeg stadium te laten meewerken in de testverbetering. En door te laten merken, dat ze belangrijk voor je zijn. Hun kennis telt, hun mening telt en zij tellen zelf zeker ook!

De wereld van complimenten en de gevaren hiervan

Een tijd geleden maakte ik een persoon mee, die complimenten promootte. Maar op een manier waarop ik totaal niet achterstond. Nu ben je als tester snel aan het oordelen, omdat je bepaalt wat goed en fout is. En daarmee ook indirect kan zeggen of suggereren wie zijn werk goed en wie zijn werk niet goed doet. Weten hoe de wereld van complimenten en de wereld van kritiek werkt, vind ik daarom een belangrijk onderwerp voor testers.

De wereld van kritiek is vaak besproken, maar naar aanleiding van deze ervaring kwam ik tot de vraag: hoe steekt de wereld van de complimenten in elkaar? Wat maakte deze promotor van complimenten in mijn ogen nou zo verkeerd? Ik ben zeker niet tegen complimenten. Maar wat mij tegenstond, was de sfeer, die eromheen ontstond. Het idee was om voor een bepaalde periode je alleen maar te concentreren op complimenten. Even geen kritiek op elkaar of op jezelf, maar kijken naar het positieve.

Klinkt misschien goed, maar ik zag ongewenste bijeffecten. Want ik zag twee dingen gebeuren. Ten eerste is ook complimenten geven iets wat je moet oefenen. Daarom is het verstandig om niet meteen te vragen wat iemand fantastisch, perfect, ideaal, uitstekend o.i.d. heeft gedaan. Nee, vraag gewoon wat iemand goed heeft gedaan. Dat maakt het veel makkelijker een compliment te geven. Het kan dan ook iets kleins zijn. En het hoeft niet eens perfect gegaan te zijn. Puur het feit dat iemand zijn best deed, is dan al voldoende. Dat maakt het zowel voor de gever van het compliment makkelijker te geven, als voor de ontvanger makkelijker om te ontvangen. De eisen en verwachtingen liggen niet zo hoog. Tijdens het beschreven evenement werden te vaak de varianten op "ontzettend goed" gebruikt. En ik zag dat als een blokkerende factor voor mensen, die complimenten geven en complimenten ontvangen toch al niet vaak doen.

 En daarmee maak ik meteen een sprong naar mijn tweede probleem. Het was niet mogelijk om hier opmerkingen op te maken. Hier opmerkingen op maken, was tenslotte geen complimenten geven. Puur de opmerking, dat ik niet achter de opzet stond, leek al bijna te suggereren, dat ik niet achter complimenten geven stond. En, jammer genoeg niet tot mijn verbazing, is het voorstanders van complimenten wel bijna altijd toegestaan om scherpe kritiek te geven op personen, die complimenten lijken tegen te werken. Terechte opmerkingen, die op dat moment hadden kunnen leiden tot verbeteringen en daarmee tot meer complimenten, waren niet welkom. Ik heb niets tegen personen, die complimenten promoten. Wel tegen personen, die dit als reden gebruik om niet te luisteren naar anderen en direct over te gaan op zelf kritiek leveren. Dat die kritiek is tegen het hebben van kritiek, maakt het in mijn ogen geen betere kritiek.

Mijn eigen ervaringen in de wereld van complimenten zijn natuurlijk vooral gebaseerd op mijn ervaringen als tester. En het eerste wat je moet beseffen is: wat een compliment is voor de een, kan kritiek zijn voor de ander. Als ik trots vertel, tijdens het testen in korte tijd heel veel fouten zijn gevonden, suggereer ik tegelijkertijd dat minimaal 1 ontwikkelaar zeer waarschijnlijk heel slecht werk heeft opgeleverd. Een ander voorbeeld: Als een ontwikkelaar trots vertelt, dat hij echt de tijd heeft genomen om goed te programmeren, kan dat mij eraan herinneren, dat er juist hierdoor te weinig tijd is overgebleven om goed te testen. Zo kan ook de opmerking, dat je als tester weinig tot geen fouten hebt gevonden, bij ontwikkelaars tot de conclusie leiden, dat je als tester je werk slecht doet. Want een vorige tester, andere tester of klant vond tenslotte wel fouten.

Waar het op neer komt: verplaats je in de ander en probeer te beseffen hoe die naar de situatie kijkt. Is de ander ook zo blij met de situatie als jij? Wat kan helpen verkeerde conclusies te voorkomen, is om een vergelijking of de oorzaak in je compliment op te nemen. Er zijn meer fouten gevonden, omdat er een nieuwe testtechniek is toegepast. De ontwikkelaar heeft meer tijd genomen, omdat de vorige keer zoveel fouten waren gevonden. En je hebt, vergeleken bij het vorige opgeleverde werk, veel minder fouten gevonden, dus de kwaliteit van het werk is verbeterd. Door de vergelijking en/of door de genoemde oorzaak is het moeilijker voor de toehoorder eigen conclusies te trekken.

Daarnaast vind ik het volgende heel belangrijk: leer complimenten geven op het geven van kritiek, ongeacht de vorm. Complimenten geven is heel belangrijk, maar je hebt kritiek nodig om te groeien. En daarmee heb je mensen nodig, die altijd bereid zijn je te vertellen wat er fout gaat. Dit zijn niet altijd de mensen met het meest subtiele woordgebruik. Maar als je werkelijk wilt leren complimenten te geven, moet je leren verschil te zien tussen het gewenste doel en het werkelijk bereikte doel. Deze kritiek, hoe slecht ook gebracht, wordt bijna altijd gebracht met het doel iemand iets te leren. Om iemand de ogen te openen voor het onbekende, niet geziene. Door meespelende emoties, teleurstellingen uit het verleden of vele andere oorzaken wordt hiervoor wel vaak de botte hamer, of in dit geval de botte woorden, toegepast. Maar bot zijn is niet het doel, bot zijn is op zijn hoogst een verkeerd gekozen middel en soms zelfs een ongewenst bijeffect. Als je hier onderscheid in kan maken, kan je iemand complimenteren voor het willen verbeteren van de situatie. En dan ben je in staat om werkelijk iedereen, optimist of pessimist, zodra je dat wil te bedelven onder complimenten. 

En dan heb je nog de "Maar dat is toch niet zo bijzonder?" complimenten. Kort geleden kreeg ik zelf een compliment voor het vinden van een probleem. De standaard waarden in een scherm leverde verderop in het proces een ongewenste situatie op. Het werd knap gevonden, dat ik dat had gevonden. Maar voor mij was het meer "Hoe had ik die nou ooit kunnen missen?". Ik wijzigde niets, ging door met het proces en zag een hele duidelijke ongewenste situatie. Het compliment was oprecht. Toch klopte het in mijn ogen niet. Ik had niets bijzonders gedaan. Ik had gedaan, wat ik altijd doe, wat ik zelfs al jaren doe.

Waarom het toch een terecht compliment was: als het echt zo simpel was, waarom was dit probleem nog nooit eerder door een tester gemeld? Waar je werkelijk goed in ben, zie je vaak zelf niet meer als een prestatie. Het hoort bij de dagelijkse gang van zaken, het normale. Je zou niet anders kunnen. Maar als het iets is, wat anderen niet doen of wat anderen niet kunnen, is het wel degelijk een compliment waard. Dat moet je als ontvanger leren zien. En als gever leren beschrijven. Waarom is dit voor jou wel zo bijzonder, dat het een compliment waard is?

Complimenten geven vraagt erom je te verplaatsen in een ander. Hoe kijkt de ander naar de situatie? Maar het vraagt ook om een goede onderbouwing: waarom is dit zo goed? Trek ook vooral niet te snel de conclusie dat de anderen slecht is in het geven of ontvangen van complimenten. Doe gerust eens een poging te achterhalen waarom het compliment niet overkomt of zelfs het omgekeerde effect heeft. En zeker nooit vergeten: gebruik jouw streven naar complimenten nooit als toestemming om kritiek te hebben op anderen.