Testen tijdens een Scrumproject
Bij Netvlies bouwen we websites en applicaties volgens de projectmethodiek Scrum. Met Scrum realiseer je op een flexibele manier en binnen een vooraf bepaald tijdsbestek het best haalbare product. In korte periodes - Sprints - leveren we een werkend deelproduct op. Een divers team specialisten werkt parallel aan het product. Daardoor heb je kortere communicatielijnen en meer focus. Dit vraagt om intensieve samenwerking tussen het team en de klant. Daarom maakt de klant deel uit van het projectteam. De Product Owner (PO) is een afgevaardigde van de klant. De PO kan ter plaatse knopen doorhakken en vragen beantwoorden en houdt daarmee de vaart erin.
Wat de PO óók doet is - samen met de Tester - tijdens een Sprint de gebouwde functionaliteiten testen. Denk bijvoorbeeld aan een header op de homepage van een website. Ziet de header eruit zoals de klant verwachtte? Werkt de header goed op mobiel en desktop? Kun je in het Content Management Systeem (CMS) zonder problemen de content invullen? Wat gebeurt er als je in het CMS te veel tekst invult? Zijn alle verplichte velden verplicht gemaakt in het CMS? Een wat complexer voorbeeld is het testen van een inlogfunctie. Wat gebeurt er bij een succesvolle login? Of bij een verkeerd ingevuld wachtwoord, een verkeerd ingevulde loginnaam of een verkeerd wachtwoord én verkeerde loginnaam?
Tijdens een Scrumproject is er geen vast testmoment, omdat de Testers afhankelijk zijn van de voortgang van het team. Als alle onderdelen van de user story - een specifieke wens op basis van een afgekaderde functionaliteit die op basis van business value wordt ontwikkeld - klaarstaan, wordt de functionaliteit getest.
De meerwaarde van testen door de PO
Bij de start van een nieuw project krijg ik soms de vraag van een PO of het wel nodig is om het werk zelf te testen als er al een Tester in het projectteam zit. Testen door de PO heeft absoluut een grote meerwaarde! Als Tester kan ik niet bepalen of het gemaakte werk voldoet aan de wensen van de klant. Ik test verschillende scenario’s die gebruikers kunnen doorlopen bij een loginfunctie, kijk of een tekstcomponent stuk gaat als er te veel tekst in staat, maar ik kan niet bepalen of het opgeleverde werk voldoet aan de wensen van stakeholders of bepalen welke functionaliteiten de hoogste prioriteit hebben. De PO hakt hier namens de klant een knoop over door. Exact weten wat er is gebouwd, hoe het zou moeten werken en hoe het in de praktijk werkt, helpt om een weloverwogen beslissing te nemen.
Daarnaast bepaalt de PO de prioriteiten tijdens de Sprint. Welke user story moet als eerste worden opgepakt? Zijn de bevindingen van een Tester een bug, issue of optimalisatie? Moet een door de tester gevonden issue in dezelfde Sprint worden opgelost? Wordt een bug in een volgende Sprint opgepakt? Of kan de bug na livegang middels een ticket worden opgelost? Als tester kan ik hier uiteraard over adviseren.
Het grote voordeel van het testwerk is dat je als klant een heel goed beeld krijgt van wat er daadwerkelijk is opgeleverd. Je kunt direct controleren of het aan je wensen voldoet. Is dit niet het geval, dan kan het meteen worden opgelost. Ik zie het ook wel een beetje als sport om die ene verborgen fout er nog uit te halen! Het testwerk helpt ook om de Sprint Review goed voor te bereiden.
Netvlies helpt je goed op weg om met het testwerk aan de slag te gaan, bijvoorbeeld met uitleg over het digitale Scrum board in Jira. De samenwerking, communicatie en sfeer in het team heb ik sowieso als heel prettig ervaren.” - Paula Isphording, senior online marketeer bij Zicht, risico- en verzekeringsadviseurs
Waaraan voldoet een goede tester?
Als Tester heb je oog voor detail en ben je niet snel tevreden. Je probeert op de kleinste dingen te letten, doorloopt verschillende scenario’s en kijkt tegelijkertijd naar het totaalplaatje. Je voelt je verantwoordelijk en bent niet bang om vragen te stellen aan het team. Daarnaast is het handig als je voldoende kennis hebt van het CMS waarin je gaat testen. Heb je die niet, dan zorgen wij dat je die krijgt.
Voor het proces is het belangrijk dat je voldoende tijd beschikbaar hebt om te testen. Bijvoorbeeld een dagdeel per dag. Het is natuurlijk zonde als een user story lang open staat, omdat de PO deze nog niet heeft getest. Het is sowieso belangrijk dat je beschikbaar en goed bereikbaar bent voor het team. Dit kan zowel digitaal als fysiek zijn. Zolang de lijntjes maar kort blijven, bugs makkelijk kunnen worden doorgenomen en snel knopen worden doorgehakt.
Tot slot heeft een goede PO mandaat. Je kan en mag beslissingen nemen voor het bedrijf en hoeft niet alles intern na te vragen. Dat geldt natuurlijk ook voor het testen en verifiëren van user stories. Zo houden we de vaart erin.
Team effort
Een dubbelrol als PO en Tester klinkt misschien zwaar, maar in de werkzaamheden zit veel overlap. Of je nu testwerkzaamheden uitvoert of niet, het is hoe dan ook de taak van de PO om user stories te verifiëren en te bepalen of en wanneer een bug wordt opgepakt.
De Scrum Master en ik begeleiden en ondersteunen je, zodat je je werk zo efficiënt mogelijk kunt uitvoeren. Zo krijg je voor de start van het project een PO training en indien nodig een CMS training. Ik leg je uit hoe het digitale Scrum board in Jira werkt, hoe je de voortgang in Jira bekijkt en bijhoudt en hoe je bugs en andere bevindingen van je testwerk in Jira vastlegt. Indien nodig lopen we samen door het testwerk heen. Bovendien ben ik altijd bereikbaar voor vragen en om te sparren. Een Scrumproject is immers een team effort. Je hoeft het dus absoluut niet alleen te doen!
Begrippenlijst
- Sprint: een iteratie van 2 of 3 weken waarin een multidisciplinair team een set van wensen (user stories) oppakt.
- User story: één specifieke wens op basis van een afgekaderde functionaliteit.
- Product Owner: de afgevaardigde van de opdrachtgever die bij het team op kantoor zit. De PO kan ter plaatse knopen doorhakken en vragen beantwoorden en houdt daarmee de vaart erin. Het is belangrijk dat de PO hiervoor voldoende tijd en mandaat krijgt van zijn of haar organisatie.