Software testen in Scrum

Scrum bestaat alweer sinds de vroege jaren 90, maar bedrijven kampen er soms mee dat het software testen binnen een Sprint best wel voor veel moeilijkheden zorgt, zo niet hoofdzorgen. Hoe komt het toch dat software testen ook binnen Scrum soms zo'n moeizaam proces is en is het dan niet mogelijk om het software testen soepeler en overzichtelijker te laten verlopen? Een heldere kijk op antwoorden op deze vragen en andere aspecten binnen een met behulp van de Scrum-methode toegepaste software-ontwikkeling.

Wat is Scrum?

In het kort is Scrum een Agile-aanpak, dat als framework kan worden ingezet om software te ontwikkelen. Scrum is populair omdat het niet al te moeilijk is, maar met name omdat het weinig overheid oplevert. Scrum verhoogt de effectiviteit van het ontwikkelteam. Een Sprint is telkens een periode van één tot vier weken waarin men de software-ontwikkeling doet.

Wat is Software testen?

In het kort is het testen van software het vaststellen in welke mate de software aan de eisen voldoet. Testen kan ook worden gedefinieerd als 'een verzameling activiteiten die uitgevoerd worden om een of meer kenmerken van een product, dienst of proces vast te stellen volgens gespecificeerde procedures'.

Tot de kern

Waar dient men rekening mee te houden wanneer software testen plaatsvindt binnen Scrum?

In het software testen zijn er verschillende disciplines zoals systeemtesten, unit testen, functioneel testen, maar ook gebruikersacceptatietesten en productie acceptatietesten. Daaraan ten grondslag (de manier waarop of de invulling daarvan plaatsvindt) liggen o.a. geautomatiseerd testen en regressietesten.

Kortom allerlei rollen die gezamenlijk ervoor zorgen dat het testen binnen een organisatie op een juiste manier geschiedt. Het belangrijkste om te beseffen is dat alleen een constructieve samenwerking tussen deze rollen ervoor zorgt dat software testen goed gaat. Veel verschillende specialisaties dus. De moeilijkheid zit hem nu in het feit dat binnen Scrum er slechts één rol is gedefinieerd, namelijk die van 'developer'.

Wat zijn de moeilijke kanten van software testen binnen Scrum?

Er zijn meerdere aspecten die software testen binnen Scrum soms best wel lastig kunnen maken. Een van de belangrijkste is dat bij het behalen van de doelen, de 'definition of done's' vaak rekening wordt gehouden met het tackelen van een probleem op het vlak van programmeren, architectuur en logica van functies, maar minder op het gebied van "hoe zorgen we er nou voor dat het testen af komt?". De focus op het halen van de Sprint houdt er soms geen rekening mee dat er in het software testen heel erg gemakkelijk een uitloop aan doorlooptijd kan ontstaan. Een buffer hiervoor is dan vaak niet of nauwelijks ingebouwd, wat ervoor zorgt dat testwerkzaamheden worden doorgeschoven.

Een andere moeilijkheid is dat door de definitie van 'developer' binnen Scrum er wat minder overzicht kan zijn over de specialistische vakinhoudelijke kennis van de software tester. Onbekend maakt dan onbemind blijkt dikwijls en het is dan lastig om ervoor te zorgen dat de juiste persoon (in de vorm van het type software tester) zijn taken kan volbrengen. Een oplossing kan zijn om in het Scrum-team de term 'developer' aan te houden, maar binnen het testteam, zodra zij zich hebben gericht op een sprint backlog item, hier wat meer inzage en duidelijkheid over te geven. Dit om met name de complexiteit van het software testproces niet op te laten lopen.

Wat kan verder helpen om het proces te versoepelen?

Testgevallen bedenken en controleren op de compleetheid van alle testgevallen kan in sommige gevallen alleen door ervaren senior software testers. Dit komt omdat zij de technieken en methoden met behulp van bijvoorbeeld TMap of ISTQB geleerd hebben en beheersen om vervolgens te kunnen bepalen hoeveel scenario's of testgevallen er voor een bepaalde functionaliteit zijn. (Dit wordt uitgedrukt in bijvoorbeeld de testdiepte en de testmaat, begrippen in het software testen).

Maar als eenmaal bepaald is welke testgevallen er zijn kunnen deze uitstekend door andere personen worden uitgevoerd. Aangezien Scrum aanstuurt op 'joint effort', is het dus aan te bevelen om, daar waar het kan, andere 'developers' uit het Scrum-team te laten bijspringen. Zij kunnen dan ook testtaken oppakken, als men merkt dat anders het totale testwerk dat er voor een Sprint staat, bij lange na niet gehaald wordt. Sterker nog, het is eigenlijk aan te bevelen om hier tijdens de Sprint backlog-planning rekening mee te houden. Sommige bedrijven stellen het zelfs zo dat zij zeggen: "Het werk is pas af, zodra het testwerk ook klaar is, het is onderdeel van het geheel". Dit zorgt er in ieder geval voor dat testen niet te licht wordt opgevat.

Ook zorgt dit ervoor dat naast het behalen van de Sprint backlog-taken het software testen niet langzaam naar de achtergrond verdwijnt. Met meer focus op software testen blijft de totale kwaliteit van de software beter gewaarborgd, ook wanneer de Scrum-methode wordt toegepast.

Lees verder

• Beter software testen in Scrum
• Mijn visie op: de rol van het softwaretestteam
• Testmanagement en -coördinatie
• Uitleg over softwaretest-rollen
• De termen 'quality assurance' vs 'software testen' uitgelegd