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.