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?