Het verschil tussen een incident en een probleem

Dan kom je plotseling in een situatie. De fouten nemen toe en je hebt geen idee waarom. Je wilt als tester natuurlijk kwaliteit. Dus je wil er wat aan doen. Maar hoe? Want als je rondvraagt, is er geen duidelijke oorzaak. Er zijn incidenten, zeker. Zaken die is een keer fout gaan. Een Opslaan knop die een keer niet werkt. Typefouten in een ander scherm. Allemaal zaken die kunnen gebeuren. Maar wanneer wordt een incident nu werkelijk een probleem dat aangepakt moet worden? Hoe herken je dat? Wanneer is het te vroeg om aan de bel te hangen en wanneer te laat?

Voor mij ligt de magische grens bij 3 keer. Twee opleveringen achter elkaar met meer fouten dan anders, dat kan. Drie opleveringen met meer fouten dan anders, dat kan bijna geen toeval meer zijn. Het kan nog steeds, natuurlijk. Maar de kans is zo klein, dat dit een onderzoek waard is. De grootste fout die Agile teams maken, is het geloof dat het de volgende keer beter gaat. Na de eerste keer, na de tweede keer, na de derde, vierde, vijfde, zesde, zevende keer. Elke keer is de laatste keer, want elke keer had zijn eigen unieke redenen waarom het fout ging. Maak als tester niet dezelfde fout en bepaal voor jezelf een grens. Dit hoeft geen 3 te zijn, maar ga niet al te hoog.

Maak het meetbaar

Probeer voor jezelf als tester ook een kwaliteitscriterium te ontwikkelen. Bijvoorbeeld 3 bugs per storypoint of 10 bugs per story. Makkelijk te meten criteria. Als je ze niet weet, tel dan gewoon een keer hoeveel bugs je binnen een sprint hebt per story, per storypoint of een soortgelijke eenheid. En kies op basis hiervan een meetlat die goed voelt. Rond hierbij de eerste keer ruim naar boven af. Je kan hem altijd bijstellen. Maar zorg er in ieder geval voor dat je kan beoordelen of de kwaliteit van het opgeleverde werk slechter was, dan het team kan leveren.

Stel je criterium ook bij. Wanneer je team beter gaat functioneren, zal het aantal bugs ook afnemen. Stel je hebt 10 bugs per story en je team haalt al drie sprints achter elkaar max. 7 bugs per story. Stel je criterium dan bij naar 8 bugs. Slechte kwaliteit kan in de loop van de tijd veranderen. Maar stel je grens bij voorkeur niet naar boven bij. Zelfs als je de oorzaak niet aan kan pakken, zoals bijvoorbeeld een deadline, is het goed om een middel te hebben om de gevolgen vast te leggen.

En analyseer

Maar dan heb je je kwaliteitsmeetlat. En deze is drie keer overschreven. Wat dan? Vaak is er wel degelijk een oorzaak. Als je maar door de incidenten heen wilt kijken. Als je, ondanks de bomen, toch het bos wil zien.  Plan dan een uur in na een bepaalde sprint of andere logische periode en ga rekenen. Ga per oorzaak tellen en kijk waar er een duidelijke piek is in bugs.

Kijk eerst naar de volgende drie oorzaken

De ontwikkelaar kon de bug niet zelf vinden, omdat de test die hiervoor nodig was door hem niet uitgevoerd kon worden
Denk hierbij aan een interface, die voor de ontwikkelaar niet op te roepen is. Een testomgeving, die niet beschikbaar is. Een testdatabase, die niet voldoende of representatieve data bevat voor een goede test. Alles waardoor een ontwikkelaar terecht kan zeggen: "Ik kan dit niet testen". Deel deze groep niet op, zodat je losse incidenten krijgt. Dus de ene keer was de testomgeving een week niet beschikbaar, een andere keer was een interface in onderhoud. Dit valt allemaal onder testomgeving management. En als daar een probleem is, keert dit in verschillende manieren terug. Maar het is hetzelfde hoofdprobleem.

De ontwikkelaar test niet goed
Hoewel in de ideale wereld een Agile team zelf de planning bepaalt, is het in de praktijk vaak zo dat de wereld niet ideaal is. Er is een krappe deadline. Er is per sprint de behoefte om zoveel mogelijk op te leveren. Deze oorzaak is simpel om te herkennen. Als je aan een ontwikkelaar vraagt, waarom de kwaliteit zo slecht is, krijg je het volgende antwoord: ik had de tijd niet om te testen. Maar er is ook een andere variant, waardoor de ontwikkelaar niet goed test, namelijk het argument: daar is de tester voor. Bij een kwaliteitsverslechtering is er meestal sprake van een gevoeld tijdsgebrek, omdat het afschuiven van testen op de tester al vanaf het begin gedaan wordt. Maar wees er bedacht op dat beiden kunnen voorkomen.

De informatie is inconsistent
Een van de meest voorkomende problemen, is dat afgesproken wijzigingen in een lijst onder elkaar staan. Met bij voorkeur vragen, antwoorden, voorstellen en reacties door elkaar. Maar wat ook een probleem kan zijn, is dat je informatiebronnen niet consistent zijn. In je functioneel ontwerp staat een veld, wat in het design van de user-interface niet genoemd staat. Of in de story staat een veld genoemd, waarvan de gegevens in het ontwerp van de technische interface niet genoemd staat. Deze situatie is ook heel eenvoudig te herkennen. Als je een ontwikkelaar wijst op een bug, krijg je te horen: "Maar ik heb gebouwd zoals het in document x stond" of een soortgelijke zin.

Als je met een van deze drie oorzaken de toename van je bugs kan verklaren, stop dan met analyseren. En maak dit onderwerp bespreekbaar in je team.  Belangrijk is steeds opnieuw: deel deze bovenstaande groepen niet op. Als er een probleem is in een van deze groepen, kan deze zich op allerlei wijze tonen. Maar het grote probleem blijft gelijk: testomgeving management, verkeerde verhouding testen ontwikkelaars v.s. tester of informatie management. Maak het grote probleem op tijd bespreekbaar en laat je niet meepraten naar "maar dit is anders" argumenten. Hoe verleidelijk soms ook. En hoe logisch het soms ook klinkt.

Gewoon een kwestie van tellen

Als een van de drie nu niet de oorzaak is, dan is het gewoon een kwestie van tellen. Neem in een sprint de bugs en kijk vervolgens naar de volgende aspecten:

• Welke ontwikkelaar
• Welk onderdeel in de applicatie
• Welke laag in de applicatie (database, technische interface, user interface, business logica, enz.)

Kijk vervolgens ook naar het aantal story's of bij voorkeur storypoints per ontwikkelaar, onderdeel en applicatielaag. Als een bepaalde ontwikkelaar, onderdeel of laag duidelijk meer bugs per story of storypoint heeft, kijk dan eerst of er een eerste logische oorzaak is. Denk hierbij vooral aan tijdsgerelateerde zaken. Bijvoorbeeld een story die ruim zwaarder was dan de anderen. Of een in storypoints ruim onderschatte story. Wanneer dit niet het geval is, is de kans groot dat je de belangrijkste oorzaak gevonden hebt.

Hoe verder

Als er sprake is van een onderdeel of een laag waarin zich veel fouten voordoen, bespreek ze dan met het gehele team. Mijn ervaring is, dat het team meestal vrij snel aan kan geven wat het probleem is. Kennisgebrek en zelfoverschatting zijn de meest voorkomende, maar worden door de ontwikkelaars zelf vaak vrij snel onder ogen gezien. Kan je als team de oorzaak niet achterhalen, spreek dan af om story's in dit onderdeel als team beter te bewaken.

Is er sprake van een ontwikkelaar, die duidelijk meer fouten maakt, bespreek dit dan onder vier ogen. Maak er geen zondebok kwestie van. Mijn basishouding naar ontwikkelaars is altijd: elke ontwikkelaar wil goed werk leveren. En hoewel deze echt niet altijd juist blijkt te zijn, is die ruim voldoende waar om als startpunt te houden in mijn communicatie met een ontwikkelaar. Ook hier zal de ontwikkelaar vaak zelf de oorzaak aangeven. En ook dit komt vaak neer op kennisgebrek en zelfoverschatting. Als deze dat niet kan, vraag dan samen hulp aan een andere ontwikkelaar. Een die dezelfde programmeertaal spreekt en bij voorkeur meer ervaren is.

En dan is er de kans dat je de oorzaak niet vindt. Ga dan door en tel de volgende sprint weer. Mogelijk ontstaat na twee of drie of vier sprints wel een beeld van de oorzaak. En blijf het kwaliteitsprobleem bespreken met het team als geheel. Want hoe uitgebreid mijn lijst ook is, mogelijk weet jij of iemand anders in je team een oorzaak die hier niet in genoemd staat. Maar die wel voor jouw project een groot probleem vormt voor de kwaliteit. Het tellen blijft gelijk. En het onderscheiden van incident en probleem ook. Blijf beseffen dat teveel incidenten echt wijzen op een probleem en niet op heel veel pech.

Agile testen voor beginners

Echt goed exploritory testing is moeilijk en vaak voor gevorderden. Testtechnieken zijn vaak moeilijk om te leren en om toe te passen in een Agile omgeving. Dus wat doe je met iemand zonder testervaring, die in het Agile testvak wil beginnen?

Waar het bij Agile testen om gaat, is vaak om een testmethode te hebben, die flexibel is. Die geen tot weinig voorbereiding vraagt en in allerlei situaties toegepast kan worden. Dat maakt exploritory testing ook zo populair. Maar er zijn ook manieren van testen, die snel te leren zijn, weinig voorbereiding vragen en toch flexibel zijn. Drie die ik zelf veel gebruik, zal ik hier beschrijven.

De CRUD test (Create Read Update Delete)

Deze officiële techniek werkt simpel. Je creëert iets, bijvoorbeeld een medewerker, en controleert of de gegevens goed zijn. Je past het aan en controleert of de gegevens goed zijn. Je verwijdert het en controleert of de verwijdering juist heeft plaatsgevonden. Kijkend naar een website of applicatie is het bijna een kwestie van het vinden van de Nieuw, Opslaan en Verwijder knoppen om deze testen uit te voeren. Dat maakt dat er nauwelijks voorbereiding nodig is. En het leertraject is vrij snel.

Een voorbeeld:
Stel je hebt een website waar een persoon een rekening kan openen, wijzigingen kan doorgeven (b.v. aangeven hoeveel je rood mag staan) en de rekening kan opheffen. Dan heb je vervolgens 1 testcase, waarbij je een rekening opent (Create). Je opent een rekening en vervolgens vraag je de rekening opnieuw op en controleer je of alle gegevens correct zijn. (Read). Hierna wijzig je b.v. het bedrag dat je rood mag stan (Update). Dan vraag je opnieuw de gegevens van de rekening op (Read) en controleer je of het bedrag dat je rood mag staan goed is weergegeven. Als laatste hef je de rekening op (Delete) en kijk je of de rekening nog op de website getoond wordt (Read).

De checklist

Vaak is er op een of andere manier sprake van een lijst met eisen. Als de lijst werkelijk een opsomming is, heb je meteen een checklist die je kan gebruiken. Is er sprake van een stuk tekst, dan is dit wat moeilijker. Je kan van de stuk tekst dan een opsomming maken. Maar je kan ook gebruik maken van een marker. Markeer de stukken tekst die je getest hebt of die je niet hoeft te testen. Als de volledige tekst gemarkeerd is, dan is de test afgerond. Kan het simpeler en sneller?

De gegevens test

Dit is geen officiële techniek, maar heel eenvoudig toe te passen. Op bijna elk scherm staan invoervelden of gegevens die data bevat. Als er geen invoerveld is, maar er staan wel gegevens op het scherm, dan kunnen deze gegevens ergens gewijzigd worden. Voor alle invoervelden en andere gegevens kan je eenvoudig de volgende testen uitvoeren

• Elk gegeven moet minimaal twee waarden hebben gehad
  Dit is om te testen of een bepaald veld steeds dezelfde standaard waarde toont. Ja, ik heb echt meegemaakt dat een vrouw werd opgeslagen en veranderde in een man.
• Elk gegeven moet minimaal een waarde met de maximale lengte hebben gehad
  Hiermee controleer je of de maximale waarde ook wordt aangehouden bij de invoer, maar daarnaast of dit gegeven op andere schermen netjes wordt weergegeven. Gaat bijvoorbeeld de tekst niet over een andere tekst heen als de maximale lengte van een veld wordt gebruikt. Als er sprake is van een keuzelijst, kies dan de langste waarde.
• Elk gegeven moet minimaal een keer leeg gelaten zijn
  Hiermee controleer je soms verplichte gegevens goed gecontroleerd worden. Maar bij niet verplichte gegevens controleer je of de applicatie goed omgaat met lege velden. Echte fouten die ik ben tegengekomen, zijn:
  - Twee spaties tussen voor- en achternaam, omdat tussenvoegsel leeg was.
  - Een technische veldnaam de de locatie waar anders het gegeven had gestaan
• Elke lijst moet minimaal getest zijn met 0, 1 en 3 waardes
  Dit is eigenlijk een variant van de bovenstaande testen, maar dan voor een lijst. Controleer of de applicatie goed omgaat met lege lijsten. Controleer of de lijst 1 waarde goed toont. En controleer of de lijst goed omgaat met meerdere waardes.

Alleen het leeg laten zal niet altijd mogelijk zijn, omdat sommige invoervelden verplicht zijn. Daarom zal je sommige gegevens op sommige schermen niet leeg kunnen tonen. Voor de rest is alles bruikbaar voor elk scherm.

Uitwerking:
Stel je hebt een applicatie waar je de straatnaam in kan voeren. De straatnaam mag maximaal 50 karakters bevatten. In dit geval gebruik je bijvoorbeeld de volgende waardes:

Twee waardes: Johan de Graafplein, Pieter Poter Plofkade
Maximale lengte: 12345678901234567890123456789012345678901234567890
Leeg: Waarschijnlijk is dit een verplicht veld, dus je zal hier controleren of er een melding verschijnt

Dit is slechts een start

De beschreven testen zijn slechts een start. Ze zorgen al vrij snel voor een bruikbare test van een applicatie of website. Terwijl de leercurve en voorbereiding laag is. Er missen nog zaken, zoals ketentesten en het goed testen van beslisschema's. Maar met deze testtechnieken kan je elke beginnende tester vrij snel waardevol inzetten. Zonder Agile testen te maken tot een ouderwets keurslijf of een taak alleen geschikt voor ervaren testers.

Test je testtools

Voor testen gebruik je al vrij snel hulpmiddelen en applicaties. Vaak om je testen te automatiseren, maar ook om je bij het testen te ondersteunen. Steeds vaker gebruiken we dan wat anderen ook gebruiken. Wat we op internet kunnen vinden bovenaan de Google lijst. We gaan ervan uit dat deze tools werken. En dat de tools voor ons zullen werken. Mijn ervaring: dit is niet altijd het geval. De oplossing: test je testtools, voor je ze invoert.

Mijn ervaring met testtools is zeer positief en zeer negatief tegelijkertijd. Bij het testen voor mobiele telefoons is het zoveel eenvoudiger om simulatoren en emulatoren te installeren dan om echte telefoons te kopen. Totdat een knop op een mobiele telefoon niet werkt. En de knop deed het toch echt op de simulator. Of in een andere situatie: je komt er tot je verbazing achter dat een tool plotseling resultaten niet meer toont. Omdat jij een weergave wil in tekst en het tool voor je besluit dat HTML een betere optie is (ja, echt gebeurd). Maar ze kunnen je flink tijd en geld besparen. Een simulator kan vrij risicoloos gebruikt worden om het testproces te versnellen, omdat je deze op elke laptop beschikbaar kan maken. Mits je ook besluit aan het eind op een echte mobiel te testen. En als je 95% van de tijd je gewenste tekstweergave krijgt, kan je voor die 5% HTML wel een iets mindere ideale oplossing vinden.

Om nu grote problemen bij gebruik te voorkomen, is het verstandig om te weten waar je een tool voor wil gebruiken. Neem bijvoorbeeld de volgende vragen:

• Hoe betrouwbaar moet het zijn? Wil je een nauwkeurige test of gaat het vooral om een indruk te krijgen?
• Is het als hulpmiddel bedoelt, ter aanvulling van een bestaande testwijze? Of moet het echt een andere testwijze gaan vervangen? Dit kan weer effect hebben op de benodigde betrouwbaarheid.
• Wil je de test eenmalig uitvoeren om de kwaliteit te bepalen? Of is het tevens een controle middel om de kwaliteit te bepalen over langere tijd, zoals een regressietest? Bij de tweede keuze zijn de eisen voor het vastleggen van gegevens hoger dan bij de eerste.
• Wat zijn je eisen? Welke browsers, programmeertalen, operating systems, databases, enz. moet het kunnen ondersteunen?
• Hoe flexibel moet de tool ingezet kunnen worden? Vaak te lezen als: hoe groot is de kans op verandering in de organisatie? Hoe flexibeler je tool moet zijn, hoe meer je organisatie verandert, hoe verstandiger het is om de eisen ruimer te trekken dan b.v. de programmeertalen die je nu gebruikt of de browsers die je nu ondersteunt.

Dan komt de werkelijke test: probeer je tool uit. Bedenk een eenvoudige testsituatie, die wel overeenkomt met een test die je vaak tegenkomt. En misschien moet je er zelfs meer bedenken. Kijk met behulp van deze testsituatie of je tool aan de eisen voldoet. Vertrouw niet op teksten als "Deze applicatie is zowel in IE als in Firefox te gebruiken". Als dit voor jou belangrijk is, gebruikt het dan zowel in IE als Firefox. Mogelijk zijn de aangeboden functies in een van beide minder uitgebreid.

Om dit duidelijk te maken, een kleine voorbeelduitwerking. Stel je hebt vaak websiteprojecten. Hierbij is performance een belangrijke graadmeter. Performance testen heeft zeker de voorkeur, maar dit kan vaak pas aan het eind en kost vrij veel tijd. Nu heb je gehoord van standaarden als PageSpeed, die via regels en berekeningen een performancescore geven van een pagina op de website. Deze standaard wordt door verschillende tools ondersteunt en ze lijken allemaal even goed.

Omdat Performance voor jou belangrijk is, wil jij een tool dat werkelijk kritisch is. Nu zou je denken dat, uitgaande van een standaard, de score, ongeacht tool, gelijk zouden zijn. Hier kan je blind van uitgaan of je kan dit controleren. Onderstaand het resultaat van een test die ik zelf heb uitgevoerd t.b.v. deze blog. De waardes zijn dus niet verzonnen, maar werkelijk gemeten met behulp van de gekozen website.

Als je weet dat de pagina bij een hogere score als een pagina met een betere performance wordt beschouwd. En je eis is om een zo kritisch mogelijk tool te kiezen. Welke van de bovenstaande hulpwebsites zou je dan niet kiezen?

Waar het op neer komt: vertrouw niet blind op verkooppraatjes, reviews, tips of standaarden. Probeer zelf de tools uit en kijk hoe ze voor jou werken. En kijk hierbij vooral naar datgene wat voor jou belangrijk is. Want wat een goede keuze is voor een ander, kan voor jou de verkeerde keuze zijn.

Een team is een project op zich

Misschien niet echt een onderwerp wat direct met testen te maken heeft: hoe maak je een team met mensen die goed met elkaar samenwerken? Toch is mijn ervaring dat je hier als tester wel snel mee te maken krijgt. Je bent vaker de uitzondering in de groep, namelijk de enige tester. En daardoor je ook vaak meteen een van de specialisten in de groep. Dus voor testers geldt zeker wat voor elk teamlid geldt: een goed team worden en blijven is een project op zich. Een project waarin je probeert op te komen voor jezelf en de zaken die jij belangrijk vindt, zonder het team of het project in gevaar te brengen. Als dit evenwicht niet lukt, kan een gespannen situatie ontstaan. Een situatie die vaak wat weinig aandacht krijgt. Want zou het met professionele IT'ers niet automatisch moeten gaan?

Hoewel het vaak goed gaat, is een goed team geen automatisme. Het gebeurt regelmatig dat bij een nieuw team of een wisseling in het team strubbelingen ontstaan. Als je geluk hebt tussen twee personen. Maar dit kan ook leiden tot een team in twee kampen. Of een team met een teamlid als te overwinnen tegenstander. Ik heb hele goede, professionele senior IT'ers de mist in zien gaan, omdat de rol die ze al jaren hadden, en met succes, niet meer volledig paste in het nieuwe team. Ik heb ze zien winnen ten koste van andere teamleden. Ik heb ze zien verliezen ten koste van het project. Maar ik heb ze ook zien veranderen en een nieuwe rol zien ontwikkelen. Ik geloof dan ook dat iedereen in een team kan komen waar het project 'teamontwikkeling' niet zo soepel loopt als verlangt. En dat iedereen hier ook een keer (mede) de oorzaak van kan zijn.

Toch zijn er wel manieren waarop je als team je teamontwikkeling weer op de rails kan krijgen. In de loop van de tijd, ook door eigen vallen en opstaan, heb ik er een paar geleerd. Hulpmiddelen, die niet altijd simpel zijn. Communicatiemethodes, die je niet altijd vol zal houden. Het vraagt zoveel, dat het vaak zal mislukken. Maar ook op dit gebied: oefening baart kunst. En als het jou niet lukt, misschien lukt het een ander teamlid dan wel.

1. Verander een ander, begin bij jezelf
Meestal hoor je dat je een ander niet kan veranderen. Je moet de ander maar accepteren, zoals die is. Qua karakter, sterke en zwakke eigenschappen is dit zeker waar. Maar qua gedrag en handelingen hoeft dat zeker niet. En is het ook niet nodig.

Iedereen kent de feedback gesprekken, met als doel een ander te veranderen. Als officieel onderdeel van je werk of gewoon als collega's onder elkaar tijdens een kopje koffie. Maar soms werkt jouw feedback gesprek bij een collega niet. Jij doet echt je best om de ander te overtuigen, te dwingen, te stimuleren, te coachen. Alles om de ander te helpen een beter persoon te worden. Maar het werkt gewoon niet. Jij geeft de ander steeds weer opnieuw een kans, met geen resultaat. De ander moet dan toch wel een hopeloos geval zijn?

In veel gevallen heb je het gesprek elke keer op dezelfde manier gevoerd. Je hebt steeds geprobeerd de ander met argumenten te overtuigen. Of je hebt juist geprobeerd de ander te leren wat de juiste manier van werken is. Wat voor manier het ook is, hij werkt niet. Als je met deze manier blijft doorgaan, geloof je dan echt dat de ander opeens wel zou veranderen? Of doe je het vooral om aan anderen te laten zien dat je echt je best gedaan hebt? Wordt het misschien tijd om een andere manier te proberen? Verander je toon, verander je woorden, verander je rol. En vooral, zoek hulp. Maar daar kom ik verderop op terug.

2. Een gezamenlijke mening is nog geen werkelijkheid
Wat ik het meest in teams tegen kom is de zogenaamde elkaar bevestigende vooroordelen. Persoon A krijgt van Persoon B te horen dat persoon X slecht met mensen kan samenwerken. Vervolgens maakt persoon X tijdens een meeting zoveel kritische opmerkingen, dat de meeting flink moeizamer verloopt. Steeds opnieuw kritiek hebben is een duidelijk kenmerk van slecht met mensen samen kunnen werken. Je staat niet open voor ideeën van anderen, als die niet overeenkomen met die van jou. En dat toon je door kritiek te geven. Persoon A praat hierover met Persoon B en vertelt dat Persoon X inderdaad slecht met mensen lijkt samen te werken. Persoon A ziet het beeld van Persoon X bevestigd door de meeting. Persoon B ziet het beeld van Persoon X bevestigd in de woorden van Persoon A. En zo'n bevestigingspatroon kan zich snel over een grote groep mensen verspreiden.

Wat er gebeurt is dat Persoon A al een beeld heeft van Persoon X voordat die elkaar echt hebben leren kennen. Handelingen van Persoon X worden dan naast het beeld gelegd om te kijken of ze het beeld bevestigen. En in veel gevallen zal het beeld bevestigd worden. Iedereen maakt fouten. Iedereen doet wel eens iets wat een ander niet leuk vindt. En als je een opmerking als "slecht samenwerken" neemt, kan bijna elke fout of ongewenste actie daaraan toegewezen worden. Te veel kritiek hebben, toont aan dat je niet open staat voor de mening anderen. Te weinig kritiek hebben, toont aan dat je niet geïnteresseerd bent in de groep of het project. Maar omdat Persoon A en Persoon B het eens zijn geworden, wordt het beeld van Persoon X voor hun de onweerlegbare werkelijkheid.

Dat je met anderen over iemand praat is niet te voorkomen. Dat je probeert samen een beeld te vormen van die persoon ook niet. Maar besef in ieder geval dat de valkuil er is. Ik heb werkelijk regelmatig meegemaakt dat een grote groep mensen door dit mechanisme een verkeerd beeld van een persoon kregen. Hoewel dat beeld incorrect was, is dit een gevecht wat bijna niet te winnen is. Want als zoveel personen hetzelfde over iemand denken, hoe kan het dan niet waar zijn? Nou, heel eenvoudig, als je niet hebt voldaan aan de volgende twee punten.

3. Vraag geen hulp aan een medestander
Als je moeite hebt met een persoon, is het heerlijk om te horen: 'je hebt gelijk'. Dit krijg je vaak te horen van iemand die precies dezelfde mening heeft over die persoon. Of juist iemand die nog geen mening heeft. Zoals jij je verhaal vertelt, is het vaak overduidelijk dat alles aan de ander ligt. Er zijn weinig mensen die in staat zijn om het op te nemen voor een persoon, die ze niet of nauwelijks kennen. Zeker niet als jij en je gesprekspartner een goede band hebben. En omdat het antwoord je sterkt in je overtuiging, zoek je niet verder. Het ligt aan de ander.

Hulp vragen aan personen, die jou gelijk geven, heeft daarom vaak geen effect. Ze vertellen je dat jij goed bezig bent en dat de ander fout bezig is. Dus vooral zo doorgaan. En je weet al hoe ik daar over denk. Hoe je iemand herkent, die je wel kan helpen? Heel simpel: een persoon die je niet altijd gelijk geeft. Iemand die wel serieus naar je luistert, maar tegelijkertijd probeert om je op een andere manier naar de situatie te laten kijken. Door je te vertellen hoe je over kan zijn gekomen. Door je een andere reden voor te spiegelen, die tot precies dezelfde handelingen kan leiden. De meest simpele keus hiervoor is een persoon, waarmee zowel jij als die moeilijke collega een goed contact heeft. Als dit niet kan, is het gewoon een kwestie van proberen tot je een juiste helper gevonden hebt.

4. Iedereen heeft recht op een luisterend oor
In veel gevallen waarin vooroordelen als werkelijkheid worden gezien, omschrijf ik de situatie op dezelfde manier. Er is veel over een persoon gepraat en/of er is veel tegen een persoon gepraat. Maar er is weinig met een persoon gepraat. Mensen hebben achter de rug van iemand om de betreffende persoon uitgebreid besproken. En als hij of zij geluk heeft, is er een gesprek geweest waarin de persoon is vertelt wat het probleem is. Waarschijnlijk ook meer dan een keer. Er dus is over de persoon gepraat en er is tegen de persoon gepraat. Maar is er ook met de persoon gepraat? Heeft die persoon kunnen uitleggen waarom hij of zij zo heeft gehandeld? Heeft die persoon kunnen uitspreken wat voor andere methodes hij of zij al geprobeerd heeft? Heeft die persoon kunnen vragen waarom de handelingen fout waren, omdat dezelfde handelingen in een vorig team juist werden gewaardeerd? Of zijn alle vragen beantwoord, zonder de vragen te stellen aan de persoon die het betreft? Heb je samen met de anderen die antwoorden al als waarheid aangenomen? Hoe hard het laatste ook klinkt, het komt zeer regelmatig voor.

Iedereen heeft het recht om zijn of haar kant van het verhaal te vertellen. En om dat te doen bij een luisterend oor. Je kan dit stimuleren door zelf tijdens een gesprek ernaar te streven zoveel mogelijk vragen te stellen, waardoor je de ander de kans geeft de situatie en keuzes toe te lichten. En om niet te spreken in feiten: 'Jij bent....","Jij moet vanaf nu....".  En in plaats daarvan te spreken in observaties: "Jij komt over als..., waardoor....".

Als je merkt dat je dit niet meer kan opbrengen, voer dan het gesprek niet. Maar onderneem ook geen verdere acties gebaseerd op je huidige beeld van een persoon. Zorg ervoor dat die persoon alsnog met iemand kan praten. Kijk hierbij niet automatisch naar een leidinggevende, personeelszaken of een collega met hetzelfde werk. Hoe logisch ook, niet altijd zal deze persoon een luisterend oor kunnen bieden. Omdat ze mee zijn getrokken in het verkeerde beeld of omdat ze de situatie te weinig kennen. Vraag, zoals eerder beschreven, de juiste persoon om hulp. Maar zorg er wel voor dat die hulp er komt. Want als je als team wil groeien, heeft iedereen het recht om op een open manier zijn of haar kant van het verhaal te vertellen.

De kracht van een team
Bovenstaande punten zijn maar het begin. Ze hebben tot doel een situatie te creëren, waarin mensen elkaar leren kennen door met elkaar te praten, niet over elkaar. Waarin iedereen in het team mogelijke vooroordelen kan herkennen. En kan besluiten er niet in mee te gaan. Want iedereen gaat wel eens op een van deze bovenstaande punten de fout in. De kracht van het team is dan juist, dat je elkaar opvangt als twee of meer personen problemen met elkaar krijgen. En elkaar helpt anders naar de situatie te kijken en anders met de situatie om te gaan. Er is bijna altijd wel iemand in het team, die de rol van helper kan invullen, mits je de situatie op tijd aanpakt. En niet wacht tot je niet 1 team, maar 2 teams hebt.

Acceptatietesten door een niet-tester

Veel testers zullen te maken krijgen met een acceptatietest. Een test, die zeer belangrijk is, maar wel vaak een belangrijk verschil heeft. De acceptatietest wordt niet altijd uitgevoerd door een tester. En wat de situatie nog moeilijker kan maken, de uitvoerder van de test heeft heel soms nog nooit eerder een test uitgevoerd. Nu kan je zeggen: "Dat is mijn probleem niet". Maar je kan er ook voor kiezen te helpen om de acceptatietest een echte aanvulling te maken op jouw eigen testen, ongeacht wie ze uitvoert.

Wanneer jij je testen uitvoert, denk je als een tester. Je denkt in testsoorten, testtechnieken en standaard testgevallen. Dit geeft natuurlijk een betrouwbare test. Maar je denkt vaak vanuit de functionaliteit die beschreven is, de paden die bekend zijn, de situaties die vaak fout gaan. Misschien heb je de test ook wel aangevuld met de meest voorkomende situaties in de praktijk, maar het blijft echt een IT test. Hoeveel je ook probeert, je hebt de domeinkennis niet opeens bij de hand, als je voor het eerst een onderdeel test. De persoon die het systeem gebruikt, heeft kennis die ook nodig is om goed te testen. Gaan alle situaties die in de praktijk voorkomen wel goed? Is er niet per ongeluk een situatie vergeten? Worden de gegevens in alle aansluitende systemen goed verwerkt? Er is niemand die dat beter kan beoordelen, dan de persoon die elke dag met het systeem werkt.

Maar deze persoon is geen tester. De kennis is in het hoofd aanwezig, maar komt niet zomaar op papier. Dus gewoon zeggen: "Jij hebt de kennis, dus test het maar" levert vaak geen betrouwbare test op. Waarmee de extra kennis geen extra waarde heeft in het testtraject. En juist door deze kennis goed in te zetten bij een acceptatietest, ontstaat een veel betrouwbaarder testtraject. Waarin zowel vanuit test- als domeinkennis een volledige test wordt uitgevoerd. Maar hoe kom je tot een acceptatietest?

Het belangrijkste is om eerst zelf een schakel om te zetten. Vergeet je testtechnieken, testmethodes, testgevallen. Probeer niet te denken in grensgevallen of andere voor jou logische testen. Waarom dit van belang is? De testen moeten geschreven gaan worden als praktijksituaties. Jij kan weten dat twee praktijksituaties in het systeem geen enkel verschil uitmaken, maar door dit uit te leggen bemoeilijk je het beschrijven voor de acceptatietester. Wanneer deze elke testsituatie door jou laat keuren, is de kans groot dat hij of zij zich niet meer vrij voelt om elke praktijksituatie op te noemen. En juist deze onbelemmerde vrijheid geeft een soort van brainstormsituatie. Waardoor ook de meer uitzonderlijke gevallen boven gaan komen. Die wil je horen. Daarvoor moet jij een volledige vrije omgeving creëren. En je opmerkingen over welke testen overgeslagen  of samengevoegd of beter kunnen worden voor je houden.

Hoe kan je wel helpen? Maak gebruik van CRUD (Create, Read, Update, Delete). Begin met de meest simpele. In veel gevallen is dit de Update. Vraag aan de persoon in welke gevallen er sprake is van wijzigingen. En ga hierna voor elke letter (voor zover van toepassing) de situaties na. Wanneer worden er nieuwe zaken aangemaakt? Wanneer worden ze verwijderd of op inactief gezet? Hoe worden de gegevens weer opgevraagd en welke gegevens worden dan opgevraagd? Naast de CRUD kan je ook gebruik maken van de bekende gegevens. Stel dat een persoon een voornaam, tussenvoegsel en achternaam heeft. Vraag dan bijvoorbeeld welke van deze gegevens gewijzigd worden. En maak van elk van deze gegevens een testgeval. In veel gevallen zal dit leiden tot een wijziging in voornaam, een wijziging in tussenvoegsel en een wijziging in achternaam. Drie testcases. Of slechts een, namelijk tussenvoegsel en achternaam samen. Wat de uitkomst is, maakt niet uit. Als het maar een situatie uit de praktijk is.

Waar het dus om gaat, is dat je de persoon hulpmiddelen geeft om vrij praktijksituaties te bedenken, die getest moeten worden. Zonder sturing, maar met hulp. Zonder correcties, behalve de controle of het volledige systeem getest wordt. Maar let op: niet of het systeem volledig getest wordt, dat moet je in je eigen test opvangen. Door te praten in praktijksituaties, in plaats van testcases, ontstaat dan een situatie waarin iedereen testcases kan bedenken. En ze vervolgens ook kan uitvoeren. Waardoor beide testen elkaar echt gaan aanvullen.

Testen van de backlog: samen streven naar een goed product

De productowner is verantwoordelijk voor inhoud van story's en volgorde van backlog. En de rest van het Scrumteam voert uit. De productowner vertelt niet hoe je een story bouwt, het Scrumteam vertelt niet hoe je de story schrijft. Heel eenvoudig. Maar ook gevaarlijk. Want de developers in het Scrumteam hebben kennis. Kennis die veel problemen kan voorkomen, als je daar al vroeg rekening mee houdt. Dus wat is een beter moment om hiermee te starten, dan het moment waarop de story's geschreven en geprioriteerd worden.

Nu kan je denken: dat heet toch product backlog refinement? Je wordt er als Scrumteam bij betrokken. En aan het eind snap je de story, begrijp je de prioriteit en sta je er dus volledig achter. Voldoende toch? Tja, ik zie zelf in de backlog refinement vaak beïnvloed worden door twee factoren:

Het eerste is de expertfactor. De productowner is expert op het gebied van de business. Wat de productowner zegt, stel je niet vaak ter discussie. En dat moet je als basis ook niet willen. Ik heb regelmatig meegemaakt dat een productowner vijf keer opnieuw de discussie aan moet gaan waarom een medewerker in het bedrijf echt wel blij wordt van een bepaalde story, zoals die beschreven is. Dat gaat vaak te ver, je moet het vertrouwen hebben dat de productowner met de persoon heeft gesproken. En het gewenste doel goed kan weergeven.  Maar zomaar geloven wat de productowner qua businesseisen in de story zet, dat is toch een ander verhaal.  Een productowner is misschien wel expert, maar geen allesweter. En is net als iedereen een mens, die fouten maakt.

De tweede factor is de uitzonderingsfactor. Elk Scrumteam heeft regels en afspraken gemaakt. En op het moment van opstellen staat iedereen hierachter. Maar dan verloopt de tijd. Een teamlid had wat tijd te weinig, er is een crisis die om snelle refinement vraagt of je hebt het gevoel dat de gemaakte afspraak nu vooral tijdsverspilling is. Dan ga je een uitzondering maken. Voor deze story verbreek je de afspraak. Daarna voor alle soortgelijke story's, want je deed het bij die ene story ook. Vervolgens voeg je hier een uitzonderingsgroep aan toe, want dat kon bij de vorige groep ook. En voor je het weet, is de afspraak eerder uitzondering dan regel.

Om dit te voorkomen moet je leren om zelf en op je eigen moment de backlog de testen. Ik spreek bewust niet van review, maar van testen. Bij een review speelt persoonlijke kennis en mening een belangrijke rol. Maar dat deel kan je vaak bij de refinement wel oppakken. Bij testen leg je het gemaakte product naast een bepaald eisenpakket. En kijkt of het product eraan voldoet. Vaak op eigen gelegenheid, zodat je er goed te tijd voor kan nemen.

Het projectdoel

Elk project heeft een doel. En het doel is vaak perfect geschreven voor de managers, die het geld beschikbaar moeten maken. Vaak ook nog voldoende om het Scrumteam en andere mensen in grote lijnen in te lichten. Maar kan je als Scrumteam het projectdoel ook gebruiken om de story en de backlog te testen? Anders gezegd: zorg ervoor dat iedereen in het Scrumteam het projectdoel begrijpt. 

Waarom? Stel dat de organisatie het belangrijk vindt dat op basis van gebruikersstatistieken achterhaald kan worden wat wel en niet werkt. Dan kan het verstandig zijn om bij elke story de volgende vraag te stellen: welke handelingen moeten gemeten kunnen worden? En kan dit meteen in deze story of moet dit in een aparte story er vlak achteraa?. Ook qua prioriteit kan het verschil uitmaken. Zijn alle onderdelen eigenlijk al te meten? Zo nee, moeten de story's die dit gaan oplossen, dan niet snel opgepakt worden?

Besef dat de hier beschreven business-eis niet snel op papier wordt gezet. Hij wordt als logisch gezien. En voor management en introductiemeetings niet zo van belang. Zorg daarom dat je duidelijkheid hebt over onderdelen als onderhoudbaarheid, meetbaarheid, performance, security en foutvindbaarheid (logfiles, etc.). Weet welke van deze eisen voor de business het belangrijkste zijn, want dan weet je wat bij de story's en de backlogprioriteit ook het belangrijkste is. Daarnaast kan je zelf kijken of er nog story's missen om deze doelen te halen.

De afspraakstatistieken

Elke uitzondering los lijkt niet erg. Tenslotte is Scrum bedoelt om flexibel te zijn. Een keer op het laatste moment een story oppakken, moet kunnen. Dus als je dan een keer niet helemaal aan de regels voldoet, is Scrum daar vast voor. Het is in ieder geval wat ik vaak gehoord heb: ja maar, bij Scrum mag je de prioriteiten toch steeds wijzigen? Ja, dat mag. En ja, je mag ook uitzonderingen maken. Maar als dit verbloemt dat een organisatie slecht kan prioriteren en daarom van het ene 'het moet nu' naar het andere 'het moet nu' springt. Waardoor steeds opnieuw story's vanuit het niets bovenaan de backlog komen. Dan wordt deze Scrumregel misbruikt. En een ander voorbeeld: als het Scrumteam geen tijd heeft of zin heeft zich aan hun eigen afspraken te houden. En daarom steeds opnieuw een uitzondering afspreekt. Dan misbruik je de geboden flexibiliteit vooral om jezelf voor de gek te houden.

Het belangrijkste middel hiertegen: maak de uitzonderingen zichtbaar. Dit kost tijd, tijd die je misschien liever ergens anders aan zou besteden. Maar zeker in een tijd met veel neiging tot uitzonderingen, levert het uiteindelijk veel op. De afspraken zijn tenslotte niet voor niets gemaakt.

Zo heeft bijna elk Scrumteam wel eisen waaraan een story moet voldoen. Leg van de story's die door het team 'geschikt voor in de sprint' verklaard zijn, vast hoeveel story's ook werkelijk aan deze eisen voldoen. Neem van mij aan: als je ziet dat slechts 50% van je story's voldoet aan alle gemaakte afspraken, is het woord "uitzondering" plotseling moeilijker te gebruiken.

En zulke statistieken kan je ook gebruiken voor andere afgesproken mijlpalen met eisen, Zelf heb ik naast bovenstaande mijlpaal, ook wel eens gebruik gemaakt van de mijlpaal 'geschikt voor refinement'. Hierbij ga ik ervan uit dat alle story's die in de komende drie sprints zullen komen op basis van huidige prioriteit, aan de eisen voldoen die het Scrumteam heeft opgesteld om er storypoints aan toe te kennen. Hiervoor heb ik het gemiddelde aantal story's per sprint bepaalt en vervolgens met drie vermenigvuldigd.

Tenslotte

Leg dus je backlog en story's naast het testdoel. Bekijk statistisch of je uitzondering wel een uitzondering blijft. En zoek je eigen testen. Welke problemen loopt jouw organisatie tegen aan? Heb je genoeg kennis om zelf deze problemen bij backlog of story's aan te geven? Kan je deze problemen met statistieken inzichtelijk maken? Of kan je zelfs een hele andere oplossing vinden? Waar het om gaat, is dat je leert om problemen te voorkomen door gebruik te maken van eisen van de business en afspraken van het Scrumteam. Dit zorgt voor draagvlak en voorkomt dat je strijd als 'eenmansoorlog' wordt gezien. Veel succes!

De ridders van Agile en de zoektocht naar de heilige testgraal

Binnen de wereld van Agile en Scrum wordt het testonderwerp vaak besproken. Men is op zoek naar dé manier van testen. Je moet vooral exploritory testing toepassen.  Of nee, je moet testen vooral automatiseren. En als je automatiseert, moet je vooral BDD toepassen. Of TDD. Welke manier van testen moeten we nu gaan toepassen bij Agile of bij Scrum? Wat is de beste methode en kunnen we aan de toekomstige testers gaan leren? Maar bij mij komt eerder deze vraag op: waarom voeren we deze discussie eigenlijk?

De discussie is al ouder en werd al gevoerd voordat Agile gemeengoed werd. TMap was een grote winnaar, maar toch waren er regelmatig groepen die opriepen om die methode vooral niet te volgen. Automatisch testen kwam meer in, waardoor het handmatig testen steeds meer in twijfel werd getrokken. Was het wel nodig? Moest je het wel willen? Dat deze discussie zich daarom bij Agile herhaalde, is dan ook niet vreemd. Er kwam wel een nieuw element bij. Waar vorige discussies vooral door testexperts onderling werden gevoerd, kwam er nu een nieuwe groep bij: de Agile experts. Een groep die zeker niet alleen uit testexperts bestaat.

Het kan echt geen kwaad om de gebruikte testmethodes en -technieken af en toe is ter discussie te stellen. Om erover te praten en weer opnieuw de voor- en nadelen vast te stellen. In het kader van Agile is het zelfs handig om je af te vragen hoe een bepaalde methode of techniek met Agile gecombineerd kan worden. Het wordt gevaarlijk als men Agile en Scrum als argumenten gaat gebruiken om bepaalde manieren van testen af te keuren. Als mensen beweren dat je testen wel moet automatiseren, omdat je anders niet goed genoeg kan inspelen op de steeds opnieuw veranderende applicatie tijdens een sprint. En als je dan toch handmatig test, moet het exploritory testing zijn, andere methodes zijn niet flexibel genoeg en vragen teveel papierwerk. Als wordt beweerd, dat je op BDD over moet gaan, omdat dit de enige methode is waarmee je de business bij het testen kan betrekken. Als mensen beweren dat je juist TDD moet toepassen, omdat zo programmeurs al kunnen testen, wat de multidisciplinaire karakter van een team versterkt. Wat hier het gevaar van is? Men kijkt niet meer naar de nadelen van deze methodes.

Exploritory testing is een methode die moeilijk te leren is. Als je hem goed wil toepassen, heb je echt iemand nodig die het je leert. Veel mensen die beweren deze methode toe te passen, doen eigenlijk gewoon maar wat. Bij een team waar flexibiliteit verwacht wordt, is een methode met een lange leercurve een nadeel. Je kan niet zomaar iemand bijschakelen. Daarnaast hangt de kwaliteit zeer sterk van de ervaring af. De tester bepaalt zelf de strategie en die is niet bij iedere tester van dezelfde kwaliteit. Veel testers zijn ook juist bij deze methode niet in staat om ervoor te zorgen dat bij vakantie of ziekte het werk zomaar door een ander overgenomen kan worden. Want hoe leg je de uit te voeren exploritory testen vast? En hoe leg je het hertesten vast?  Deze nadelen heeft een ouderwets testscript niet. Een testscript uitvoeren is eenvoudig te leren en kan ook goed overgenomen worden tijdens ziekte of vakantie. Het kost wel wat meer voorbereiding, maar daarna kan iedereen binnen je team meetesten. En bijna iedere tester weet hoe je er een schrijft.

Geautomatiseerd testen heeft ongeveer dezelfde nadelen. Ik heb zelf regelmatig geprobeerd om geautomatiseerde testen over te dragen en meestal is het niet gelukt. Alleen als de testen zijn geschreven in de taal van de ontwikkelaar met de tools van de ontwikkelaar is overdracht echt realistisch. De leercurve voor automatisch testen is ook nog eens veel groter dan bij exploritory testing, omdat mensen vaak eerst moeten leren programmeren in een taal en/of een testtool moeten leren gebruiken, voor de ook maar 1 test kunnen schrijven. Daarnaast is ook de voorbereidingstijd voor een goede automatische test enorm groot. De test is misschien zo geprogrammeerd (3 x zo lang als een handmatige test?). Maar herhaalbaarheid van de test en gebruik van goede testdata is vaak een probleem. De terugverdientijd is soms vrij lang. Terwijl juist door de snelle wijzigingen in een applicatie een test soms maar 3 x kan draaien, voordat hij opnieuw aangepast moet worden. Of misschien zelfs in zijn geheel weggegooid kan worden. Handmatig testen vraagt, zeker bij exploritory testing, veel minder voorbereiding en onderhoud. En is daardoor makkelijk aan te passen aan veranderingen in de software.

TDD en BDD zijn beide technieken die eenvoudig klinken, maar moeilijk zijn. TDD goed toepassen vraagt veel van programmeurs, daarom gebruiken vele een lichtere variant van TDD. Bijvoorbeeld eerst een aantal testen schrijven, daarna programmeren i.p.v. één test schrijven en dan programmeren. Wat de voordelen van TDD weer vermindert. Daarnaast worden er heel, heel veel testen geschreven. Dit vraagt veel onderhoud. De kleinste aanpassing gooit je testen al omver. Ook is TDD erg gericht op de kwaliteit van de code van een klein onderdeel van je applicatie. Kleine, eenvoudige testen. Testen waarbij gekeken wordt of module 1 ook goed samenwerkt met module 2 worden meestal niet geschreven. Zeker niet als de onderdelen in verschillende programmeertalen zijn geschreven. Of bij verschillende bedrijven zijn ontwikkeld. Het test daarom vaak niet voldoende om vast te stellen of je applicatie in zijn geheel geschikt is voor productie. Ouderwetse functionele testen zijn juist gericht op de gehele applicatie en staan veel meer los van een bepaald onderdeel. Een ervaren tester weet ook het aantal testcases beperkt te houden, zonder daarmee minder te testen.

BDD is ook al een methode waarbij de programmeurs vaak een light variant nemen. Hoewel de methode business-eisen als basis verwacht, worden die business-eisen regelmatig niet door de business ingebracht. Ergens ook logisch. Je maakt je zo afhankelijk van mensen die niet in je team zitten. En deze afhankelijkheid wil je eigenlijk zo min mogelijk hebben. Maar als de eisen niet van de business afkomen, heeft het dan nog veel meerwaarde? Daarnaast hebben deze testen vaak een lage dekkingsgraad. De business is niet opgeleid om tot een goed dekkende testcase set te komen. En de ontwikkelaars vaak ook niet. Nu BDD vaak gebruikt wordt om testers niet of minder nodig te hebben, is hun ervaring op dit gebied vaak afwezig. Wat is het dan een voordeel als je functionele test op meer gebaseerd is dan de business-eisen, waarbij door een tester goed is gekeken naar de dekkingsgraad.

Wil ik nu naar een Agile of Scrum wereld waarin al deze technieken niet gebruikt worden? Nee, natuurlijk niet. Wat ik wil is dat we stoppen met het verheerlijken van een bepaalde manier van testen. Zeker in Agile en Scrum. Agile vraagt een flexibiliteit van een tester, waarbij je kan inspelen op veranderingen in de applicatie, in je team, in de organisatie, in het ontwikkelproces. En naar mijn mening vraagt dit om de vaardigheid om de juiste keuzes uit je testgereedschappen te kunnen maken. Daarvoor moet je de voor- en nadelen van elke manier van testen heel goed kennen. En de voor- en nadelen die elke methode heeft binnen Agile en/of Scrum. Zodat je elk moment opnieuw kan besluiten of jouw team voor jullie situatie op de juiste manier test. Zowel Agile of Scrum schrijven tenslotte bewust niet voor hoe je moet testen of programmeren of documenteren. Welk testtool geschikt is, welke programmeertaal het beste is of welke template je aan moet houden voor het opschrijven van een story. Omdat beseft werd dat dit per situatie anders kan zijn. Wanneer gaan alle Agile (test)experts dat nu ook beseffen?