Handmatig regressietesten in een Scrumtraject - Is daar wel tijd voor?

Handmatig regressietesten is waardevol, maar tijdsintensief. En als je kijkt naar wat regressietesten inhoudt, wordt het nog veel tijdsintensiever. Waar je je bij gewone functionele test kan concentreren op datgene wat is aangepast of toegevoegd, kijk je bij regressietesten of dat deel wat juist niet aangepast zou moeten zijn, ook inderdaad niet aangepast is. En het deel wat niet aangepast is, is eigenlijk altijd veel groter dan het deel wat aangepast is. Dus het niet aangepaste deel handmatig testen is een zeer tijdsintensieve klus.

En dan heb je Scrum, met korte sprints. Sprints, waarin de tijd dus al beperkt is. Bij een sprint van twee weken heeft een regressietest van twee dagen een flinke impact.Maar als je alles wil testen in een grote applicatie, is twee dagen zelfs vaak nog te weinig. Niet voor niets wordt vaak gezegd dat handmatig regressietesten en Scrum gewoon niet samengaan. Je hebt de tijd er niet voor. Dus heb je meerdere opties: de regressietest overslaan en gokken dat de kwaliteit toch goed is, de oplevering uitstellen tot een sprint waarin je een hele lange regressietest plant of natuurlijk de regressietest automatiseren.

Waarom zou je hierover nadenken?

Aan iedereen, die altijd de volledige regressietest handmatig uitvoert, zou ik het volgende willen vragen: reken uit hoeveel uren je aan de regressietest besteed hebt. En kijk daarna naar de bugs die je hebt gevonden. Als deze bugs nu via de helpdesk of via de klant binnen zouden komen, hoeveel uur zou je er dan aan mogen besteden? Een validatiefout is zeker belangrijk, maar als je 8 uur nodig zou hebben om hem op te lossen, zou dat mogen? Waarschijnlijk zou er vaak gezegd worden: als het meer dan 4 uur is, dan kunnen we onze tijd beter besteden. Doe is een schatting van de tijd, die je aan het oplossen van de gevonden bugs zou mogen besteden. En vergelijk dit aantal uren met de tijd, die de regressietest heeft gekost. Als de tijd voor de regressietest lager is of ongeveer even hoog, dan moet je vooral zo door blijven gaan. Als de tijd overduidelijk hoger is, vraag je dan het volgende af: als ik deze tijd niet mag besteden aan het oplossen, waarom zou ik die tijd dan wel willen besteden aan het vinden van de bugs?

En dan de vraag voor de groep, die de regressietest maar overslaat: hoeveel tijd kost het eigenlijk om de regessietest niet te doen? Hoe vaak wordt er een bug door de klant gemeld, die je met een regressietest had kunnen voorkomen? Hoeveel tijd kost het om deze bug te analyseren en en om de bug met de klant te bespreken? Hoeveel tijd is het team als geheel kwijt met klachten van klanten over de kwaliteit in het algemeen? Hoeveel tijd zou je besparen als je zelf de bug zou ontdekken en de bug niet van een klant af hoeft te komen? Zou regressietesten dan uiteindelijk geen tijd besparen?

Maar hoe moet je dan handmatig regressietesten?

Binnen het testen is risk based testing vrij normaal. Je kijkt naar testsoorten, dekkingsgraden, etc. En mede op basis van de kans op een fout en de gevolgen als de fout optreedt, bepaal je hoever je gaat met je testen. Waarom zou je zo'n soortgelijke techniek niet bij regressietesten toepassen?

Er zijn onderdelen, die altijd moeten werken. Die onderdelen test je daarom altijd met een regressietest. Maar vaak geldt wel voor regressietesten: als het fout gaat, gaat het vaak altijd fout. Daar bedoel ik mee: als een knop eerst werkte, is bij de regressietest de kans groot dat de knop nu altijd werkt of altijd niet werkt. De kans dat de knop soms wel en soms niet werkt, is meestal niet zo groot. Dus een groffe handmatige regressietest, waarbij je alle belangrijke functies 1 keer raakt, kan met minder tijd al een flinke vermindering in risico opleveren.

Wanneer een knop toch plotseling soms wel en soms niet werkt, is er vaak sprake van enig raakvlak met een uitgevoerde aanpassing. De knop was bijvoorbeeld in hetzelfde scherm als de aanpassing. Of de algemene functionaliteit voor het actief en inactief maken van elementen is aangepast. Of het scherm voorafgaande aan de scherm met de knop is aangepast. Stel dat er dus een aanpassing in een scherm is geweest. Dan kan het zeer verstandig zijn de regressietest voor dit scherm wel uitgebreider te doen. Het kan ook verstandig zijn om een werkproces, waar dit scherm een onderdeel van is, wat uitgebreider te regressietesten. Overleg eventueel met het team en de productowner hoe ver je wil gaan? Hoe groot is het risico dat de aanpassing iets onverwachts heeft geraakt? Welke onderdelen of processen hebben het grootste risico op een fout? En hoe ernstig is dat?

Durf te beginnen

Risk based regressietesten is makkelijker beschreven, dan uitgevoerd. Maar durf te beginnen. Als je nu in een sprint geen regressietesten doet, heb je weinig te verliezen. Al begin je maar met de story's, waar je zelf een groot risico ziet op het veroorzaken van onverwachtse bugs. Al begin je maar met het grof regressietesten van de drie belangrijkste schermen in je applicatie of je belangrijkste proces. Al begin je maar met 2 uur per sprint. Probeer het uit, zeg voor ongeveer drie sprints, kijk of het bevalt en kijk wat het resultaat is. Bevalt het, breidt verder uit. Bevalt het niet, breng het terug. De hoeveelheid regressietesten, dat nuttig is, verschilt per bedrijf, per team, per applicatie. Dus dat zal je zelf moeten uitvinden. Maar als je het lukt, maak je wel een flinke kwaliteitssprong en wordt je als team een stuk flexibeler.

Testverbetering - Maak het meer Agile

Dat Agile een zeer goede manier van werken is voor het bouwen of onderhouden van applicaties, is iets wat langzaamaan steeds meer wordt geloofd. Men beseft steeds meer dat het verstandig snel een resultaat op te leveren, zodat deze voor de klant veel sneller een positief effect heeft en geëvalueerd kan worden. Dat, wanneer je het belangrijkste eerst bouwt, je het belangrijkste resultaat ook het eerst kan inzetten. En het belangrijkste bepaal je niet voor de klant, maar met de klant.

Vele bedrijven hebben ook regelmatig een gefaald verbeterproces achter de rug. In de testwereld gaan bijvoorbeeld vele verhalen van gefaalde testautomatiseringsprojecten. Maar ook testers, die worstelen om van T-Map waterval naar een Agile manier van testen te gaan. Exploritory testing, dat in de praktijk betekend dat iedereen maar wat doet. Een achterstand in regressietesten, in wat voor vorm dan ook, omdat de kennis van het product niet voldoende is om ook maar te starten. Een belangrijk aspect voor het falen "Ik heb geen tijd" wil ik even buiten deze blog laten. Als je de tijd wel krijgt, wat dan?

Ondanks de waardering voor Agile, zijn verbeterprocessen meestal nog heel erg waterval. Een, twee, maximaal drie mensen gaan samen als team het hele verbeterproces op papier uitwerken. Of een geheel automatiseringsproject wordt gebouwd door een of twee experts. Deze personen zijn vaak ingehuurd en/of deel van het management. Soms, als je gelukt hebt, aangevuld met iemand uit de praktijk van het bedrijf. Het contact met de mensen, die werkelijk moeten gaan werken met de verbeteringen, is zeer beperkt. Zo niet volledig afwezig. Als het traject volledig is uitgedacht of de automatisering volledig is gebouwd, wordt het met een grote big bang gestart. Vaak wordt in één keer een grote groep wijzigingen doorgevoerd. En de automatisering wordt in één keer in productie gezet. Dan zijn de experts klaar. Soms is er nog een beetje tijd voor de eerste begeleiding. Maar al snel gaan de externe experts door naar een andere klus en de interne experts weer door naar een ander project of volledig terug naar hun dagelijkse werk.

Hoewel de testers en eventueel ontwikkelaars weinig keus hebben, zie ik ze in dit proces wel als de klanten. Zij zijn, hoe vrijwillig of onvrijwillig ook, de personen die de verbeteringen afnemen. Die ermee moeten werken. En met grote regelmaat zijn zij ontevreden. Het fantastisch bedachte automatiseringsproduct kunnen ze niet onderhouden. Er wordt van de gevraagd om hun oude gewoontes weg te gooien, voordat de nieuwe zich bewezen hebben. Evalueren is vaak geen optie, net zo min zijn aanpassingen bespreekbaar. Want het project is eigenlijk al afgerond. Wat laatste klusjes kan misschien nog, maar verder houdt het op.

Als we het niet meer vreemd vinden dat waterval automatiseringsprojecten falen? Waarom zijn we dan nog steeds verbaasd dat waterval verbeterprojecten falen? En waarom zoeken we in de eerst situatie de oorzaak vaak bij de leverancier en in de tweede situatie vaak bij de "klant"?

Hoe moet het dan?

Er zijn drie belangrijke principes, die ik aanhoud, ongeacht of ik test of verbeter:

• Het belangrijkste moet het eerst
• Er moet zo snel mogelijk resultaat zijn
• Er moet draagvlak zijn

 Het belangrijkste moet eerst

Waar dit eigenlijk op neer komt is dat je een backlog maakt. Een lijst met problemen en/of een lijst met zaken die geautomatiseerd moeten worden, geprioriteerd op belangrijkheid. Een goede backlog is van groot belang. Daarom is het verstandig om juist hier al uitgebreid met de "klant" te praten. Welke problemen zien zij? Wat willen zij bereiken met automatisering? Is er eerder een project geweest, dat faalde? En zo ja, waarom denken zij dat het faalde?

Als in de backlog de belangrijkste problemen van de "klant" niet hoog staan, is de kans groot dat je project faalt. Ten eerste, omdat je "klant" niet zal geloven dat het gaat werken. Hun grootste problemen worden namelijk niet opgelost. Ten tweede, omdat je "klant" kennis en ervaring heeft, die jij mist. Deze zomaar negeren, leidt meestal niet tot een betere oplossing.

Hier is wel een groot verschil met verbeteringen op organisatie niveau en testverbeteringen. Bij grote verbetertrajecten geldt vaak het argument "Ik kan toch niet iedereen betrekken". Maar als je het hebt over testverbeteringen, gaat het vaak niet over groepen testers van 30 man of meer. Iedereen erbij betrekken, of anders minimaal iedereen erbij betrekken die wil, is daarom eigenlijk bijna altijd wel een optie.

Er moet zo snel mogelijk resultaat zijn

Zo snel mogelijk resultaat is een moeilijke stap en te uitgebreid om hier tot in detail te bespreken. Er zijn echter wel twee zaken, die je moet loslaten, voor dit een echte optie wordt. Ten eerste moet je er niet naar streven het project zo snel mogelijk af te ronden. Dit leidt vaak tot een situatie waarin je met zo weinig mogelijk mensen en overleggen probeert om zo veel mogelijk zo snel mogelijk te bedenken, schrijven en programmeren. En het snelst werk je nu eenmaal in je eentje, in een kamer, met de deur op slot, waar je alles achter elkaar kan doen. Als het klaar is, kom je dan de kamer weer uit. En is het zoveelste waterval project afgerond.

Ten tweede  moet je de gedachte loslaten dat invoering pas zinvol is, als alles is bedacht en afgerond. Als je de belangrijkste testen heb geautomatiseerd, kunnen deze al meteen hun waarde bereiken. Als je voor de belangrijkste problemen een oplossing hebt bedacht, dan kan dit je "klant" al flink helpen. Zelfs als de rest nog in de pijplijn zit. Je kan nog niet alles automatisch testen en niet al je problemen zijn opgelost. Maar alle kleine beetjes helpen.

Er moet draagvlak zijn

Als er draagvlak is voor de verbeteringen, dan is men bereid zich daarvoor ook in te zetten. En om de verbeteringen echt een kans te geven. Wanneer je bovenstaande voor elkaar hebt gekregen, dan het je op twee punten vaak al hulp voor draagvlak bij de "klant": hun belangrijkste problemen worden snel opgelost en ze zien dat het project wat oplevert. Door de eerdere oplevering, kan je je "klant" nu ook betrekken bij evaluaties en verbeteringen. Het project loopt nog, dus als er echt iets is, dan kan dat in de backlog worden opgenomen. Als het belangrijker is dan een stukje "nieuwbouw", dan pak je het dus ook eerder op dan de "nieuwbouw".

Maar er is nog een belangrijke manier van werken om het draagvlak te vergroten: maak niet alle keuzes in je eentje of met je team. Draagvlak is vaak te herkennen, wanneer men niet meer spreekt over "hun project", maar "ons project". En één van de eenvoudigste manieren om van "hun" naar "ons" te gaan is: laat ze hun eigen bijdrage aan het project leveren. Kies hiervoor momenten, waarin de keuzes niet gaan tussen "goed" of "slecht". De mogelijke opties leiden altijd tot een goede weg, alleen de ene wat beter dan de ander. Hierbij is wel belangrijk: je moet bereid zijn om de slechtere keuze te accepteren. Mijn ervaring is: een slechtere oplossing met draagvlak heeft een beter effect dan een betere oplossing zonder draagvlak. Omdat in het tweede geval de inzet, het vertrouwen en het geloof in de oplossing zullen ontbreken. Wat regelmatig zorgt voor een "self fulfilling profecy".

Nee, dit is niet alleen een techniek om iedereen blij te houden. Je resultaat zal er ook flink beter van worden. De verbeteringen zijn vaak op initiatief van een manager, scrummaster, testcoordinator of senior tester. En met grote regelmaat ook op initiatief van iemand die vrij nieuw in het bedrijf is. Hoe veel deze personen ook zien, ze zien zeker niet alles. Ze weten niet alles, ze horen niet alles. Hoe is het om als junior tester in dit bedrijf te werken? Welke problemen loop je tegenaan als je wil groeien en leren? Grote kans dat je verbetertraject dezelfde problemen gaat ondervinden. Dus waarom zou je een junior tester niet betrekken bij je beslissingen over leer- en overdrachtstrajecten? Bijna elke groep heeft een of meer "vertrouwenspersonen", een persoon waar mensen zeer snel naar toestappen als ze problemen hebben. Zij kennen de organisatie vaak beter dan de officiële managers. Dus waarom zou je ze niet betrekken bij besluiten over informatiebijeenkomsten en andere communicatiemiddelen? Om de meest logische categorie "ze hebben gewoon van hun vakgebeid heel veel kennis, meer dan jij" nu eens niet als eerste te noemen.

Dus...

Verbetertrajecten moeten, net als bouw- en onderhoudstrajecten, het doel hebben de "klant" tevreden te stellen. Daarom wil je ze snel resultaat geven, om te bewijzen dat het werkt en ze de kans te geven zaken te verbeteren. Voor het beste resultaat, doe je het het belangrijkste het eerst. En zorg je voor draagvlak bij je "klant". Het blijft simpeler geschreven, dan gedaan. Maar ook voor deze blog geldt: elke kleine verbetering in je verbeteringstraject kan al helpen. Lukt niet alles in een keer, doe de volgende keer wat meer. En als dit allemaal teveel is, begin gerust alleen met het belangrijkste.

"Dat doen onze gebruikers niet" - Het belang van betrouwbaarheid bij testen

De meeste testers zijn wel voor goed geprioriteerd testen. En dat mag zeker op basis van een goede risico-analyse. En zeker geen onbelangrijk onderdeel van zo'n risico-analyse is: Hoe vaak wordt deze functie op deze manier gebruikt? Veel tijd besteden aan het testen van een functie, die nauwelijks gebruikt wordt, zal vaak onverstandig blijken. En uitgebreid gegevens invoeren, die in werkelijkheid nooit ingevoerd zullen worden, is vaak ook niet het meest nuttig. Wel moet je hierbij stilstaan bij een factor: er is een groot verschil tussen niet testen en minder testen.

Ik heb zelf regelmatig als tester te horen gekregen, als ik een fout vond: "Maar dat doen onze gebruikers niet." Wat inhield dat ik mijn tijd aan het verspillen was. Want hoeveel fouten ik ook zou vinden, hoe ernstig ze ook zouden zijn, ze zouden toch niet worden opgelost. De gebruiker zal ze niet tegenkomen, dus er zullen geen klachten over komen, dus men kan de tijd wel beter besteden. Ik kon mijn tijd wel beter besteden.

Testen heeft meerdere doelen. Maar het doel om de applicatie te laten werken, zoals je gebruikers dat nodig hebben, is zeker een hele belangrijke. Juist als functionele tester, wil ik eigenlijk altijd een stapje verder gaan. Bij mij is betrouwbaarheid altijd een zeer zwaar meetellende factor. Als een gebruiker plotseling een uitzonderingssituatie invoert, moet de gebruiker niet opeens grote fouten tegengekomen. Als er een nieuwe gebruiker is, die net even anders werkt, moet de applicatie niet opeens onwerkbaar blijken te zijn. En als een nieuwe klant of afdeling ook de applicatie gaat gebruiken, moet deze niet opeens onder je vingertoppen omvallen. Hoe je de applicatie ook gebruikt, er mogen eigenlijk geen grote fouten inzitten. De gebruiker moet altijd op de applicatie kunnen vertrouwen. Dus als iets oplossen of testen de moeite niet waard is, omdat onze gebruikers dat toch niet doen? Dan heb ik liever dat je die functionaliteit of situatie verwijdert, dan dat je er een grote fout in laat zitten.

Het doel van een goede functionele test is het streven naar goede kwaliteit. Kwaliteit, die zo min mogelijk afhankelijk is van nu, van de huidige gebruikers, van de huidige klanten en/of afdelingen. Je testen moeten daarom ook zeker niet alleen gericht zijn op de meest voorkomende situaties. Maar juist ook op de "nu misschien nog niet, maar je weet maar nooit" situaties. Hier hoeft niet 90% van je testtijd in te zitten, maar 0% is te weinig. Een goed evenwicht vinden, dat is en blijft het streven.

Agile Review - Wanneer is het logsich? Wanneer weet iedereen het?

De ouderwetse review van documenten was duidelijk: alles moest erin staan. Als je iets miste, voegde je het toe. Niemand deed het graag, maar er was nauwelijks discussie mogelijk. Toen kwam Agile en daarmee de reden om minder te documenteren. Argumenten die vroeger bij een review niet van toepassing waren, worden nu opeens belangrijk. Nu hoor ik bij een review vaak argumenten als: "Maar dat is toch logisch?" en "Maar dat weet iedereen toch?". Hoe Agile deze argumenten ook klinken, te vaak heb ik meegemaakt dat juist deze argumenten kunnen leidden tot niet werkende software. Omdat wat de schrijver logisch vond, voor de bouwer onlogisch was. En wat bij de schrijver bekend was, bij de bouwer niet bekend was. Juist binnen Agile is een goede review door een objectief persoon van groot belang. Maar ook een stuk moeilijker. Want wat voor criteria kan je gebruiken om te bepalen wat bekend is en wat niet?

Ervaring van het team

Ervaring van het team is de meest logische om mee te nemen in je review. Wanneer je een team hebt, wat al jaren aan de software werkt, dan kan je rustig van heel veel kennis uitgaan. Standaard berekeningen zullen bekend zijn. En standaard uitzonderingen zullen automatisch worden meegenomen. Zo zal iemand werkend aan verkoop binnen de vervoerssector waarschijnlijk uit zijn hoofd de meeste vervoersabonnementen op kunnen noemen. Met de meest belangrijke kenmerken voor de prijsberekening. Dit vermelden zal dan vaak niet nodig zijn. Heb je echter een team met veel mensen die de software nog maar kort kennen, zal je meer moeten vastleggen. Ze zullen geholpen moeten worden, door alle belangrijke situaties en uitzonderingen te noemen. Want zelf zullen ze er niet zo snel bij stilstaan.

Achtergrond van het team

Je staat er soms niet bij stil hoeveel kennis als Nederlander vanzelfsprekend is. Een postcode heeft vier cijfers en twee letters. Een telefoonnummer bestaat standaard uit 10 cijfers. Volwassenen zijn 18 jaar of ouder. Ouderenkorting is bijna automatisch 65+. In een Nederlands team kan je dit rustig als bekende informatie beschouwen. Maar in een internationaal team, wat steeds vaker voorkomt, zijn dit zaken waar je bij stil moet staan. Is bij iedereen in het team een volwassenen dezelfde groep personen? En worden de invoercontroles bij een adres niet te ruim of juist te krap vastgelegd, als je die niet hebt vastgelegd?

Frequentie van aanpassing

Wat echter zeer regelmatig vergeten wordt, is de frequentie van aanpassing. RFS's en/of story's worden regelmatig door mensen geschreven die dagelijks, en anders zeer regelmatig, te maken hebben met een bepaald scherm, een bepaald rapport of een bepaald proces. Zelfs als dit niet het geval is, heeft de schrijver vaak al weken een bepaald onderdeel bekeken en geanalyseerd. Zijn kennis van dit onderdeel is zo groot, dat wat voor hem logisch is en algemene kennis is geworden, voor anderen zeer onbekend kan zijn. Dit gebeurt dan ook vooral bij onderdelen in de applicatie, die bij bedrijven zeer vaak of zeer intensief gebruikt worden, maar nauwelijks worden aangepast. 

Denk bijvoorbeeld aan het invoeren van uren door medewerkers in het bedrijf. Dit proces zal bij iedereen in het bedrijf zeer bekend zijn. Urenregistratie is echter ook vaak een proces, wat niet zo vaak verandert. Ontwikkelaars hebben misschien al jaren niet meer aan dit onderdeel gewerkt. Dus dan kan het zijn, dat "Voer een extra controle in voor de manager" voor de schrijver automatisch betekend, dat zowel de tweestapscontrole als de driestapscontrole met een stap moet worden uitgebreid. Terwijl de ontwikkelaar niet eens weet dat er ook een driestapscontrole is.

En misschien is er nog meer...

Wat het belangrijkste is bij een review, zeker nu, is dat je de lezers kent. Dat je hun kennisniveau en hun achtergrond kent. Dat je weet hoe ze werken en bij voorkeur hoe ze lezen. Als het even kan, weet je ook precies hetzelfde van de schrijver. Zodat je ook de verschillen weet tussen de kennis van de lezer en de kennis van de schrijver.

Juist het verschil in kennis tussen lezer en schrijver wordt steeds belangrijker, wanneer je niet meer alles tot in de puntjes vastlegt. Wat voor verschillen dit ook zijn. Het maakt de review misschien een stuk moeilijker. Maar tegelijkertijd ook een stuk uitdagender.

Wat men kan leren van Agile en Scurm saboteurs?

Iedereen komt ze tegen, dus testers zeker ook: personen die zich verzetten tegen Scrum of Agile. Of steeds protesteren tegen bepaalde aspecten van Agile of Scrum. Regelmatig is het ook de tester zelf die saboteert. Saboteurs zijn lastig, een sta-in-de-weg. Ze beïnvloeden de groep negatief en staan verbeteringen in de weg. Ze maken meetings onnodig lang, doordat ze onderwerpen keer op keer op keer aankaarten, terwijl Scrum en Agile een duidelijk antwoord geven. Ze gaan hun eigen weg, terwijl je juist als team samen een weg wil bepalen. Je zou ze misschien het liefst uit je team halen. Want wat heb je aan ze?

Agile en Scrum saboteurs zijn, naar mijn ervaring, meestal geen mensen die niets geven om werk, team, project of bedrijf. Het zijn vaak mensen, die hun werk werkelijk met passie uitvoeren. En zeer regelmatig hier ook erg goed in zijn. Ze willen goed werk leveren, op een snelle, efficiënte en effectieve manier. Ze willen hun beloftes nakomen. Ze willen ook vaak het beste voor het bedrijf en het team. Hoe ik dat allemaal zo durf te beweren? De mensen, die vaak echt als saboteurs worden beschouwd, zijn de mensen die hun mond opentrekken. Of, netter gezegd, mensen die hun mening naar voren brengen. Mensen, die proberen problemen en risico's naar voren te brengen. Zaken die het bedrijf, het team of het project in gevaar kunnen brengen. Hun toon mag soms erg negatief zijn, hun doel is meestal echt niet om het bedrijf, team of project kapot te maken.

De uitdaging (en ja, het is echt een uitdaging) is om erachter te komen wat de problemen en risico's zijn, die de saboteur ziet. En de nog grotere uitdaging is om hun problemen en risico's op te vangen met behulp van Agile en Scrum. Want alleen als je hun tegenstanders, Agile en Scrum, gebruikt om hun pijnpunten op te lossen, zullen ze echt gaan beseffen wat de kracht hiervan is. Wat voor jou het voordeel is? Het opent je ogen voor zwakke punten in de organisatie, project, proces en team. Zaken, die je zelf gemist hebt.

Maar genoeg theorie, hoe kan dit nou in de praktijk werken?

Testweigerende programmeurs - Verwachtingen tegenstrijdig met Scrum of Agile

Een tester is regelmatig de enige tester in het team. Omdat je als team zo veel mogelijk onafhankelijk wil zijn van niet-teamleden, wordt het testen binnen het team gedaan. Door de tester dus. Maar die gaat ook wel eens op vakantie of is ziek. Om het werk dan niet stil te laten liggen, is het geen rare verwachting, dat er binnen het team bereidheid is om het testwerk over te nemen. Maar bijna elke tester, die dit geprobeerd heeft, is wel tegen een of meerdere teamleden aangelopen, die weigeren te testen. Dat is hun werk niet, zij zijn programmeurs. En het multidisciplinaire aspect doet ze eigenlijk niets.

Terug naar de bron

Scrum wordt vaak ingevoerd in een situatie waarin management of klant ontevreden is over deadline en planning. Niet alleen duurt het heel lang, voordat problemen en wensen worden opgelost. Te vaak is dat ook nog eens veel later dan beloofd. Een methode, waarbij elke twee of drie weken standaard problemen worden opgelost en wensen worden vervuld, lijkt dan ook de ideale oplossing voor de planningsproblemen.

Probleem is dat bij de start van Scrum de klant en/of de manager vaak al ongeduldig is geworden. Hij wacht al vrij lang en heeft vrij weinig gekregen. Dus eigenlijk wil hij zoveel mogelijk, zo snel mogelijk. En dat wordt ook uitgestraald. Nu Scrum is ingevoerd, moet er snel resultaat komen. En het liefst zo veel mogelijk. Zodat de managers en de klanten tevreden kunnen worden gesteld.

Om zoveel mogelijk zo snel mogelijk op te leveren, is het het handigste om de mensen te laten doen, waar ze goed in zijn. Dan kunnen ze veel werk leveren in weinig tijd. En vaak met een goede kwaliteit. Is het dan vreemd dat mensen, bij zulke verwachtingen, eisen dat hun werk op hun eigen specialistische gebied ligt? Ze voelen tenslotte ook de druk om snel veel werk op te leveren. En als ze mogen doen waar ze goed in zijn, dan kunnen ze het beste helpen aan deze verwachting te voldoen.

Scrum heeft echter bewust niet als doel om zo snel mogelijk zo veel mogelijk op te leveren. Iedereen weet ook dat dit vaak een garantie is tot slechte kwaliteit, waardoor je later nog meer problemen krijgt. Bijvoorbeeld ongeplande uitloop van je project. Of een product, wat niet voldoet aan de eisen van de klant. Het doel van Scrum is veel meer om het belangrijkste het eerst op te leveren. En een flink stuk sneller dan het opgeleverd zou zijn met een waterval project. Waardoor de belangrijkste problemen eerder opgelost zijn en de belangrijkste nieuwe functionaliteit eerder geld op kan gaan leveren. Het feit dat de zaken die het meeste geld kosten, het meeste geld opleveren of de grootste problemen veroorzaken, snel worden opgelost, dat is wat managers en klanten tevreden moet stellen. En juist door de druk van "zo snel mogelijk zo veel mogelijk" weg te halen, kan een team veel beter garanderen dat de kwaliteit in orde is. Wat uitloop of ontevredenheid weer voorkomt.

Controleren of de kwaliteit op orde is, doe je onder andere door te testen. Ook als een tester ziek of op vakantie is. Want als niet alles getest is, kan het belangrijkste niet volledig worden opgeleverd. Je weet tenslotte niet of het goed is. Waardoor je alsnog de manager of klant teleurstelt. En de druk op het team nog hoger wordt. Testen dus, ongeacht vakanties of ziektes. Alles om klant en manager tevreden te houden.

De nutteloze stand-up - Schijnbetrokkenheid

Bijna elke Agile tester heeft ermee te maken: de stand-up. Elke dag, als je geluk hebt tenminste, een kwartier informatie uitwisselen. En bijna elk scrumteam wat ik heb gekend, heeft wel een of meerdere personen gehad die het nut in twijfel trokken. Kan je de tijd van een nutteloze stand-up niet veel beter besteden aan het bouwen van nieuwe functionaliteit?

Agile en Scrum zijn beiden voor het afschaffen van nutteloze zaken: nutteloze documentatie moet je niet schrijven en nutteloze overleggen moet je niet voeren. De eis om een nutteloze stand-up meeting af te schaffen is daarmee misschien niet eens zo tegenstrijdig met Agile en Scrum. En, helaas, moet ik toegeven dat veel stand-up meetings vaak ook nutteloos zijn. Iedereen vertelt wat die gaat doen en heeft gedaan en vervolgens weer aan het werk. Informatie, die je ook wel uit het Scrumboard kan halen. Daar heb je geen meeting voor nodig. Dus, vanuit dat oogpunt, is afschaffen eigenlijk de beste optie.

Terug naar de bron

Planningssessies hebben regelmatig dezelfde aanpak: de Scrummaster bepaalt hoeveel het team in de sprint aankan en de Productowner bepaalt wat er in de sprint wordt opgenomen. Het team mag, als het geluk heeft, zeggen dat de planning haalbaar is. Maar eigenlijk is "Ja" het enige juiste antwoord. Hoe zwaar een story is, hebben de teamleden tenslotte zelf bepaalt. De Scrummaster weet, met zijn ervaring, echt wel goed te bepalen wat een team aankan. En de Productowner weet, door zijn contacten met klanten en managers, toch het beste wat belangrijk is. Wel wordt verwacht dat die "Ja" voldoende is om volledige commitment van het team te krijgen. Maar wat er in de sprint zit, is toch eigenlijk 90% van de planning. Als 90% van de planning het team wordt opgelegd, is het dan vreemd dat de betrokkenheid bij de planning laag is? En dat daardoor de commitment ook niet zoveel voorstelt?

De Stand-up heeft als belangrijkste doel om de commitment op het halen van de sprint na te gaan. Als deze commitment slechts schijn is, dan wordt de stand-up dat al snel ook. Als de teamleden zich niet betrokken voelen bij de planning, gaan ze bij de stand-up ook niet kritisch op de planning letten. Als Scrummaster en Productowner samen de planning hebben bepaalt, houden ze deze ook maar zelf in de gaten. Het is tenslotte hun planning. Is deze redenering zo vreemd?

Agile en Scrum-experts zijn altijd voor gezamenlijke overleggen en besluiten. Het heeft zeker nut als testers meepraten over hele technische onderwerpen. En experts van de back-end kunnen best input geven over onderwerpen van de front-end. Maar te veel Agile en Scrum-experts maken hier een hele grote uitzondering op: Agile en Scrum onderwerpen. Het is echt niet mogelijk dat iemand met geen tot weinig kennis van Agile en Scrum serieus mee kan praten over de beste manier om Agile en Scrum toe te passen in het team. Het bepalen van de workload in de sprint en de op te pakken story's zijn onderwerpen waarvoor echt Scrum kennis nodig is. Anders kan je dat echt niet. Dat moet je dus aan de experts overlaten. Ben je dat niet, dan moet je erop vertrouwen dat ze hun werk goed doen.

Het spijt me zeer voor de experts, maar ook het bepalen van de workload en de inhoud van de sprint is een teamverantwoordelijkheid. Een waarover ook Agile- en Scrum dummies mogen meepraten. Zelfs moeten meepraten. Misschien weten ze niet hoe een Velocity chart werkt. Maar ze weten misschien wel dat Pietje, die deze sprint op vakantie is, helaas als enige verstand heeft van database X. En dat story Y daarom in deze sprint nooit opgepakt kan worden, want daarvoor zijn veel aanpassingen in database X nodig. En ze kunnen zich misschien ook herinneren dat Jantje deze week een cursus heeft. Iets wat vergeten is bij het bepalen van de beschikbaarheid. Hoe goed Scrummaster en Productowner ook zijn, ook zij vergeten wel is wat.

Dit meepraten maakt de planning ook meteen veel meer een teamactiviteit. Nu wordt 90% van de planning met instemming van het team gemaakt. Het draagvlak voor de planning is hoger en de commitment is oprechter. Het team zal daardoor automatisch meer inzet tonen om te sprint te halen. En hierdoor eerder de neiging hebben om kritisch naar elkaars planning te kijken. Ook zullen problemen, die ze zelf tegenkomen, sneller aangekaart worden, om de planning niet in gevaar te brengen. De beste manier om deze communicatie te groeperen: elke dag een kwartiertje bij elkaar komen om dit soort zaken te bespreken. Even zeggen wat je hebt gedaan, gaat doen en tegen welke problemen je aanloopt. Even controleren of er niet iemand al 3 dagen zegt met hetzelfde bezig te zijn, terwijl de klus slechts 1 dag zou duren. Even kort vragen of dit niet besproken moet worden. Of de planning nu niet aangepast moet worden. Even kort bespreken hoe problemen aangepakt gaan worden, zodat ze de planning niet in gevaar brengen. Of bespreken wat voor effect deze op de planning hebben. Iedereen wil nu de sprint halen. En dat maakt meteen de stand-up een stuk nuttiger voor iedereen.

De nooit gevolgde Definition of Done - Te veel eisen in een keer

Bijna elke tester, die geeft om kwaliteit, zal de Definition of Done al vrij snel een belangrijk document vinden. Toch komt het regelmatig voor dat de Defnition of Done wel aanwezig is, maar dat opgeleverde story's regelmatig niet helemaal aan de Definition of Done voldoen. Als je dit na gaat vragen, krijg je als antwoord: "Ja, maar daar had ik echt geen tijd voor. " En als je daar tegenin brengt: "Maar dit hebben we afgesproken.", kan je als antwoord krijgen: "Ja, wat wil je nu? Wil je dat ik mijn werk op tijd afrond? Wil je de sprint halen? Of wil je dat ik ontzettend veel tijd steek in dit ene puntje? Wat vind je nu belangrijker? We willen de sprint toch halen? Nou, dan moet je niet zo moeilijk doen over dit puntje van de Definition of Done."

Terug naar de bron

Bij de Defnition of Done wordt vaak uitgaan van de gewenste situatie. Of het is een kopie van een Definition of Done opgesteld bij een ander bedrijf of een Scrum expert. Deze gaan vaak uit van een meer ervaren Scrum organisatie, die ook meer aankan. Op zich begrijpelijk, want het streven is goed.

Het probleem is echter het volgende: Als men leert jongeleren, is het besef dat men eerst moet leren om drie ballen in de lucht te houden. En dat is al een uitdaging, die veel tijd kost. Pas daarna gaat men naar steeds meer ballen. Of naar gevaarlijkere objecten als zwaarden of vuur. Maar als men een Definition of Done invoert, probeert men meteen 10 tot 20 eisen in de lucht te houden. Waarvan sommige zeer gevaarlijk zijn, omdat ze veel tijd kosten. En niemand wil uitleggen waarom de invoering van een Definition of Done leidt tot een halvering van het aantal haalbare storypoints per sprint. Of een bepaalde story qua storypoints plotseling twee keer zo zwaar is. Je kan eigenlijk zeggen dat men voor het in de lucht houden het aantal eisen terugbrengt tot een haalbaar aantal. Geen onlogisch besluit toch? Beter drie eisen in de lucht, dan alle eisen op de grond.

Voor de Definition of Done moet dan ook niet gekeken worden naar een ideaal of een Definition of Done van een te hoog volwassenheidsniveau. De Definition of Done moet onder alle omstandigheden haalbaar zijn. En hier moet ook iedereen van overtuigd zijn. Als een logische eis, bijvoorbeeld unittesten schrijven, nog niet haalbaar is, laat hem weg. Besteed aan de ene kant dan tijd en story's om een goede basis voor unittesten op te zetten en hier goede afspraken over te maken. En vertrouw er aan de andere kant op, dat andere eisen in de Definition of Done uiteindelijk zorgen voor een beter product of beter proces. Hierdoor krijg je vertrouwen, waardoor je meer tijd kan gaan besteden aan deze eisen. En je weer nieuwe eisen kan toevoegen.

Dus wat moet je doen bij saboteurs?

Bovenstaande zijn voorbeelden. Wel gebaseerd op mijn praktijk ervaringen, maar zeker niet direct van toepassing op alle situaties. Zelfs niet soortgelijke situaties. Waar het om gaat, is dat je probeert erachter te komen welke problemen en risico's saboteurs zien. En deze problemen en risico's serieus neemt. Probeer de ander er niet van te overtuigen dat de problemen en risico's er niet zijn. En kom zeker niet met het argument: "Maar Scrum/Agile werkt zo, dus we doen het zo."

Kijk naar de genoemde problemen en risico's. Kijk vervolgens naar welke personen. middelen of afspraken binnen Scrum en Agile dit probleem zouden moeten oplossen of het risico zouden moeten voorkomen. Kijk wat bij deze personen, middelen of afspraken beter kan worden, zodat de genoemde problemen worden opgelost of risico's worden voorkomen. En durf daarbij ook kritisch naar jezelf te kijken. Overleg met de saboteur of je aanpassing inderdaad zou helpen. Leg daarbij ook zeer duidelijk uit welk aspect van Scrum of Agile je gebruikt om de situatie aan te pakken. Dit om Scrum en Agile niet als vijand te tonen, maar als vriend.

Als de saboteur akkoord is, leg dan de aanpassing voor aan het hele team. Vertel waarom je de aanpassing wil doorvoeren. En vraag feedback. Staat er een nieuwe saboteur op, pak dit dan weer opnieuw op de juiste wijze op. Want ook nu blijft: het hele team moet erachter staan. Niet alleen jij en de saboteur.

Hoewel dit misschien werk van de Scrummaster lijkt, kan iedereen dit doen. Tenslotte ben je als heel team altijd verantwoordelijk voor het hele proces. Het kan echter wel verstandig zijn de Scrummaster hierbij te betrekken. Misschien wil de Scrummaster bij een bepaalt deel aanwezig zijn. En het heeft zeker grote voordelen als de Scrummaster al achter de aanpassing staat.

Veel sterkte en succes!!

Exploritory Test Automation - Al lerend automatiseren

Hoe ga je testen automatiseren als je de applicatie niet kent? Als het domein nog nieuw voor je is? Als er geen testscripts zijn? Kan je wel automatiseren, als je zelf nog bijna niets weet? Zonder minimaal een half jaar nodig te hebben om de eerste geautomatiseerde test op te leveren? Of anders gezegd: kan leren en automatiseren tegelijkertijd? Of nog sterker: Kan testautomatisering je helpen bij het leren kennen van een applicatie?

Iedere tester zal wel te maken hebben gehad met een applicatie, waar ze geen kennis van hebben. Vaak een ideale kans om te bewijzen dat een tester werkelijk een meerwaarde is. Je leest je in, je vraagt, je probeert datgene wat je moet testen ook echt te snappen. Daarna bepaal je wat je wil testen en hoe. En je test.

Bij testautomatisering gaat we er echter vaak van uit, dat deze kennis al beschikbaar is. Je hebt het al een keer getest, of anders heeft een collega al gedaan. Die kennis staat bij voorkeur op papier, maar is in ieder geval beschikbaar. De kennis is daarmee toetsbaar en geschikt om te automatiseren. Hoe Agile we ook zijn en denken, "Lever regelmatig werkende geautomatiseerde testen op" is zeker niet iets wat haalbaar lijkt, als je start bij 0% kennis en 0% geautomatiseerde testen of testscripts.

De start - breng je eisen naar beneden

Een van de moeilijkste zaken is om je eisen voor testautomatisering naar beneden te brengen. Je weet niet alles, dus je kan nog niet alles testen, dus je kan nog niet alles automatiseren. Probeer dat dan ook niet. Je start moet iets zijn wat je wel weet, hoe zinloos die automatische test ook mag lijken. Het enige doel is een basis neer te zetten, die je daarna, al lerend, uit kan bouwen.

Stel je hebt een invoerscherm voor een medewerker met 100 velden, waarvoor wel het een en ander aan business logica wordt uitgevoerd. Bijvoorbeeld berekeningen of velden die verschijnen en verdwijnen. Om voor dit scherm te starten met de testautomatisering, is het niet nodig alle regels en voorwaarden al te kennen. 

Start met een test waarbij een nieuwe medewerker wordt aangemaakt, alleen de verplichte velden gevuld worden en sla de medewerker op. Open de medewerker hierna opnieuw en controleer of de verplichte velden correct zijn. Nee, dit lijkt waarschijnlijk geen zinvolle geautomatiseerde test. Je test bijna niets. Maar de kennis heb je al. Of kan je vrij eenvoudig achterhalen. De meerwaarde mag klein zijn, maar er is een meerwaarde. En de test werkt.

Het vervolg - Automatiseer stapje voor stapje

Als je eenmaal een basis hebt, is het verstandig om vervolgstappen te bepalen. Ook hiervoor geldt: hou je eisen laag. Als er 100 velden zijn, probeer ze dan niet meteen alle 100 te automatiseren. En als je een salarisberekening wil testen, probeer dan niet meteen alle mogelijkheden voor het salaris te automatiseren. Maak zo klein mogelijke stappen, die wel duidelijk herkenbaar zijn. 

Zo staan velden in je scherm vaak in groepen ingedeeld. Automatiseer dan bijvoorbeeld per groep. En de gegevens voor een berekening zijn ook vaak in groepen in te delen. Bij salaris zijn dit bijvoorbeeld: brutosalaris, berekening van loonheffing en eventuele extra inhoudingen. Automatiseer dan ook hier per groep en houdt voor de andere gegevens de standaard waardes aan of nog liever: zet ze in eerste instantie op 0. Dus bijvoorbeeld eerst de controle van het salaris als er geen loonheffing is en geen extra inhoudingen. Daarna het salaris, waar de loonheffing wordt ingehouden, maar er nog geen extra inhoudingen zijn. En daarna nog extra inhoudingen toevoegen.

Elke keer test je weer een deel extra functionaliteit. Het eindresultaat lijkt nog niet altijd zinvol, omdat de situatie niet erg realistisch is (salaris zonder loonheffing?). Maar je weet wel dat de toegevoegde functionaliteit werkt.

Hoe gebruik je de stappen nu om te leren?

Je doel wordt nu niet om alles in een keer te leren, om alles in een keer te automatiseren. Je doel wordt, elke groep opnieuw, om alles over deze groep gegevens of deelberekening te leren. En het effect wat deze hebben op het al geautomatiseerde deel. Dit maakt je stap om te leren een stuk kleiner en daarmee kan je sneller verder met automatiseren. Onderzoek en leer, tot je voldoende weet voor de stap, waar je mee bezig bent. En automatiseer deze vervolgens in je bestaande testcases. Breidt dus bij voorkeur bestaande testcases uit, maak geen nieuwe. Want juist de relaties tussen deze groepen is interessant om te testen.

Wel belangrijk: automatiseer alle velden. Dus als er in het scherm read-only velden staan zonder waarde, controleer ze allemaal. Hebben ze altijd dezelfde waarde, controleer ze toch. Mits ze binnen je te automatiseren stap vallen natuurlijk.

Wat voor effect kan er nu gaan ontstaan? Na of tijdens het automatiseren van je testen, kom je erachter dat je test faalt. En niet altijd op een logische manier. Ja, als je een naam van een medewerker invoert en deze wordt niet opgeslagen, dan is er duidelijk een fout gevonden. Maar je bent eigenlijk het veld "Aantal openstaande vakantiedagen" aan het automatiseren. En plotseling is deze bij een van je testcases twee dagen hoger. Is dit fout of is dit goed?

Als je dit tegenkomt is het belangrijk om net zo lang door te zoeken, leren, vragen tot je het antwoord op deze vraag weet. Maar nog belangrijker: zorg ervoor dat je snapt waarom dit goed of fout is. Dan kan je erachter komen, dat in je testcase de medewerker ouder dan 50 is. En dat medewerkers boven de 50 automatisch twee vakantiedagen meer hebben.

Of  een ander voorbeeld: je dacht dat het veldje "einddatum" alleen werd gevuld bij het beëindigen van een dienstverband. Die stap is nog niet geautomatiseerd. Maar plotseling staat er wel een datum. Blijkt dat bij het wijzigen van een functie, en dat was je wel aan het automatiseren, ook een einddatum wordt vastgelegd. En daar is dan ook de reden om alle velden mee te automatiseren, ook al lijkt het zinloos. Je kan juist zo altijd achter een onverwachts effect komen.

De vervolgstap is nu wel vrij logisch. Als het fout is, laat het oplossen. Als het goed is, pas je testen erop aan.

Dus hoe kan je al lerend automatiseren

Voor Exploritory Test Automation volg je dus de volgende stappen:

1. Automatiseer een basisstap en houdt die zo klein mogelijk
2. Bepaal de vervolgstappen en automatiseer deze per stap
3. Probeer voor het automatiseren van deze stap alles over dit deel te leren
4. Leer tijdens het automatiseren alles wat nodig is om de onverwachte bevindingen bij het automatiseren van de testen op te lossen

Zo kan je automatiseren en leren tegelijkertijd. En kan de testautomatisering misschien zelfs helpen om nog meer te leren.

Testen doe je bij.... de foutenloterij

Testen, zeker handmatig testen, kost soms veel tijd. Je komt vervolgens 25 keer langs hetzelfde scherm. Een scherm, dat je steeds opnieuw weer moet invoeren. Heeft niet bijna iedere tester in zijn of haar hoofd een standaard adres voor adresformulieren? Een standaard bestelling voor een webshop? Of andere standaard gegevens, die je keer op keer opnieuw invoert? Hoe logisch! Maar besef je het gevaar ook?

Testen is regelmatig als een soort van loterij. Je voert gegevens in, voert handelingen uit en je hoopt zoveel mogelijk prijzen te winnen. Oftewel om zoveel mogelijk fouten te vinden. Hoe groter de fout, hoe trotser je bent. Maar grote fouten hebben vaak iets gemeen met grote prijzen in een loterij: hoe groter de prijs, hoe groter vaak de geluksfactor. Je moet bepaalde gegevens invoeren, bepaalde handelingen uitvoeren of nog erger: een combinatie van die twee. Als je dat niet doet, kom je die betreffende fout niet tegen.

De geluksfactor is echter te vergroten. Je standaard gegevens zijn al zo vaak ingevoerd. De kans dat je hiermee nog een fout vindt, is erg klein. Ja, de kans is aanwezig. Elke oplevering is tenslotte weer een nieuwe loterij. Toch zal het snel zeer verstandig zijn om je gegevens meer te variëren. Ondanks de extra tijd die dat kost.

Om dit duidelijk te maken, ga ik testen even nog meer benaderen als een loterij. Stel je hebt de cijfers 0 t/m 10 en een van deze tien cijfers gaat fout.

 

Stel nu dat je in al je testen steeds hetzelfde cijfer kiest. Je hebt dan 10% kans om de fout te vinden. Als je twee cijfers gebruikt tijdens je testen, is je kans echter al 20%. En als je 10 testcases hebt (iets wat zeker geen onrealistische situatie is) en je kiest elke keer een ander cijfer, is je kans om de fout te vinden gewoon 100%.

Varieer daarom je gegevens tijdens het testen. Dit vergroot echt al heel snel je kans op het vinden van fouten. Want hoewel de software bij cijfer 1 misschien hetzelfde zou moeten werken als bij cijfer 6, heeft niet iedere tester meegemaakt dat dit te vaak toch niet het geval is?

Ook de klant wil kwaliteit....

Misschien ken je het proces. Er komen veel fouten binnen, die aangegeven worden door klanten. De klant is belangrijk, dus deze fouten moeten zo snel mogelijk opgelost worden. In de backlog wordt weer van alles naar beneden geschoven om ruimte vrij te maken voor de fouten. Ook zaken, die voor een applicatie met een hogere kwaliteit zouden moeten zorgen. Ondanks het feit dat juist de lagere kwaliteit zorgt voor deze situatie. Het lijkt er sterk op, dat je steeds moet kiezen tussen de klant en kwaliteit. En de klant wint meestal. De rest komt later.

Daarnaast gebeurt er regelmatig het volgende: het uitstellen wordt goedgepraat. We doen namelijk wat de klant het liefste wil: de fouten die hij tegenkomt oplossen. Andere fouten: fouten gevonden door testers, door ontwikkelaars; ze zijn daarom minder belangrijk. Want de klant geeft het niet aan. Verbetertrajecten, het mag, maar eerst doen wat de klant wil. Met als toppunt: als de klant wil dat deze fout opgelost wordt, dan laat deze het ons toch wel weten?

Er is geen klant, die alles meldt
Het werken aan een fout kost tijd, dat snappen we. Maar staan we er ook bij stil dat het de klant ook tijd kost? Hoe hard het ook klinkt: hoe meer fouten je applicatie bevat; hoe kleiner percentage fouten dat je te horen krijgt. Klanten besteden zeker op zo'n moment hun tijd liever aan de fouten, die ze in hun werk belemmeren. Maar het is wel het totale zicht op de fouten, die bepalen hoe een klant over een product denkt.

Als een scherm twee knoppen heeft om op te slaan en een ervan geeft een grote foutmelding, dan zal dit niet altijd worden doorgegeven. Er werkt nog een knop. Als iemand al heel veel fouten hebt doorgegeven, laat hij het daarbij. Hij is tenslotte niet de tester. En hij kan doorwerken. Dat zegt niet dat hij de fout niet ernstig vindt. Het zegt alleen, dat het hem niet in zijn werk belemmerd.

Eeuwige cyclus
Daarnaast is er nog het volgende probleem: als je alleen je tijd besteed aan datgene wat je klant meldt, kan je in een eeuwige cyclus terechtkomen. Je bent zoveel tijd kwijt aan het oplossen van klantproblemen, dat je geen tijd vrij kan maken voor andere verbeterzaken. Hierdoor kom je steeds niet toe aan het verbeteren van je testproces, juist nodig om deze cyclus te doorbreken. Bugs zijn vaak ook nog eens moeilijker in te plannen, zodat je sprint eerder niet gehaald wordt. En doordat er steeds nieuwe fouten hoog op de backlog geplaatst worden, lijkt het wel of je nooit een stap verder komt in de backlog. De klant is vervolgens ontevreden over planning en over de kwaliteit. Waardoor het nog belangrijker wordt om de klant tevreden te stellen. Dus fouten die de klant meldt, moeten zeker dan zo snel mogelijk opgepakt worden. Waarna het weer overnieuw begint.....

Maar wat dan?
Het klinkt eenvoudig: verbeter je testproces en begin vandaag! Maar ik weet al wat de reactie is: dat wil ik wel, maar daar heb ik de tijd niet voor. Ja, ik weet dat ik regressietesten moet hebben en uitvoeren. Maar een complete regressietestset kost veel tijd. Die heb ik niet. Ja, ik weet dat ik eigenlijk de hele applicatie een keer goed zou moeten testen. Maar dat kost tijd, die ik niet heb. En zelfs al zou ik de tijd hebben. De bevindingen die uit het testen komen, die kunnen niet opgepakt worden. Fouten van de klant gaan voor, voor andere fouten is geen tijd.

Prioriteer alsof de klant ze meldt
Het belangrijkste is om de prioritering aan te passen. Het feit dat een klant ze meldt, mag niet de belangrijkste rol spelen in de prioritering. Natuurlijk, hoe belangrijk het voor een klant is, bepaalt sterk hoe snel een bug opgelost moet worden. Maar ga er niet automatisch van uit, dat alleen datgene wat gemeld wordt voor de klant belangrijk is. Ik heb al eerder geschreven, dat klanten best wel eens ernstige fouten, die ze tegenkomen, zullen verzwijgen. Maar daarnaast: wil je afwachten tot de klant ze wel vindt? Daarom is voor de prioritering het volgende van belang: prioriteer elke bug alsof deze door de klant gemeld is. Hoe zou je de bug prioriteren als deze van de klant afkwam? Dat is dan ook de prioriteit die de bug moet krijgen.

Test ruimer
Mijn ervaring is, dat waar een bug wordt gevonden, vaak soortgelijke bugs in de buurt zitten. Stel je je hebt een scherm met 100 velden. En veld 81 wordt niet opgeslagen. Regelmatig worden dan meerdere velden niet opgeslagen. En zeer regelmatig liggen ze bij veld 81 in de buurt. Als je een bug krijgt, test daarom ruimer dan de fout zelf. Test minimaal alle velden in de groep gegevens, waar het veld bijhoort. Test bij voorkeur alle velden in het hele scherm, als dit niet veel extra tijd kost.

Als in een deel van de business logica 1 fout gevonden is, test dan bij voorkeur alle regels. Dus als bijvoorbeeld de korting niet goed berekend wordt, test dan ook of de totaalprijs, het subtotaal, de BTW, de bezorgkosten, enz. wel goed berekend worden. En als de korting voor 65+  te weinig is, kijk dan of de korting voor andere mogelijke kortingen wel goed gaan.

Wat je reden is: waar iets fout gaat, gaat vaak meer fout. En als deze fout belangrijk genoeg is om op te lossen, zijn soortgelijke fouten belangrijk genoeg om te vinden. Om het niet teveel tijd te laten kosten, kan je het langzaamaan uitbreiden. Test bijvoorbeeld eerst de groep gegevens. Breidt dit uit tot het hele scherm, zodra de vorige testen geaccepteerd zijn of minder tijd kosten. En daarna tot meerdere soortgelijke schermen.

In een deel van de business logica kan je eerst de regels testen, die dezelfde gegevens gebruiken als je bug. Dat is uit te breiden naar de regels, die een van beide gegevens gebruikt. Tot alle regels over hetzelfde onderwerp. Dus bijvoorbeeld eerst alleen alle mogelijke vervoerskortingen voor 65+. Daarna alle mogelijke vervoerskortingen voor alle leeftijdscategorieën. Dan alle mogelijke kortingen voor alle leeftijdscategorieën.

Begin met regressietesten
Voor de zekerheid: regressietesten is belangrijker dan automatisch testen. Dus als automatisering niet kan, begin handmatig. Maar als iets bekend staat om de vele tijd die het kost, is het wel handmatig regressietesten. Enkel al het opstellen van deze testen kost heel veel tijd. Hoe kan je hier ooit aan beginnen?

Ook hiervoor geldt: dit kan stapje voor stapje. Als er een blokkerende fout gevonden wordt, schrijf dan een regressietest die deze blokkerende fout voorkomt. En bij voorkeur soortgelijke fouten, maar in ieder geval deze fout. Voer deze test ook elke sprint uit. Belangrijkste argument: als deze fout belangrijk genoeg is om zo hoog ingepland te worden, is het belangrijk genoeg om deze fout voor de klant te voorkomen.

Begin met regressietesten om de blokkerende fouten te voorkomen. Breidt deze daarna uit om de kritieke fouten (criticals) te voorkomen. En, als men enthousiast wordt, breidt hem uit naar de grote fouten (major). Als je handmatige regressietesten uitvoert, stop hier dan. Verder uitbreiden van je regressietesten kost vaak meer tijd, dan het oplevert. Bij testautomatisering kan je daarna nog verder gaan.

Maak de klant blij: verbeter je kwaliteit
Onthoudt dus dat de klant meer kwaliteit verwacht, dan de fouten die hij meldt. Werk daarom niet alleen aan de fouten, die de klant meldt. Werk ook aan fouten, die door andere gemeld worden. En behandel deze fouten allemaal gelijk. Test ruimer, om soortgelijke fouten te voorkomen. Zodat de klant ze niet zal vinden. En begin met regressietesten, om de grootste fouten te voorkomen. Zodat ze niet opnieuw bij de klant terecht komen. Hoewel dit in het begin misschien meer tijd kost, doorbreek je zo stap voor stap wel de negatieve kwaliteitscyclus. En daar worden uiteindelijk zowel jij als de klant blij van!

Besluiten op basis van het "Vier wielen argument"

Hoe neem je een goed besluit? Je wilt een auto, maar niet meer vier wielen. Want vier wielen betekent een 4x zo grote kans op een lekke band. Dus wil je minder dan 4 wielen. Logisch toch? Of je vindt stabiliteit van een auto belangrijk, dus moet de auto minimaal vier wielen hebben. De auto, waar je nu naar kijkt heeft vier wielen. Een duidelijk pluspunt. Logisch toch? Nee, natuurlijk niet. Toch zie ik regelmatig in het testvak dat soortgelijke redeneringen worden gemaakt. Een auto vinden zonder vier wielen zal vast wel lukken, maar maakt de zoektocht onnodig moeilijk. Het allergrootste deel van de auto's heeft nu eenmaal vier wielen. Dat weten we. En daar ligt vaak het probleem: dit soort redeneringen gebeuren alleen als we van een onderwerp eigenlijk te weinig kennis hebben om goede besluiten te nemen. Bij testen voornamelijk op het gebied van ...... testautomatisering en testtools. Wat er zoal gebeurt? Kiezen voor een tool waarbij meteen alles geautomatiseerd wordt: testtechnieken, testscriptbeheer, testautomatisering. Want dit scheelt tijd. Terwijl je nu als bedrijf niet de tijd en/of kennis hebt om handmatige regressietesten te schrijven en te beheren. Dan ga je zeker niet de tijd en/of kennis hebben om alles automatisch te beheren. Niet kiezen voor een automatiseringstool, omdat bij de record-and-play functionaliteit, de opgenomen test later bij Play niet vlekkeloos verloopt. Tja, record-and-play staat bekend om dat soort problemen. Dat is een algemeen probleem, niet specifiek voor een bepaald tool. Kiezen voor een bepaald tool dat de kwaliteit van de website niet alleen meet, maar ook goede verbetersuggesties geeft. Maar deze adviezen worden eigenlijk door de meeste soortgelijke tools gegeven, omdat ze een deel zijn van de gekozen meetmethode, niet van de gekozen tool. En veel tools gebruiken dezelfde standaard meetmethode, dus inclusief bijbehorende suggesties en adviezen. Deze voorbeelden heb ik zelf in de praktijk meegemaakt. Dus ze komen voor. En ik denk dat velen wel andere voorbeelden kunnen aandragen.

Wat is het probleem?

Er blijft nu eenmaal altijd wel ergens een bedrijf dat met testautomatisering begint. Of een bedrijf wat op een ander gebied een tool gaat inzetten om het testen te vergemakkelijken. Daar is natuurlijk niets mis mee. Maar op een of andere wijze hebben dit soort belangrijke keuzes te vaak dezelfde kenmerken. Er is slechts 1 optie Zeggen we ja of nee tegen keuze A? Het idee is namelijk afkomstig van een leverancier, die belde met een goede optie. Of iemand in het bedrijf heeft goede ervaringen met deze mogelijkheid bij een vorig bedrijf. Of het is gewoon de keuze die het best bekend staat in de markt. Geen kennis aanwezig of ingehuurd Er is geen tijd of geld om een externe deskundige in te huren, die op basis van kennis en ervaring een gefundeerde keuze kan maken. Daarom moet je het doen met de middelen/testers, die je tot je beschikking hebt. Mensen die soms nauwelijks kennis hebben van het onderwerp en/of de tools die hiervoor beschikbaar zijn. De keuze moet snel gemaakt worden Tijd besteden aan zaken, die niet direct geld opleveren; men doet het liever niet. Daarnaast wordt de verandering als belangrijk gezien, dus hoe eerder hoe beter. Tijd om meerdere opties te bekijken of om je uitgebreid te verdiepen is daarom nauwelijks beschikbaar.

Wat is de oplossing?

Als de praktijk eenvoudig was, zou de oplossing zijn: vergelijk altijd meerdere tools en neem de tijd ervoor. Of de volgende: huur altijd een expert in. Maar de praktijk is niet altijd eenvoudig, omdat je hierbij afhankelijk bent van factoren waar je geen of weinig invloed op hebt: management en beleid. Dat maakt wel dat het "Vier wielen argument" niet altijd te voorkomen zal zijn. Maar er zijn wel mogelijkheden om de kans flink te verkleinen. Mogelijkheden die weinig tijd en geld kosten. Lees artikelen over het algemene onderwerp Ga via Google op zoek naar artikelen en blogs, die het algemene onderwerp bespreken. En daarbij de problemen, die hierbij naar voren komen, onder de aandacht brengen. Let er wel op dat het onderwerp los besproken wordt. Dus een artikel dat gaat over de problemen, die je tegen kan komen bij het gebruik van Selenium bij testautomatisering, is niet geschikt. Een artikel dat gaat over problemen bij testautomatisering daarentegen wel. Dit helpt je, om na te gaan welke problemen je waarschijnlijk in elk tool tegen zal komen. Omdat ze eerder bij het onderwerp horen, dan bij het tool. Lees vergelijkingen of review sites Om een beeld te krijgen van goede argumenten om wel of niet voor een tool te kiezen, kan je gebruik maken van experts, ook als je ze niet inhuurt. Er zijn op elk gebied wel experts, die in een blog of artikel verschillende tools met elkaar vergeleken hebben. En over bijna alles kan je tegenwoordig wel reviews vinden, vaak geschreven door mensen die wel de gelegenheid hadden meerdere tools te bekijken. Je kan deze gebruiken om het oordeel over 'jouw' tool te lezen. Maar ook om te kijken welke voor- en nadelen hier genoemd worden. Deze kunnen een goede basis vormen voor de keuze, die jij zelf moet maken. Want als deze mensen deze argumenten gebruiken om te vergelijken, is de kans groter dat jij dat zelf ook veilig kan. Vergelijk met een ander gratis tool of tool met een proefperiode Als je wel wat meer tijd hebt, maar niet het geld, kan je toch een vergelijking maken. Veel tools hebben tegenwoordig een gratis uitprobeerperiode. En daarnaast zijn van veel tools tegenwoordig ook goede, gratis en ook meerdere varianten te vinden. Zo kan je zonder extra kosten toch twee tools uitproberen. Dat maakt dat de voor- en nadelen, die jij ondervindt al vergeleken kunnen worden met de voor- en nadelen van het andere tool. Ook als deze tool helemaal geen optie is, zorgt het in ieder geval voor een betere afweging voor de keuze die je wel moet maken. "Ik ben dit probleem ook tegengekomen in tool B, dus de kans is groot dat meerdere tools dit probleem hebben" of "Tool B kan dat ook, dus dat is waarschijnlijk niet de beste afweging om voor A te kiezen".

Ideaal v.s. praktijk

Streef natuurlijk altijd naar het ideaal: meerdere tools met genoeg tijd. Maar als dit niet kan, ben je dan in ieder geval goed bewust dat de voor- en nadelen best wel eens niet specifiek voor deze tool kunnen zijn. Probeer dit op te vangen door te lezen en, als het kan, toch naar andere tools te kijken. Voorkomen is dan misschien niet mogelijk, maar de kans flink verkleinen is vaak wel een realistische optie.

100% dekking bij testen heeft zo zijn gevaren

100% code coverage. Alle eisen hebben een testcase. Er zijn verschillende manieren om na te gaan of iets 100% gedekt is tijdens het testen. En het is een van de meest eenvoudige methodes om na te gaan of de test betrouwbaar is geweest. Alleen is de vraag of de test ook werkelijk betrouwbaar is. Je kan een 100% dekking hebben van iets, maar tegelijkertijd kan de test weinig tot niets toevoegen aan je kwaliteitsgarantie. Hieronder wil ik twee voorbeelden verder uitwerken. Niet met het doel een 100% dekking als onbelangrijk af te doen. Maar wel om mensen verder te laten kijken dan alleen "Heb ik alles getest". Belangrijker is "Heb ik alles goed getest".

Het gevaar van 1 waarde

Stel je hebt een applicatie waarin persoonsgegevens worden beheert. Elke aangemaakte persoon krijgt als standaard geslacht de waarde "Man". En stel dat je nu een test bedenkt of programmeert waar een persoon wordt aangepast. En deze test bevat de volgende regel:

GESLACHT = MAN

Je wil bij deze test dus het geslacht wijzigen naar man. Daarom maak  je snel een persoon aan en ga je daarna de gegevens wijzigen. Dus van de nieuwe persoon wijzig je het geslacht van man naar man. Anders gezegd: je test eigenlijk niets. Want als de wijziging niet opgeslagen wordt, is het geslacht man. Maar als de wijziging opgeslagen wordt ook.

Waar het om gaat is, dat als je een gegeven in al je testen slechts een waarde geeft, de waarde per ongeluk  de juiste waarde kan hebben. Dit is op twee manieren te voorkomen:

1. Controleer voor de wijziging of het betreffende gegeven een een andere waarde heeft

GESLACHT <> MAN

2. Geef  het gegeven tijdens je testen twee verschillende waardes en controleer dit ook tweemaal. Dit verkleint de kans dat de gegevens per ongeluk elke keer opnieuw toch de gewenste waarde hadden.

Het gevaar van condities

Stel je hebt een applicatie waarmee je kortingen berekent. Een van de voorwaarden voor korting is de volgende

LEEFTIJD > 18 OR WOONPLAATS = UTRECHT

Een persoon krijgt dus volgens de code alleen korting als hij ouder is dan 18 en woont in Utrecht. Maar stel nu dat de persoon ook 18 jaar mag zijn, hoe haal je dit dan uit de test? En stel dat de korting eigenlijk alleen uitgevoerd mag worden als de de leeftijd 18 jaar en ouder is, maar ook de woonplaats Utrecht is?

LEEFTIJD >= 18 AND WOONPLAATS = UTRECHT

Met de volgende testcase in ieder geval niet

LEEFTIJD = 20

WOONPLAATS = UTRECHT

 Je hebt nu alles getest. De korting is toegekend. Maar de fouten zitten er nog in.

Stel nu dat je slim bent en je wilt de randgevallen testen. Randgevallen zijn in ieder geval die twee waardes die er net voor zorgen dat de uitkomst anders is. In het geval van 18 jaar en ouder zijn dat dus de leeftijden 17 en 18. De leeftijd 17 geeft geen korting, de leeftijd 18 wel. Nu komt er wel een fout naar boven. Als de leeftijd 17 is, dan krijg je alsnog korting. Verder testen zou aantonen dat ook de leeftijd 16, 15 14 en 13 alsnog korting zouden geven. Dus er moet nog uitgebreider getest worden.

Als er voorwaarden zijn, die de woorden "en" of "of"bevatten (door ontwikkelaar eerder AND of OR genoemd), is het regelmatig handig om hier meerdere testen aan te besteden. Mijn favoriete methode is het aantal condities + 1. Op de volgende wijze uitgewerkt

A AND B AND C

A = TRUE, B = TRUE, C = TRUE => Resultaat = TRUE

A = FALSE, B = TRUE, C = TRUE => Resultaat = FALSE

A = TRUE, B = FALSE, C = TRUE => Resultaat = FALSE

A = TRUE, B = TRUE, C = FALSE => Resultaat = FALSE 

Wat bij de onderste drie testcases gebeurt, is het volgende: ze verschillen slechts 1 waarde met het TRUE resultaat. Hierdoor kan je ervan uitgaan, dat als deze twee testcases het gewenste resultaat geven, het resultaat door de conditie met het verschil veroorzaakt wordt. Daarmee is die betreffende conditie 100% gedekt getest en niet alleen de volledige verzameling condities als geheel. En dat maakt de test een stuk betrouwbaarder.

En de andere variant

A OR B OR C

A = FALSE, B = FALSE, C = FALSE => Resultaat = FALSE

A = TRUE, B = FALSE, C = FALSE => Resultaat = TRUE

A = FALSE, B = TRUE, C = FALSE => Resultaat = TRUE

A = FALSE, B = FALSE, C = TRUE => Resultaat = TRUE 

Als je de grensgevallen en de AND/OR testen combineert, kom je dan op de volgende testcases uit:

LEEFTIJD = 18 AND WOONPLAATS = UTRECHT => Gewenste resultaat is korting

LEEFTIJD = 17 AND WOONPLAATS = UTRECHT => Gewenste resultaat is geen korting

LEEFTIJD = 18 AND WOONPLAATS = AMERSFOORT => Gewenste resultaat is geen korting

Wanneer alle drie slagen, dan kan je ervan uitgaan dat je de eis qua condities voldoende hebt getest.

Hoe voorkom je de "Wet van Murphy"

Soms zijn er van die momenten en dan gaat alles fout. Is net het ene fout gegaan, gaat vlak daarna het andere fout. Als tester kom je de ene na de andere fout tegen. En als de ene fout opgelost is, is er een nieuwe fout ontstaan. Zo niet meerdere fouten. Ik denk dat er bijna geen tester is, die niet een keer in zo'n periode heeft gezeten.

Hoe voorkom je dat alles wat fout kan gaan ook werkelijk fout gaat? Een van de belangrijkste oorzaken van deze situatie is tijdsdruk. Iets moet afgerond zijn voor een bepaalde datum. Dit kan het eind van een sprint zijn of een deadline. Maar het werk is eigenlijk teveel om voor deze datum af te ronden. Dus gaat iedereen op zoek naar manieren om het werk sneller op te leveren. De tijd voor het testen wordt teruggebracht, het lezen van de vastgelegde eisen gaat sneller of wordt overgeslagen. Maar om de planning te halen, moet het wel in een keer goed. Anders haal je het niet.

Voor mijzelf heb ik dit de "Happy flow planning" genoemd. Dit is een geplande werkwijze, waarbij je ervan uitgaat dat alles goed gaat. Daarom is testen en voorbereiden bijna niet nodig. En is er geen tijd nodig om problemen op te lossen. Dit vaak onder de noemer dat een zo ervaren team toch in staat moet zijn om deze klus zonder problemen op te pakken.

Maar de reden dat een ervaren team in staat is om zo'n klus zonder problemen op te pakken, is vaak dat ze niet uitgaan van een foutloos traject. Ze controleren hun eigen werk en laten het door anderen controleren. Ze lezen en bespreken, om te kijken of ze het goed hebben begrepen en hebben onthouden. Dit lijkt in eerste instantie vaak meer tijd te kosten. In de praktijk gaat dit echter sneller of even snel als de "Happy flow planning". Want bijna nooit gaat alles in een keer goed. Waardoor men een nog krappere "Happy flow planning" moet afstemmen. Met nog meer risico en stress. En vaak nog meer fouten. Resultaat: de afgesproken datum wordt niet gehaald met de afgesproken inhoud.

Wat dan? Want soms is er nu eenmaal een einddatum. En soms is er te veel werk. Nu, het belangrijkste is een goede prioritering. Plan datgene wat het belangrijkste is het eerst, maar voer deze activiteiten wel goed uit. Hierbij kan je denken aan onderdelen van een applicatie, bijvoorbeeld eerst zoeken op naam, daarna zoeken op postcode. Maar je kan hier ook denken aan het prioriteren van activiteiten. Denk dan wel aan activiteiten, die de kwaliteit niet in gevaar brengen. En ja, vaak zijn dit toch testactiviteiten. Is het sneller om handmatig te testen, dan automatisch? Test dan handmatig. Is het sneller om de tester te laten testen, dan om een ontwikkelaar te laten testen? Laat de tester testen. Is het sneller om een ontwikkelaar te laten testen, dan een tester te laten testen? Laat een ontwikkelaar testen. Kan je even zonder documentatie, stel het uit.

Het beste is en blijft de functionaliteit zo afspreken dat de einddatum geen probleem is. Maar als dit niet kan, bezuinig dan niet op activiteiten die juist helpen om te garanderen dat de afgesproken einddatum gehaald wordt. Ook al lijkt dit overbodige tijd. Blijf je eigen werk minimaal 1 keer controleren. Laat je werk minimaal 1 keer door iemand anders controleren. En blijf nagaan of je alles goed begrepen hebt. Houdt altijd minimaal deze eisen aan en kijk waar je kan bezuinigen op de rest.

En laat deze situatie een uitzondering blijven. Want als dit vaker voorkomt, kan je doen wat je wil. Maar de "Wet van Murphy" zal uiteindelijk toeslaan. Ook de uitgestelde activiteiten hebben tenslotte hun meerwaarde. Dus op de lange termijn gaat het problemen geven als je ze blijft overslaan. En dat worden uiteindelijk vanzelf heel veel grote problemen heel veel achter elkaar.

Wat is exploritory testing NIET

Exploritory testing is in. Bijna iedere Agile tester beweert het te doen. De ene cursus na de andere, de ene presentatie na de andere, het onderwerp is helemaal van deze tijd. Toch kom ik bijna niemand tegen, die mij kan vertellen wat exploritory testing nu eigenlijk is. En zelf zou ik me ook nog lang niet aan een definitie wagen. Wat ik wel weet, is dat veel "Exploritory testing" hier zeker niet onder valt. Er zijn grote verschillen tussen exploritory testing en het alleen maar loslaten van de waterval testmethode. Dus wat is exploritory testing niet?

Doelloos testen

Testers gaan achter een applicatie zitten en klikken gewoon op de eerste de beste knop. En daarna op een knop. En daarna op een menu-item. Vroeger mocht dat niet, want er was geen vastgelegd testscript. En nu, nu mag het nog steeds niet.

Om je teststijd goed te besteden, is het verstandig om een doel voor ogen te hebben. Je hebt vaak niet alle tijd van de wereld. En bij de invoering van Exploritory testing is het belang van het risico op een bug en de mogelijk schade van een bug niet opeens onbelangrijk geworden. Daarom is het nog steeds verstandig om het belangrijkste het eerst te testen. Een rijtje met testdoelen kan daarbij helpen.

De formulering hoeft niet SMART te zijn, dus volledig op een manier te begrijpen. Je mag als tester best wat meer vrijheid nemen. Als je doel is een invulformulier te testen, mag je best op basis van ervaring bepalen of je het formulier hiervoor een, twee, vijf of tien keer invoert. Als je maar wel beseft dat "Kijken of de applicatie goed werkt" wel een erg ruime doelomschrijving is.

Geen testvoorbereiding uitvoeren

Waar Scrum en Agile vaak verwart worden met "Geen documentatie schrijven", wordt Exploritory testing vaak verwart met "Geen testvoorbereiding". Hoe vreemd het misschien ook klinkt, je bereidt je testen niet minder keren voor. In tegendeel, je bereidt je testen vaak veel meer keren voor dan bij de watervalmethode. Niet alleen voor je eerste testuitvoering. Maar ook tussen verschillende rondes van testuitvoering door.

Testvoorbereiding kan misschien bestaan uit alleen maar het bepalen van doelen. Het kan ook bestaan uit het lezen van een document. Of het opstellen van een minimale set aan gewenste testcases. Het hoeft alleen niet meer te bestaan uit volledig uitgewerkte testscript voor elke test die je uit wil voeren. Maar testvoorbereiding blijft ervoor zorgen dat je je testen beter uitvoert, dus waarom zou je het laten?

Daarnaast kan je tijdens het exploritory testing iets tegenkomen wat je verder wil onderzoeken. Wat je dieper wil testen of anders wil testen. Een onverwachtse bug. Een foutje in een tekst. Dat dit mogelijk is, is een van de grootste krachten van exploritory testing. Maar dit kan wel betekenen, dat je hier even over na moet denken. En net als in het begin van het testen even de tijd moet nemen een doel vast te stellen en te bepalen wat de beste manier is om te testen. Juist omdat bij exploritory testing leren erg centraal staat, leer je steeds beter hoe je de applicatie het beste kan testen. Maar dat vraagt dus elke keer ook weer om nieuwe testvoorbereiding.

Testen afbreken voor je doel bereikt is

Je bent een invulformulier aan het testen. Plotseling zie je dat de e-mail, het resultaat van het invulformulier, er in Outlook niet mooi uitziet. Meteen ga je de mail bekijken in andere e-mailprogramma's. Is die daar wel goed? Maar terwijl je dat doet, zie je dat het adres van de organisatie in de e-mail fout is. Dat staat in de instellingen van de applicatie. Dus ga je daarheen om  het te testen. Je leert steeds meer van de applicatie. Je bepaalt steeds beter wat je wil testen. Alleen vergeet je testen af te ronden. En je probeert nu op een heleboel zaken tegelijkertijd te letten. Wat vaak inhoudt, dat de kans op fouten missen steeds groter wordt.

Een van de moeilijkste zaken is de focus houden. Je hebt een testdoel, blijf dan alleen met dat testdoel bezig, tot je het doel bereikt is. Zie je iets anders, schrijf het op. Maar besteed er geen verdere tijd aan. Dat zorgt ervoor dat je je testen afrond en daarnaast dat je je aandacht zeer goed kan focussen op een onderwerp. En dat komt de kwaliteit van je testen weer ten goede.

Onderhoudbaar maken van automatisch testen

Je hebt je automatische testen. En dan wijzigt er iets. Plotseling vallen er heel veel van je testen om. Dat wordt aanpassen. Dat wordt veel werk. Kan je ervoor zorgen dat het onderhouden van je automatische testen minder tijd kost? Het blijft altijd tijd kosten, maar ik heb gemerkt dat er trucjes zijn om de tijd te verminderen. Zowel zonder als met programmeerkennis.

Naamgeving

Hoe eenvoudig ook, aanpassen gaat een stuk eenvoudiger als je aan de hand van de naamgeving kan raden wat de inhoud is. Geef je bestanden en/of procedures altijd een naam, die de test of de testsuite beschrijft. Zo geef ik vaak de testsuite in Selenium een beschrijving van het scherm dat ik wil testen. En vervolgens de testen een korte beschrijving van de test. Bij voorkeur laat ik de naam van de testsuite terugkomen in de testcase. Zo zal ik een testsuite "Zoeken" noemen, omdat ik hier het scherm wil testen waar de zoekgegevens ingevoerd worden. En vervolgens noem ik de testcase "ZoekenPostcode", omdat in deze test ik wil nagaan of het zoeken op postcode goed werkt.

Houdt je naamgeving ook zo consistent mogelijk, zodat er automatisch een groepering ontstaat. Als je de testen "ZoekenPostcode", "NaamZoeken" en "SearchPlace" noemt, maak je het jezelf moeilijk. Begin de naam, als dit kan, met de groep waar het bestand en/of test een onderdeel van is. En geef daarna een omschrijving.

Door de naamgeving goed te kiezen, kan je raden wat de inhoud is. En hierdoor weet je of, bij een aanpassing in de applicatie, je dit onderdeel moet aanpassen of niet. Als je daarnaast al een soort van groepering hebt, kan je ook eenvoudig raden of er een hele groep aangepast moet worden. Bijvoorbeeld als je het zoekscherm hebt aangepast, zal je zeker moeten kijken naar alles wat begint met  "Zoeken".

Groeperen en becommentariëren

Bijna elk testautomatiseringsprogramma heeft de mogelijkheid om commentaar toe te voegen. Wanneer je dit consistent doet, kan je ook binnen een stukje automatiseringscode eenvoudig onderdelen herkennen. Ook dit maakt het weer eenvoudiger om te wijzigen stukken code te vinden. Zeker als je dit combineert met een goede groepering

Zelf groepeer ik zoveel mogelijk de volgende opdrachten bij elkaar: invoeropdrachten, schermwisselopdrachten en controleopdrachten. Alle opdrachten, die gegevens invoeren staan in een groep. Als dit teveel is, dan splits ik dit eventueel per component. Zo kan het invoeren van de zoekbox een groep zijn. Daarbinnen kan de datumcombobox weer veel handelingen vragen (selecteer jaar, selecteer maand, selecteer dag), waardoor dit een aparte groep kan worden.

Buttons die zorgen voor het openen van een dialoog of wisselen naar een ander scherm, zet ik in een aparte groep met schermwisselopdrachten. Deze groep bevat zowel het klikken op de button, het wachten op het nieuwe scherm als eventuele controle of het scherm geopend is.

Als laatste groepeer ik de controleopdrachten. Na invoer en/of schermwissel ga je de werkelijke test uitvoeren m.b.v. controles. Ook deze komen weer samen in een groep.

Deze groepen kan je vervolgens herkennen/groeperen door commentaar toe te voegen. Zelf doe ik dit bij voorkeur met een beschrijvend zelfstandig naamwoord gevolgd door "invoeren" of "controleren". Bijvoorbeeld "Zoekscherm invoeren" of "Kassabon controleren". Schermwissels hebben bij mij meestal het commentaar "Ga naar .....".

Door consistent te groeperen en commentaar toe te voegen, worden je testen goed leesbaar. Maar vooral leer je de onderdelen herkennen die terug komen. Als we weer uitgaan van een aanpassing in het zoekscherm, dan weet je dat elk onderdeel met het commentaar "Zoekscherm invoeren" hoogstwaarschijnlijk even gecontroleerd moet worden.

Search and replace

Een van de meest voorkomende aanpassingen is een element dat gewijzigd is. Eerst heette de button "btnSearch", maar nu heet het "btnSearch1". Er is namelijk een tweede toegevoegd.

Maak voor dit soort aanpassingen gebruik van Search and replace mogelijkheden. Dit kan binnen het automatiseringtool zijn, dat je gebruikt. Maar als je testtool geen mogelijkheid biedt, bijvoorbeeld omdat je Selenium IDE gebruikt, kan je ook een Search and Replace tool via internet downloaden en installeren. Belangrijkste is, dat je meerdere bestanden tegelijkertijd kan aanpassen.

Houdt er wel rekening mee dat je hierna al je testen moet controleren. Het is namelijk zeer goed mogelijk, dat je per ongeluk op een verkeerde plek iets hebt vervangen. Maar ondanks dit risico is deze manier van aanpassen vaak sneller dan alles handmatig opzoeken.

Herbruikbare functies

Als je kan programmeren en je programmeert zelf je testen, dan kan je je werk nog eenvoudiger maken. Door de groepering die je hopelijk hebt toegepast, komen automatisch groepen naar voren die vaak terugkomen. Hier kan je vervolgens functies van maken, die je vervolgens binnen je testen aan kan roepen. Ook hierbij is het verstandig de juiste naamgeving aan te houden.

Wanneer je veelgebruikte groepen in een functie weet te vatten, kan je deze binnen meerdere testen gebruiken. Bij een aanpassing is een aanpassing in deze functie vervolgens voldoende. Dat scheelt dan vervolgens weer een heleboel werk.

De valkuilen van open en eerlijk communiceren

Ieder Agile teamlid, en zeker ook een tester, heeft wel eens een onderwerp dat besproken moet worden. Met een of met meerdere personen. En misschien heb jij het dan ook wel eens gehoord: "Je moet open en eerlijk met elkaar praten." Ik ben geen blinde voorstander van open en eerlijk communiceren. Ik heb op deze wijze heel veel zaken goed opgelost zien worden. Maar ik heb ook gezien hoe deze manier van communiceren de problemen alleen maar groter maakten.

"Open en eerlijk zijn" is, net als andere communicatiekeuzes, een mogelijkheid om een probleem op te lossen. En net als elke mogelijkheid is het soms wel en soms niet de juiste keuze. Het voordeel is, als het lukt, dat mensen elkaar meer begrijpen en dat oplossingen meer gedragen worden. Maar als het niet lukt, zijn de nadelen veel groter. En meestal, is mijn ervaring, komt dit doordat "open en eerlijk communiceren" op zo'n wijze gebruikt wordt, dat mensen, bewust of onbewust, de mond gesnoerd wordt of er binnen het gesprek tegenstanders ontstaan.

Onvoldoende vertrouwen

Om een goed open en eerlijk gesprek te hebben, moet er tussen alle gesprekspartners vertrouwen aanwezig zijn. Men moet het vertrouwen hebben dat niemand van de aanwezigen tot doel heeft de ander als zondebok aan te wijzen of bij de ander zijn of haar geschiktheid voor zijn of haar werk in twijfel te trekken. Aan de andere kant moet men het vertrouwen hebben dat wat gezegd wordt, later niet gebruikt wordt om een persoon negatief beoordelen. Dit laatste heeft misschien iets meer toelichting nodig. Stel dat je tijdens het gesprek wil inbrengen dat de communicatie tussen scrummaster en teamleden niet goed verloopt. Als je dit aan wilt kaarten, moet je het vertrouwen hebben, dat de scrummaster niet na het gesprek boos naar je toe komt. Of dat je teamleden je links laten liggen, omdat je de kant van de scrummaster hebt gekozen.

Als je vertrouwenskwesties binnen de groep negeert en toch onderwerpen ter sprake brengt, zal er zeker geen open sfeer heersen. Er zal snel sprake zijn van emotie, omdat mensen zich aangevallen voelen. Dit maakt dan misschien weer, dat mensen zeer voorzichtig gaan communiceren, om de ander niet op de tenen te trappen Of mensen houden hun mening helemaal voor zich. Dit om een negatieve reactie van een ander te voorkomen of om niet zelf in de problemen te komen na het gesprek.

Wat veel mensen vergeten, is dat vertrouwen niet af te dwingen is. "We gaan nu open en eerlijk communiceren. Het is niet het doel iemand te beoordelen of te veroordelen," Soortgelijke uitspraken gaan vaak vooraf aan open en eerlijke gesprekken. Hoe goed bedoelt, zo'n zin kan het vertrouwen niet spontaan herstellen. Voordat je een open en eerlijk gesprek kan voeren, zal je eerst het onderlinge vertrouwen tussen de mensen moeten herstellen. En deze zaken een-op-een laten uitpraten. Zonder vertrouwen krijg je echt geen open en eerlijk gesprek.

Onderwerpen die uitsluiten

"We gaan deze keer open en eerlijk bespreken waarom de kwaliteit van het product de laatste tijd zoveel slechter is geworden" Misschien lijkt hier in eerste instantie niet zoveel mis mee. Maar stel dat er iemand in de groep is, die niet vindt dat de kwaliteit slechter is geworden? Hoe denk je dat die persoon aan het gesprek zal deelnemen?

Als je "geluk" hebt, zal deze persoon zwijgen. Maar het is de vraag of je daar blij mee moet zijn. Een open en eerlijk gesprek, waar niet iedereen een actieven bijdrage aan geeft, zorgt nu niet echt tot een oplossing waar de hele groep achter staat.

Stel dat deze persoon toch zijn of haar mening geeft, dan heb je pas echt een probleem. Je open en eerlijke gesprek heeft dan vaak meteen twee kampen. Aan de ene kant de groep die dwarsligt en/of de waarheid niet onder ogen wil zien en/of..., vul je eigen antwoord maar in. Aan de andere kant de groep die niet wil luisteren en/of sterk bevooroordeeld is en/of.......

In een open en eerlijk gesprek kan je meestal geen onderwerpen bespreken die als feiten geformuleerde uitspraken bevatten. Of je moet er wel heel, maar dan ook heel, erg zeker van zijn dat iedereen in het gesprek het met deze feiten eens is. Slimmer is om een onderwerp op een hoger niveau te bespreken. "We gaan het hebben over de kwaliteit van het product" geeft mensen veel meer vrijheid. Iedereen kan nu alles zeggen over de kwaliteit, of ze deze nu beter of slechter vinden.

Watervallen aan informatie

"Dit gaat fout. En dit. En dat, En daar gaat dat fout." Er zijn weinig mensen die het leuk vinden om zulke opsommingen te horen. Maar de andere kant "Dit gaan we doen. En dan dat. En vervolgens dat. En natuurlijk dan dat." wordt zeker ook niet gewaardeerd. Mensen voelen zich vaak overvallen door de grote stortvloed aan informatie. Ze kunnen emotioneel worden, doordat ze zich plotseling beschuldigd voelen van een heel rijtje fouten. Ze kunnen de openheid van het gesprek in twijfel gaan trekken, omdat diegene die spreekt alles al uitgedacht lijkt te hebben. Of ze kunnen je gewoon niet bijbenen. Hoe dan ook, opsommingen van problemen of acties is misschien wel open en eerlijk, maar komen het gesprek niet ten goede.

Slimmer is het om deze opsommingen op te splitsen. Wat is naar de mening van de spreker de ergste fout die gemaakt is? Wat is naar de mening van de spreker de eerste stap die gezet moet worden? Laten we die dan eerst open en eerlijk bespreken, voor we de opsomming verder behandelen. En zorg er ook voor dat iedereen zijn of haar ergste fout of eerste stap heeft kunnen noemen, voordat de opsomming van een persoon volledig behandeld is. Dit geeft binnen de groep het gevoel dat iedereen inbreng mag geven, in plaats van slechts een persoon.

Oneerlijke groepsverdeling

Een oneerlijke groepsverdeling kan een open en eerlijk gesprek zwaar blokkeren. Stel dat twee of meer personen in de groep vinden, dat er anders getest moet worden. En stel dat er maar een persoon in de groep dit niet vindt. De andere personen vinden dan steun bij elkaar, zien elkaars mening bevestigd in de ander. De enkeling kan dan al snel gezien worden als dwarsligger of iemand die de waarheid niet onder ogen wil zien. De enkeling zelf zal zich zeker niet snel serieus genomen voelen of het gevoel hebben onder druk te worden gezet.

Dit gebeurt zeker niet altijd, maar oneerlijke groepsverdelingen zijn en blijven een risico, Als je een onderwerp wil bespreken en je weet ongeveer de meningen, probeer dan de situatie te voorkomen. Zorg ervoor dat elk "kamp" minimaal twee personen bevat. En als dit niet lukt, zorg dan voor een onafhankelijke scheidsrechter. Een persoon die over de situatie geen mening heeft en ook niet hoeft te hebben. Die vooral erop kan letten dat alle "kampen" aan het woord komen en dat naar iedereen geluisterd wordt.

Dan maar nooit meer open en eerlijk zijn?

Als open en eerlijk communiceren zoveel valkuilen heeft, moet je het dan niet gewoon laten? Wat mij betreft zeker niet. Je moet niet van iedereen verwachten dat ze altijd open en eerlijk zijn. Een open en eerlijk gesprek moet je voorbereiden. Een open en eerlijk gesprek moet een goede gespreksleider hebben. Je moet vooral een sfeer neerzetten, waarin mensen open en eerlijk kunnen zijn. Dit kan dan wel degelijk zaken bespreekbaar, die anders alleen in de achterkamertjes besproken worden. Want bepaalde zaken wil je alleen bespreken in een veilige omgeving. Open en eerlijk communiceren kan deze veilige omgeving zijn, mits je niet denkt dat deze vorm van communicatie in een vingerknip ontstaat.

Testtechnieken en Agile testen

Testtechnieken en Agile testen lijken vaak tegenstrijdig. Testtechnieken lijken te horen bij de tijd van de waterval, waarbij je veel tijd besteedde aan testvoorbereiding. En niet bij een tijd van Agile testen, waarbij je snel en flexibel moet testen. Toch ervaar ik ze als een krachtig, sterk middel, juist binnen Agile testen.

Het toepassen van een testtechniek kost tijd, dat zal ik niet ontkennen. Maar het heeft zeker een meerwaarde. Testtechnieken geven een houvast bij een test. Ze zijn meestal een vrij snelle methode van testvoorbereiding. En, eenmaal opgesteld, kunnen ze ook nog eens een basis zijn tot waardevolle functionele documentatie.

Testtechnieken tijdens testen

Als je je testtechnieken, zoals Datacombinatietest en Elementaire Vergelijkings Test, goed beheerst, ben je in staat deze elk moment in te zetten. Vaak is het verstandig ze te gebruiken, als er een onderdeel te testen valt waarbij de dekkingsgraad van belang is. Je wil zeker weten dat je voor dit onderdeel voldoende varianten hebt getest. Denk hierbij bijvoorbeeld aan ketentesten, waarbij je zeker wil weten dat je alle mogelijke processtappen een keer getest hebt. Of aan ingewikkelde business rules, die te belangrijk zijn om op de gok te testen.

Wanneer je zo'n onderdeel in de story, of soortgelijke beschrijving, ontdekt, is de manier van werken eigenlijk niet zoveel anders. Je kiest de testtechniek uit, die naar jouw mening het beste bij het onderdeel past. Je past hem toe. En daarna voer je de testcases uit. Het belangrijkste verschil zit hem in het moment van toepassen. Bij waterval paste je deze testtechnieken al vaak ruim van tevoren toe. Nu pas je hem vrij vlak voor het testen toe. Van belang is om de testtechniek pas toe te passen, als de informatie, die je wilt testen correct is. Of er minimale wijzigingen verwacht worden.

Het moment wordt dus niet bepaalt door de gehele status van het proces, zoals bij waterval. In plaats daarvan wordt het moment alleen bepaalt door het moment waarop de informatie, nodig voor de testtechniek, gereed is. Hierna hangt het van verdere afspraken binnen je team af, wanneer je de testvoorbereiding uitvoert. Dit kan aan het begin van de sprint, als je uit ervaring weet dat je aan het eind van de sprint vaak veel werk hebt. Maar dit kan ook gewoon als de taak op het scrumboard de bovenste taak is. Het kan zelfs een onderdeel zijn van een algehele taak "testuitvoering". Wat de beste optie is, is echt organisatie afhankelijk.

Testtechnieken als communicatiemiddel

Testtechnieken hebben vaak als voordeel dat ze door andere teamleden, zoals ontwikkelaars, makkelijk te begrijpen zijn. Zelfs zonder uitleg kan een ontwikkelaar de testtechniek vaak voldoende begrijpen, om de informatie eruit te halen. Zeker bij technieken als de procescyculstest, die veel lijkt op ontwerptechnieken waarmee ontwikkelaars veel te maken hebben. Als je een testtechniek toepast, kan deze daarom ook meteen gebruikt worden om wat ingewikkeldere informatie zo weer te geven, dat iedereen binnen het ontwikkelteam de informatie op dezelfde manier begrijpt. Hierbij moet je vooral denken aan technieken die een schematische weergave geven van de werkelijkheid, niet aan technieken die vooral tot een opsomming van testcases leiden.

Als er een moeilijker onderdeel staat in de story, kan je daarom als tester je team helpen met je testtechnieken. Je kan al in een vroeg stadium, misschien zelfs al bij bijvoorbeeld de backlog refinement, je kennis inzetten om je team te helpen tot een duidelijk en begrijpelijk te bouwen story te komen. Hierdoor gebruik je je vaardigheden als tester ruimer en tevens heb je alvast een start gemaakt met de testvoorbereiding. Wat later weer tijd scheelt.

Testtechnieken als documentatie

Als je je testtechnieken goed toepast, zijn het vaak kleine, compacte, duidelijke schema's, waarin veel belangrijke informatie terugkomt. Door de compactheid is het vaak makkelijk om er aanpassingen in door te voeren, mochten er wijzigingen komen. Zoals al eerder geschreven, zijn ze vaak ook begrijpelijk voor andere teamleden en anders eenvoudig uit te leggen. Door deze combinatie zijn testtechnieken vaak een mooie start voor documentatie.

Documentatie is ook bij Agile projecten vaak een ondergeschoven kindje. Maar ook bij deze projecten ontstaat vaak een kennisgebrek. Omdat je de testtechnieken vaak op wat uitgebreidere of ingewikkeldere delen gaat toepassen, zijn dit regelmatig ook de onderdelen waarvan de kennis niet volledig in de hoofden van het team zit. Dit maakt alleen al het vastleggen van deze technieken in algemene documentatie tot een goede basis voor de documentatie.

Gebruik dus je testtechnieken

Agile testen en testtechnieken gaan goed samen. Blijf dus je testtechnieken leren, breidt je kennis uit en pas ze toe. Ook, nee juist, binnen een Agile project. Maak gebruik van de begrijpelijkheid om zowel voorafgaand als tijdens als na de bouw van een onderdeel de communicatie en kennis binnen het team te verbeteren. Ze zijn niet voor niets uitgevonden, daar verandert Agile niets aan.

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.