Acceptatiecriteria - Het nieuwe contract?

Eerst had je het functioneel ontwerp, bij voorkeur van punt tot punt vastgelegd en met handtekening eronder. Dat willen we vaak niet meer. Maar toch heb je enige houvast nodig, dus hebben we nu zeer regelmatig acceptatiecriteria. Geen handtekening, maar wel een meetpunt om via een acceptatietest alsnog een definitief akkoord te krijgen. Maakt dit van acceptatietesten de nieuwe handtekening onder een contract? Zijn de acceptatiecriteria het nieuwe contract? En moet je dat wel willen?

Zowel bij programmeurs en testers is heel veel vraag naar duidelijke specificaties. Logisch, de informatie uit het functionele ontwerp heb je ook nu nog nodig om tot een goede applicatie te komen. Ook om duidelijk te kunnen afspreken wat wel en wat niet geaccepteerd gaat worden. Daarom gaan we het volledige FO als scrumteam vaak proberen op te vangen in de beschrijving van de story. En met enige grote regelmaat gebeurt dit via de acceptatiecriteria in de story. Ook als tester heel handig, want je weet zeker dat je alle informatie waarop je moet testen in de story staat.

Maar is de acceptatietest nu eigenlijk wel een acceptatietest? Een acceptatietest heeft in mijn ogen voornamelijk als doel om te bepalen of het opgeleverde werk, vanuit de business en de klant gezien, naar productie kan. Dus de acceptatiecriteria moeten hier een afspiegeling van zijn. En zolang het project op tijd loopt, lijkt dit ook het geval. Totdat er tijdnood komt. Dan blijken veel lijsten met acceptatiecriteria opeens niet zo belangrijk te zijn.

Acceptatiecriteria zijn bijvoorbeeld doorgeslagen in detail. Stel je hebt een invoerveld waarbij het acceptatiecriterium is: "Bij een geldige waarde in het veld moet naast het veld een groen vinkje getoond worden". Stel nu dat er een zwart vinkje is gebouwd. Er is geen tijd meer, dus het invoerveld gaat naar productie of het invoerveld gaat niet naar productie. Het is het enige veld in een scherm, de validatie is verder goed. Er is geen enkele reden om het af te keuren, behalve de kleur van het vinkje. Neem maar van mij aan, het invoerveld wordt naar productie opgeleverd. Zelfs als het hele vinkje niet aanwezig zou zijn, het invoerveld gaat zeer waarschijnlijk naar productie. Want wat wil de gebruiker? De gebruiker wil geen groen vinkje. De gebruiker wil een invoerveld waaraan duidelijk te zien is of de ingevoerde waarde fout of goed is. Of dit wordt aangegeven met een vinkje, met een foutmelding met een rode rand om het invoerveld, de gebruiker maakt het niet uit. Waarom maakt het in de acceptatiecriteria dan wel uit?

Wat ook wordt toegepast in de acceptatiecriteria is de verwijzingen naar andere documenten. Het gebouwde scherm moet voldoen aan het design. Het moet voldoen aan het interactie-ontwerp. Of misschien zelfs voldoen aan het functioneel ontwerp. Tja, vroeger leek datgene wat in productie ging al niet volledig op het ontwerp. Zou dat nu zoveel anders zijn? Ik heb in ieder geval nog geen acceptatietest meegemaakt waarin de acceptatietester het ontwerp tot op de letter of tot op de pixel ging controleren. En bij het eerste kleine verschil zei: "Nee, dit gaat dus niet naar productie"

Het probleem is naar mijn mening dat we graag blijven bij het oude, vertrouwde, veilige watervalprincipe van een contract met handtekening. We bouwen wat voor ons is vastgelegd. Niets meer en niets minder. Als we het niet gebouwd hebben en het was ook niet vastgelegd dat we het moesten bouwen, dan is het extra. Vroeger extra tijd en geld, nu een extra story. Want het blijft dan toch een vooruitgang? Als iemand wilde afwijken was dat bij waterval eigenlijk niet toegestaan. Nu kan je de story gewoon direct prioriteren, je mag dus afwijken. Dus vooruitgang.....

Als gevolg hiervan zie ik ontwikkelaars die al vijfentwintig keer een datum invoerveld hebben gebouwd tot in detail vragen hoe het veld moet werken. Het antwoord "Kan mij wat schelen, als ik maar alleen geldige datums kan invoeren" is vanuit de business vaak het enige juiste antwoord. Maar dat antwoord mag niet. Want zo kunnen we niet bouwen of testen. Hoe moeten we anders antwoorden krijgen? Tja..... bedenk zelf het antwoord? Als je al vijfentwintig keer een datum invoerveld hebt gebouwd of getest, kan je dan niet zelf bedenken welke invoercontroles nodig zijn om aan het acceptatiecriterium te voldoen?

Maar hoe kan je dan weten of het gebouwde in een keer naar wens is? Tja, dat weet je niet. Misschien heb je een zwart vinkje gebouwd en wordt de vraag gesteld "Kan dat vinkje niet groen zijn?" Waar het om gaat is het vertrouwen dat je in je scrumteam en met de business dit soort zaken via overleg kan oplossen. Overleg veel, tijdens de bouw, tijdens de test, tijdens de acceptatietest. Als je eerst te horen krijgt "Maak me niet uit" en later "Ik wil het toch anders", zie dat niet als een nadeel van de methode. Dit is juist een van de belangrijkste redenen waarom we geen functioneel ontwerpen meer schrijven, waarom we meer Agile willen werken. Vaak weet je pas echt wat je wil, als je het voor je ziet en je er werkelijk doorheen kan klikken.

Hoe ga je je hiermee om tijdens een acceptatietest? Overleg vooral goed of het verstandig is de nieuwe wensen direct op te pakken of door te schuiven. De sprint mag niet in gevaar komen. En het blijft: als het gebouwde aan de acceptatiecriteria voldoet, mag een wijziging in het gebouwde niet de oplevering in gevaar brengen. Wanneer dit wel het geval is, gaat het gebouwde zoals het is naar productie. Zonder wijzigingen. Dit klinkt streng, maar eigenlijk willen bijna altijd alle partijen dit. Ieder vanuit hun eigen belang. Mits de acceptatiecriteria een goede weergave waren van de echte wensen.

Maak daarom van een acceptatietest een test waarin de acceptatiecriteria altijd volledig gecontroleerd worden en leiden tot een betrouwbare acceptatietest. Zorg ervoor dat de acceptatiecriteria weergeven wat de business wil. En maak van de acceptatiecriteria geen weergave van wat het scrumteam wil weten. Dit zijn twee verschillende zaken. We moeten dan ook allemaal, hoe moeilijk het soms ook is, leren om deze twee soorten beschrijvingen los van elkaar te gaan zien. En het belangrijkste daarbij is vertrouwen. Vertrouwen dat je er zonder contract met handtekening, maar met overleg, ook wel samen uit gaat komen.

Sprint 0 of "Waarom wil je niet alles automatiseren"

Sprint 0, de start van een nieuw project. Voor mij een net afgerond traject. Tot mijn eigen verbazing bestaat de voorbereiding van een nieuw project voor mij vaak uit het beantwoorden van de vraag "Waarom wil je niet alles automatiseren?" Want juist bij Scrum en Agile wil ik niet alle testen automatiseren. Maar het lijkt wel of zo'n uitspraak in tegenspraak is met alles waar Scrum en Agile voor staan.  Heb ik dan echt zo weinig kennis van Agile en Scrum dat ik die verwachting voor testautomatisering nergens terug kan vinden?

Bij de start van een nieuw project is het altijd verstandig om stil te staan bij welke testen je wil automatiseren en welke niet. Performance gaat al snel naar automatisch testen. Testen van vormgeving vaak weer niet. En bij alle testen geldt ook voor mij: bij voorkeur automatisch. Maar dan moet het wel een meerwaarde hebben. Ik blijf er bij: het automatiseren van testen is geen doel, het is een middel om goede software te bouwen en te behouden. Levert het daaraan niet of nauwelijks een bijdrage, dan automatiseer je niet.

Dat is makkelijker geschreven dan bedacht. Want levert testautomatisering niet altijd een bijdrage aan het bouwen van betere software? Nee, naar mijn mening niet. Om een extreem voorbeeld te gebruiken: je kan vijfentwintig keer in een testcase testen of een knop de gebruiker van scherm 1 naar scherm 2 brengt. Maar als dat het enige is wat je test, heeft de test geen meerwaarde. De meerwaarde is er wel als de knop je van een invoerscherm naar een controlescherm brengt, waarin de ingevoerde gegevens opnieuw getoond worden. En elke testcase voor een bepaald invoerveld bijvoorbeeld een minimum of een maximale waarde test.

Dit kunnen de meeste testers zelf wel bedenken. Maar hoe zit het in deze situatie? Stel je hebt al een test, waarin je controleert of de waarde van een veld na de klik op een knop in het volgende scherm goed wordt meegegeven.  Heb je dan de testcase "Als de gegevens correct zijn, wordt na een klik op de knop het controle scherm getoond" nog wel nodig? Als aan deze eis niet voldaan wordt, zal ook het controleren van de waarde falen. Dat maakt de test overbodig. Een reden waarom ik nauwelijks testcases opstel en zeker niet automatiseer, die de navigatie tussen schermen controleren.

En stel nu dat je de vormgeving van een applicatie nog handmatig test. En het genoemde scherm krijgt bijna elke sprint  wel extra velden. Dus bijna elke sprint worden het invoerscherm en het controlescherm bij het handmatig testen van de vormgeving meegenomen. Neem maar rustig van mij aan, dat het niet uitmaakt wie het scherm test. Iedereen zal het laten weten als na een klik op de knop het controlescherm niet verschijnt. Automatisch testen voor de eerder beschreven testcase heeft in die situatie nauwelijks meerwaarde. Die paar keer dat het scherm in een sprint niet wordt aangepast, kan je hem wel handmatig testen.

Toch zijn er situaties waarin dubbel automatiseren wel een meerwaarde heeft. Als al tijdens het programmeren kan worden vastgesteld dat de knop niet meer werkt, kan de programmeur dat direct aanpassen. En dat heeft zeker voordelen. Maar vervolgens kan de knop best wel eens alleen werken in Firefox en niet in IE. Of de knop werkt ten onrechte niet, als het invoerveld "Geboortedatum" is leeg gelaten bij de persoonsgegevens. Vaak omdat de programmeur een foute aanname heeft gemaakt. Een aanname die herhaald is in zijn eigen automatische testen. In alle beschreven gevallen heeft de testcase dubbel automatiseren een meerwaarde. In het ene geval test je nu in een andere "omgeving", namelijk IE. In het andere geval is de automatisering om het werk te laten testen door een persoon die het werk niet gebouwd heeft. Een testprincipe wat ook bij testautomatisering erg belangrijk is.

Met een eenvoudig voorbeeld klinkt het misschien allemaal zo simpel en begrijpelijk. Ik heb in ieder geval mijn best gedaan om het zo begrijpelijk mogelijk op te schrijven. Maar zeker aan de start van een project is het dat niet, de te testen functies zijn zeker niet altijd zo simpel. Probeer het wel. Bedenk welke overlap de testen hebben. Sta stil bij de directe testen, maar ook de indirecte testen, zoals het klikken op knoppen bij het controleren van de vormgeving. Bedenk of het dubbel testen, al of niet automatisch, een duidelijke meerwaarde heeft. En maak je niet teveel zorgen over fouten. Als je te veel of te weinig meeneemt in je automatische test, je project is Agile. En dat betekent dat niet alleen de business, maar ook jij van mening mag veranderen.

Regressietesten in een Scrum traject

Als je testen volledig geautomatiseerd zijn, is het regressietesten in Scrum niet zo'n groot probleem. Dat gaat automatisch. Je moet alleen een plaats vinden voor de bevindingen. Maar wat nou als de testen niet geautomatiseerd zijn? Hoe ga je dan met regressietesten om? Ze kosten tijd en gaan over meerdere story's, dus een onderdeel van de story is niet eenvoudig. In deze blog wil ik beschrijven welke opties er zijn, want de keuze ligt in dit geval vooral bij jezelf.

Basisprincipes

Het belangrijkste is om een aantal basisprincipes aan te houden en af te spreken met het Scrumteam

1. Bevindingen worden zoveel mogelijk toegekend aan een story
   Wanneer uit de regressietest een bevinding komt, moet je altijd proberen om te achterhalen welke story deze veroorzaakt heeft. Dit geeft een beter zicht op het Scrum traject, doordat alle informatie rond een story bij elkaar blijft. Dus ook de bevindingen die tijdens een story ontstaan zijn. Daarnaast kan een bevinding beter gefixed en gehertest worden, als de bouwer de story kent en de tester weet wat de oorspronkelijke wens was. Zodat je rekening kan houden met het geheel, in plaats van de gehele bevinding.
2. Regressietesten moeten door iedereen in het team uitgevoerd kunnen worden
   Juist bij regressietesten moet je flexibel kunnen zijn. Veel keuzes in de aanpak vragen om de mogelijkheid dat ook andere teamleden meehelpen in de regressietest. Daarnaast kan er bij een regressietest snel tijdsdruk ontstaan, doordat dit vaak een van de laatste testen is. Dan is het handig als je extra handen kan inschakelen. En als je de enige tester bent: jij wordt ook wel eens ziek of gaat op vakantie!

Regressietest opnemen in een sprint

De regressietest kan je op verschillende manieren een plaats geven in de sprint. Alle varianten hebben zo hun voor- en nadelen. En ze zijn of meer geschikt voor handmatig testen of voor meer geautomatiseerde testen. Combinaties zijn natuurlijk ook mogelijk.

Regressietesten niet in de sprint backlog opnemen

Je kunt de regressietesten buiten de sprint backlog laten. In dit geval neemt de productiviteit van het team aan de sprint backlog af, waardoor je minder storypoints of uren in een sprint beschikbaar hebt. Je regressietest zal niet meegenomen worden bij de planning en standup, waardoor het volledig jouw verantwoordelijkheid is. Dit is tegen het idee om het hele team verantwoordelijk te maken voor het hele ontwikkelproces. Maar het grote voordeel is wel dat deze methode altijd kan. Hoeveel ervaring je ook hebt en hoeveel handmatige testen je ook hebt. Ook bij tegenstand vanuit het team of de organisatie om de regressietest een vast onderdeel van de sprint te maken.

Regressietest als aparte story opnemen

Om van een regressietest een aparte story te maken, heb je in ieder geval enig inzicht nodig hoe vaak je de regressietest uit gaat voeren. Je kunt altijd starten met een keer aan het eind van de sprint. Afhankelijk van de doorlooptijd van de regressietest kan je besluiten deze meerdere keren per sprint uit te voeren. Zorg in ieder geval voor een aparte taak per uit te voeren regressietest. Het voordeel is dat je een losse story kan plannen en bij de standup mee kan nemen.

Maar voor een losse story is veel draagvlak nodig in de organisatie en in het team. Want losse story's kunnen uit de sprint geschoven worden. En een regressietest kan daarmee als onnodig of onbelangrijk uit de sprint schuiven. Iets wat je als tester niet wil. Probeer daarom de regressietest zo hoog mogelijk in de sprint backlog geplaatst te krijgen. Neem hiervoor bijvoorbeeld het argument: "We vinden het als team het heel belangrijk dat het opgeleverde product minimaal dezelfde kwaliteit heeft als daarvoor. Daarom willen we dit testen en de bevindingen die deze kwaliteit verminderen altijd snel oplossen."

Regressietest binnen bestaande story's opnemen

De regressietest binnen bestaande story's opnemen is het meest ideaal. De regressietest gaat mee in planning en standup. En je hoeft niet bang te zijn dat de story uit de sprint schuift. Daarnaast is met deze wijze veel eerder duidelijk bij welke story een bevinding hoort.

Maar om dit voor elkaar te krijgen moet je heel goed kunnen inschatten wat voor regressietesten er voor een story nodig zijn. Voor een kleine aanpassing wil je geen regressietest van 8 uur moeten uitvoeren. En daarnaast kan in een regressietest vaak meerdere story's getest worden. De beste methode is om per story te bepalen of je de regressietest uit wil voeren. Bekijk daarna op basis van risico en je eigen ervaring welk deel van de regressietest je uit wil voeren. Kijk hierbij bijvoorbeeld naar regressietesten waarin het binnen de story aangepaste scherm gebruikt wordt. Of regressietesten waarin voorgaande of achterliggende processen van het applicatiedeel van story getest worden. Het kan in het begin verstandig zijn om aan het eind van de sprint als vangnet nog een volledige regressietest uit te voeren.

Kies je eigen methode

Er is geen standaard ideale oplossing. Alle oplossingen hebben hun voor- en nadelen. Kijk goed naar de doorlooptijd, naar je eigen kennis, naar je team. Als je het niet weet, begin gewoon zonder de regressietest in de sprint op te nemen. Kijk of je er een losse story van kan maken en probeer dat een sprint uit. En ga voor jezelf na of je het ziet zitten of de regressietest in de bestaande story's op te nemen. Weet je niet hoe, laat deze variant dan zitten. Het belangrijkste is dat de regressietest uitgevoerd wordt, de methode is van ondergeschikt belang.

Testen van een onbekende applicatie

Het mag niet. En toch komt het voor. Een applicatie testen waarvan je niet weet hoe die werkt. Ook in de Agile wereld. Want Agile wordt soms gebruikt om geen documentatie te schrijven. Tenslotte is werkende software belangrijker. Met als gevolg dat je als tester geen idee hebt wat je moet testen. Kan je dan wel testen?

Het beste voor het testen zou zijn als je zou weigeren. Als je totaal geen informatie hebt over de applicatie, dan is goed en betrouwbaar testen eigenlijk niet mogelijk. Maar weigeren is niet altijd een optie. Soms houdt weigeren in, dat een applicatie zonder getest te zijn naar productie gaat. Of je bent in een organisatie waar ze de informatie misschien wel willen geven, maar niet kunnen geven. De kennis is in de organisatie niet meer aanwezig of erg verspreid over verschillende mensen. Dan kan het verstandig zijn om toch te testen. Naar beste kunnen gezien de omstandigheden en garantie tot de deur. Maar toch, testen is dan de beste optie.

Hoe pak je dat aan? Het belangrijkste is je insteek als tester. Waar je anders test wat je weet of op papier hebt staan, moet je nu op een meer lerende manier testen. Je test wat je weet, maar zorgt er tegelijkertijd voor dat je via vragen meer te weten komt. De door mijzelf ontwikkelde aanpak bestaat uit vier stappen:

• Testen
• Noteren
• Informeren
• Doel bepalen

Testen

Als je niets weet, begin je met testen. Dit klinkt vreemd, maar er zijn testen die je altijd kan uitvoeren. Tijdens deze testen leer je de applicatie kennen, waardoor je leert welke vragen je moet stellen en welke onderdelen je uitgebreider moet testen.

Hieronder drie voorbeelden van testen die je altijd uit kan voeren

Navigatie-items test
Klik in een menu elk menu-item of klik in een knoppenbalk elke knop aan. Test voor zover je kennis nu reikt. Hoewel bij deze test de testwaarde minder is, is het een ideale manier om voor het eerst kennis te maken met de applicatie.

Twee test
Voer in elk veld twee waardes in. Vul elke tabel met twee rijen en elke verzameling met twee waardes. Bekijk elk getoond gegeven met minimaal twee waardes. Twee is hierbij belangrijk. Hiermee voorkom je dat je fouten mist, waarbij in een functie steeds dezelfde waarde wordt gebruikt. Of dat er in een verzameling of tabel slechts 1 item wordt getoond of opgeslagen.

Leeg test
Begin bij het invoerscherm met een volledig leeg scherm. Klik op Opslaan en vul vervolgens alleen de gevraagde waarde(s) in. Klik hierna weer op Opslaan. En ga hiermee door tot de invoer geaccepteerd wordt. Als je dit al weet of kan voorspellen, ga dan naar andere schermen, waar de ingevoerde gegevens gebruikt worden. Op deze wijze kan je nagaan of de applicatie goed kan omgaan met lege waardes. Worden deze goed getoond? En kunnen deze ingevoerde gegevens later nog goed gebruikt worden.

Noteren

Het verstandigste is om het noteren vrij vlak na het testen te doen. Het kan zelfs verstandig zijn om tijdens het testen al kort aantekeningen te maken. Het doel van het noteren is om vast te leggen waar je nog kennis te kort komt. Ongeacht of je hier antwoord op kan krijgen of niet. Als je antwoord kan krijgen, kan je later verder testen. Anders dient het als basis om anderen te informeren wat je niet hebt kunnen testen. En later om aan te kaarten over welke onderdelen er een kennisgat is.

Bij het noteren zijn er onderdelen die bijna altijd om meer kennis vragen

• Berekende gegevens
• Beslissingsprocessen
• Verdwijnende en verdwijnende velden

Informeren

Informeren is twee-ledig. Het belangrijkste deel is het verkrijgen van informatie over de genoteerde onderdelen. De vragen over deze onderdelen kan je het best stellen aan gebruikers of andere niet-IT'ers die kennis hebben. Dat is het meest objectief. Daarna komt de groep IT'ers die de software niet gebouwd hebben, denk hierbij vooral aan Functioneel Ontwerpers of andere functies die de software ontwerpen of bij het ontwerpen betrokken zijn. Maar je kan soms bijvoorbeeld ook heel veel kennis bij een helpdesk vandaan halen. En als derde kan je altijd de ontwikkelaar vragen hoe het moet werken. Dit is het minst objectief en zal dan ook voornamelijk tot doel hebben de bestaande applicatie in beeld te brengen. Toch kan je ook op deze wijze fouten ontdekken, omdat een ontwikkelaar ook als hij weet wat hij wil bouwen, regelmatig toch net iets anders bouwt.

Als het niet meer mogelijk is meer informatie te achterhalen, wordt het tijd om je teamleden en eventuele andere betrokkenen te informeren. Laat aan de hand van je notities weten wat je wel en wat je niet hebt kunnen testen. En bespreek met je team en eventueel met andere betrokkenen of dit voldoende is. Zo nee, kijk dan of zij nog een mogelijkheid zien of hebben om meer informatie te achterhalen.

Doel bepalen

Na het informeren heb je meestal meer kennis van hoe de applicatie moet werken. Vervolgens moet deze kennis weer omgezet worden in testen, b.v. met testtechnieken of checklists. Je zet de nieuw verkregen kennis dus om naar nieuwe testdoelen, om vervolgens de cyclus weer opnieuw in te gaan.

Tot slot

Ideaal blijft het niet om een onbekende applicatie te testen. En het blijft goed om ernaar te streven dit te voorkomen. Maar als het toch moet kan je door te testen ontdekken wat je niet weet. Vervolgens kan je dit vastleggen en ernaar informeren. Waarna je kan bepalen hoe je verder test. Op deze wijze kom je nog vrij ver. En je hebt een beter beeld van welke kennis je niet hebt. Beide zijn waardevol, voor nu en in de toekomst.

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.