Zichtbare Agile Applicatiekwaliteit

Agile heeft mede als doel een kwalitatief goede product op te leveren. Toch lijkt er te vaak, juist bij Agile teams, te weinig aandacht voor kwaliteit van de applicatie als geheel. Dit kan verschillende redenen hebben. Maar de drie die ik het meest tegenkom, zijn de volgende drie:

• De bevinding kan niet direct aan een story worden toegewezen, waardoor deze buiten het proces valt
• De bevinding is veroorzaakt door een ontwikkelaar buiten het team, bijvoorbeeld in een ander Agile team of zelfs door een externe leverancier
• Het bouwen van nieuwe functionaliteit gaat voor het fixen van bevindingen of loopt teveel uit, waarna er besloten wordt met bepaalde bevindingen in productie te gaan.

Wat van belang is, is dat je als team ernaar blijft streven om een goed product op te leveren. En als Agile tester moet je dit nog meer willen dan de rest. Het kan zijn dat je inderdaad een bepaalde bekende bevinding niet mag of kan oplossen, maar dan nog moet je de verantwoordelijkheid voelen dit probleem aan te kaarten. Wat het probleem ook is.

Maar om een probleem te bespreken is het vaak handig om het probleem zichtbaar te maken. Zowel als motivatiemiddel en als bewijsmiddel. Nu zijn de meeste teststatistieken veel werk, uitgebreid en te ingewikkeld. Dus niet erg Agile naar mijn mening. Ik werk daarom zelf liever met methodes die snel en eenvoudig een beeld geven. Misschien minder betrouwbaar, maar ze hebben zich voor mij in de praktijk betrouwbaar genoeg bewezen.

Mijn meest gebruikte techniek is van toepassing op de regressietest. Maar met een beetje aanpassing kan je hem ook voor andere zaken gebruiken. Hierbij is het doel om elke keer als je de regressietest uitvoert, al of niet automatisch, vast te leggen wat het resultaat is. En bij voorkeur op zo'n wijze, dat het hele Agile team deze resultaten in de kamer kan bekijken. Dus bijvoorbeeld geschreven op een bord of op een papier in de kamer van het Agile team. Want ik ken weinig ontwikkelaars die houden van een tabel die ze laat weten dat een aantal testen steeds opnieuw niet slagen. Dat bepaalde fouten maar niet opgelost worden. Of bepaalde wijzigingen plotseling heel veel fouten veroorzaken.

Bij deze weergave verdeel je je regressietest op in een beperkt aantal groepen. Dit kan per testscript, maar als dit er veel zijn kan een groepering van testscripts handig zijn. Deze zet je onder elkaar. Vervolgens maak je voor elke keer dat je de regressietest uitvoert een kolom. Als de test goed is uitgevoerd, geef je dit aan in de tabel. Bij voorkeur natuurlijk met groen. Als de test slaagt, geef je dit ook aan. Natuurlijk doe je dit bij voorkeur met rood. Maar daarnaast is het ook handig om anderen in het team de mogelijkheid te geven om na te lezen wat er fout is gegaan. Als je gebruikt maakt van een bevindingenregistratie, dan heeft de bevinding vaak een code. Deze code kan je dan in de grafiek zetten. En als er twee bevindingen uit de test kwamen, zet je twee codes neer.

Op deze wijze ontstaat er een overzicht van de regressietest door de tijd. Je kan dan waarnemen wanneer een regressietest plotseling wel heel erg faalde. Maar bijvoorbeeld ook welke fouten in de applicatie nu al heel lang op een oplossing wachten. En dit kan je weer gebruiken om problemen bij het oplossen van bevindingen bespreekbaar te maken. Als dit al nodig is, want als mensen geloven in je regressietest en/of ze willen kwalitatief goed werk afleveren, is de tabel al motivatie genoeg om met de bevindingen aan de slag te gaan.

Automatisch testen als automatisch testen niet kan

Stel je hebt nog helemaal geen automatische testen. Je hebt geen tijd om een automatische test op te bouwen. En je hebt nauwelijks kennis van testautomatiseringstools. De belangrijkste functies lijken onmogelijk om te automatiseren, zo moeilijk en/of uitgebreid zijn ze. Of bedenk zelf maar andere redenen waarom testautomatisering bouwen eigenlijk gewoon niet mogelijk is. Er is vaak wel een reden om aan een onmogelijk grote klus als testautomatisering niet eens te beginnen. Zelf denk ik daar toch anders over. Je moet alleen wel bereid zijn om met weinig te beginnen.

Wat je naar mijn mening nodig hebt: minimaal 2 uur per week en de vaardigheid om tevreden te zijn met een heel klein beetje. Maar daarmee, dat weet ik ook wel, kom je niet zonder problemen tot een automatische test. Ik hoop met deze blog wat hulpmiddelen te geven om de moed te vinden te starten.

De voorbereiding

Wat heel verstandig is om voor de testautomatisering te hebben, is een in een document beschreven testscript. Hierin moet goed beschreven zijn wat je wilt invoeren en wat je wil controleren. Zorg ervoor, dat je alleen die testen automatiseert, die op papier beschreven staan. Het is je ontwerp bij de bouw en je documentatie bij later onderhoud. En het is het inwerkmateriaal voor latere overdracht.

Daarna komt, met behulp van de beschreven testscripts, de volgende stap. Deel je testscripts in zo klein mogelijke delen op. Je kan later altijd weer samenvoegen. Als je in een test op Opslaan klikt, heb je een deel wat je los kan automatiseren. Als je op een OK of een Cancel button klikt, vaak ook. En bij wisseling in applicatie heb je al zeker te maken met losse delen. Het idee is, dat een los deel van het testscript geautomatiseerd kan worden en het voorgaande deel en het deel erna eventueel handmatig uitgevoerd kan worden.

Stel je hebt een programma voor urenregistratie. En hiervoor wordt de volgende test uitgevoerd: De medewerker voert zijn uren in. Hierna keurt de leidinggevende de uren af. Vervolgens past de medewerker zijn uren aan. 

Stel nu dat voor de testautomatisering de switch tussen medewerker en leidinggevende niet mogelijk is. Je moet daarvoor namelijk al bij het inloggen op de computer de juiste persoon gekozen hebben. En het inloggen op de computer automatiseren is niet mogelijk. Dan kan je de hele testcase laten vallen, niet mogelijk is niet mogelijk. Of je kan toch besluiten te automatiseren. Want het invoeren van de uren en het aanpassen zijn handelingen, die je als tester veel tijd kosten. Het goedkeuren is slechts een knop indrukken. Dus splits je het testscript in drie delen: het invoeren van de uren en het wijzigen van de uren worden geautomatiseerd gedraaid op computer 1. En het controleren van de uren doe je op computer 2 handmatig tussendoor. Testautomatisering is dan niet meer het doel, maar een middel om sneller te testen. En dat maakt testautomatisering, zoals hopelijk uit het voorbeeld blijkt, een stuk sneller waardevol.

De aanpak

Er zijn in mijn ogen twee manieren om testautomatisering aan te pakken. De beste manier is op basis van risico: je kijkt welke onderdelen het meest belangrijk en/of het meeste kans op fouten hebben. Dit kan dus een volledige testcase zijn, maar ook een onderdeel van een testcase. Het grootste voordeel is: je hebt het snelste resultaat. Maar om dit voor elkaar te krijgen, heb je wel veel kennis van je testautomatiseringstool nodig. De meest belangrijke testcases en de testcases met de meeste kans op fouten zijn helaas vaak ook de moeilijkste om de automatiseren. Dus is deze aanpak alleen geschikt, als je de kennis al hebt of veel tijd hebt om die kennis op te bouwen.

Een minder ideale manier is op basis van moeilijkheidsgraad. Je bouwt eerst de makkelijkste onderdelen en, naarmate je kennis van testautomatisering toeneemt, bouw je de moeilijkere onderdelen. Hier wordt het vaak moeilijk om gemotiveerd te blijven, want wat is het nut nu? Bij deze aanpak ligt het nut dan ook veel meer in tijdsbesparing. Want gelukkig zijn de eenvoudigste testautomatiseringsklussen, vaak ook erg tijdrovend. Iedere tester heeft wel eens voor de zoveelste keer handmatig een heel formulier ingevuld. Of met het oog een heleboel gegevens op een scherm opgevraagd en gecontroleerd. De kans dat je hier als tester een fout maakt, is eigenlijk vrij hoog. Het is eenvoudig werk, maar vraagt toch veel tijd en concentratie. Dus zo onlogisch om te automatiseren is het dan misschien toch niet? Als je hoofddoel maar ligt in de tijdsbesparing en dus niet in de testautomatisering.

Bij de laatste aanpak is het vaak verstandig om te beginnen bij CRUD (create, read, update, delete). Automatiseer het aanmaken van personen, bestellingen, artikelen en/of pas ze aan. Vraag schermen op en controleer of de juiste waardes worden getoond. En automatiseer het verwijderen om de automatische test herhaalbaar te maken. Want eenmaal verwijderd, kan je precies hetzelfde object opnieuw aanmaken. Er is bijna geen applicatie waar deze testen in de een of andere vorm niet voor plaatsvinden. Begin bij invoervelden en knoppen. Ga daarna naar tabellen en los weergegeven teksten. En bepaal daarna welke onderdelen voor jou en jouw automatiseringstool een logische volgende stap zijn.

Durf te beginnen

Wat zo langzamerhand wel duidelijk is: naar mijn mening moet je met testautomatisering gewoon beginnen. Onder alle omstandigheden, desnoods klein en eenvoudig. Maak van testautomatisering niet je doel, maar gebruik de testautomatisering om sneller en beter te testen. Als het automatiseren van een volledig testscript niet mogelijk is, automatiseer dan een deel. Maar dus bovenal: zie de testautomatisering nooit als een enorme klus, die pas zin heeft als je alles meteen helemaal volledig kan automatiseren.

Functioneel testen door ontwikkelaars

Testen is een specialisatie, ik zal de laatste zijn om dat te ontkennen. Maar zeker in een Agile omgeving kan je in de situatie komen dat ook ontwikkelaars moeten testen. Bijvoorbeeld als het testwerk te veel is voor de enige tester in het team. Of je gaat als enige tester in het team op vakantie. En eerlijk is eerlijk: ontwikkelaars zijn meestal geen slechte testers. Tenslotte is het testen van hun eigen code een vast onderdeel van hun werk. Een echt goede ontwikkelaar kan niet een echt slechte tester zijn Toch stappen veel ontwikkelaars in valkuilen, die ervaren testers kunnen ontwijken. Hoe zorg je er als tester voor dat ontwikkelaars beter gaan testen?

Er zijn twee belangrijke varianten die je hierbij kan volgen. Welk pad het juiste is, hangt af van jezelf en van je werkomgeving. Als je bijvoorbeeld goed kan uitleggen of als je een team moet begeleiden waar je zelf geen deel van bent, dan zal de nadruk liggen op het coachen. Maar als je team of het bedrijf nog erg veel denkt in gescheiden disciplines of je voelt je geen coach, kan je altijd nog teruggrijpen naar een vorm van testvoorbereiding. Maar waarschijnlijk komt het erop neer dat je beiden moet proberen en ontdekt welke van de twee manieren of welke combinatie jou het beste bevalt.

Testvoorbereiding

Het doel van de testvoorbereiding is niet veel anders dan we als testers gewent zijn: je schrijft van tevoren de testscripts en/of de testcases, zodat de test later uitgevoerd kan worden. In de testvoorbereiding verwerk je dat deel van jouw specialistische kennis, die een ontwikkelaar vaak niet heeft. Het probleem bij deze methode is het opbouwen van een voorsprong. Jouw testvoorbereiding moet klaar zijn, voordat de bouw gereed is. En die tijdsperiode is bij een Agile methode soms erg kort. Zeker als je ook nog een extra voorsprong moet hebben om bijvoorbeeld een vakantie te overbruggen.

Als je de voorsprong wil behouden, zal je soms als tester een moeilijke keus moeten maken. Het kan nodig zijn om je voor een bepaalde periode alleen te richten op de testvoorbereiding. Het testwerk komt dan volledig bij de ontwikkelaars te liggen. Als het nodig is, neem dan deze keuze: het doel is niet dat jij de test uitvoert, het doel is dat er goed getest wordt.

Belangrijkste nadeel van deze methode: je blijft altijd lang bezig met de voorbereiding. Het werkt wordt nooit minder, omdat de ontwikkelaars niet beter leren testen. Maar het voordeel is dat je deze methode altijd kan toepassen, ongeacht je eigen vaardigheden, het bedrijf waar je werkt of het team waar je deel van uitmaakt.

Coaching

Op het gebied van coaching heb ik zelf ervaring op twee verschillende gebieden: procesmatig en inhoudelijk.

Procesmatig ligt de nadruk op principes die ervoor zorgen dat het testproces constant en goed uitgevoerd wordt. Zelf houd ik minimaal de volgende twee principes aan:

1. De functionele test wordt niet uitgevoerd door de ontwikkelaar die de code geprogrammeerd heeft
2. De functionele test wordt zo dicht mogelijk op de bouw uitgevoerd

Belangrijk is om momenten te vinden waarop je deze principes kan controleren of  in herinnering kan brengen. Denk hierbij bijvoorbeeld aan de daily standup of de retrospective.

Maar daarnaast kan het ook verstandig zijn om de functionele testvaardigheden van ontwikkelaars beter te krijgen. Bijvoorbeeld door ze bepaalde testtechnieken te leren of bepaalde testprincipes. Mijn eigen favoriete methode is de "Drie meest voorkomende fouten" methode. Hierbij gebruik je je ervaring als tester om te bepalen wat bij jou in het team de drie meest voorkomende fouten zijn. Vervolgens bepaal je voor jezelf hoe jij als tester specifiek op deze fouten test. Dit samen kan je in een document, een presentatie of iets dergelijks samenvoegen. Wat je dan vervolgens met de ontwikkelaars kan delen.

Om de coaching goed uit te voeren heb je veel medewerking nodig, zowel van je team als soms van je bedrijf. Maar als het lukt, betreft het wel een investering die op een bepaald moment niet meer nodig is. En ter geruststelling: je zal jezelf niet snel overbodig coachen.

Blijf betrokken

Als het ook maar enigszins mogelijk is, blijf als tester zelf ook testen. En kijk naar de bevindingen die gevonden worden. Vooral als ze uit productie komen. Of je nu kiest voor testvoorbereiding en/of coaching, gebruik je kennis als professionele tester. Kijk welke bevindingen gemist worden en kijk welke bevindingen veel gevonden worden. Gebruik deze kennis om je testvoorbereiding en/of je coaching nog beter te laten worden. Als je een echt goede tester bent, dan kan je altijd een volgende keer het functioneel testen beter laten verlopen. Ook als de functionele test door ontwikkelaars uitgevoerd wordt.