Beter software testen in Scrum

Scrum is een framework voor teams om complexe systemen en producten te ontwikkelen. Wanneer je software testen goed toepast, is dit al complex van zichzelf. Hoe combineer je iets dat al complex is van zichzelf met een framework dat is ontwikkeld om complexe systemen en producten te ontwikkelen? Het is niet zo gek dat veel bedrijven kampen met een juiste manier van het toepassen van software testen binnen Scrum.

Een stukje geschiedenis

Scrum is een populair framework voor software-ontwikkeling dat begin jaren 90 is ontstaan, het wordt tegenwoordig door veel bedrijven gebruikt. Bij het toepassen van Scrum dient men aan bepaalde voorschriften en regels te voldoen. Voordat Scrum bestond werkten veel bedrijven volgens de Waterfall-methode van software-ontwikkeling. Dit werkte op veel vlakken erg goed, echter er was weinig rekening gehouden met voortschrijdende inzichten. Kortom, zoals het was uitgedacht, zo moest het gaan werken. Een de ene kant is dit voor software testers natuurlijk ideaal om een planning op te maken. Je weet namelijk precies wat er aan komt, wat de feiten zijn en met feiten kun je gemakkelijk testgevallen maken. Dit is de theorie, echter in de praktijk bleek altijd dat de requirements (eisen) naar verloop van tijd toch wel werden aangepast, middels Request For Changes (RFC's), want niemand wil daadwerkelijk een systeem bouwen waarvan blijkt dat het uiteindelijk toch niet werkt.

Dit betekende wijzigingen in het testplan, de chronologische volgorde van testen, de manier van testen (testmethode), andere testtechnieken moesten worden aangewend, etc, etc. Kortom, de Waterfall-methode en software testen gaat alles behalve perfect samen.

De eerste paradox

Als je alle theorie even weglaat en je beantwoordt de volgende vraag: "Wanneer verwacht je een testplan, bij een simpel te testen klein informatiesysteem of bij een complex groot product?". De meeste mensen zullen logischerwijs antwoorden: "bij het grote systeem". Dit is ook logisch, want je wilt overzichtelijk hebben wat er getest is, welk deel nog getest moet worden, je wilt een beeld hebben van wat de totale testinspanning is en wanneer testen klaar is. Een testplan is in theorie veel gemakkelijker te lezen wanneer het deel aan te testen werk statisch is. Scrum zorgt er echter voor dat de testwerkzaamheden per Sprint ontzettend dynamisch zijn. Het is echter niet juist om te stellen: "Wij doen nu aan Scrum, dus we hebben geen testplanning meer nodig".

De tweede paradox

Scrum definieert drie rollen, namelijk de project owner, het ontwikkelteam en de Scrum master. Heb je wel eens een huis proberen te bouwen met mensen die allemaal 'timmerman' als rol hebben? Waarschijnlijk niet. Wat software testen moeilijk maakt is dat er ontzettend veel diversificatie is, of specialisatie zo gewenst. Dit is niet voor niets, software testen is complex en er zijn veel takken van sport bijvoorbeeld: Gebruikers Acceptatie Testen, Testautomatisering, Systeem Integratie Testen, Ketentesten, Acceptatietesten, Unit testen, Systeem testen, Functioneel testen, Technische testers (code), Test Manager, en Testcoördinator.
Je ziet, de moeilijkheid zit hem dus in het feit dat Scrum voorschrijft dat er een ontwikkelteam is daar waar de specialisatie binnen software testen enorm groot is. Dit moet je als bedrijf zelf dus in de gaten hebben en goed stroomlijnen.

De oplossingen

Wat erg belangrijk is om te beseffen is dat Scrum allesbehalve een vrijbrief is om ad-hoc te werk te gaan. Natuurlijk, Scrum is iteratief en incrementeel en het houdt rekening met voortschrijdende inzichten, wat voor het software testen zorgt dat het dynamisch kan meebewegen binnen het project. Echter wat vooral niet vergeten moet worden is dat er over testplanning nagedacht dient te blijven worden. Dit blijft ten opzichte van de Waterfall-methode minstens zo belangrijk, zo niet belangrijker.

Omdat er zoveel kan wijzigen in de eisen en wensen (de requirements) is het juist erg belangrijk om focus te houden op chronologische volgordes van software testen, als ook het bewaken van de totale scope in het software testen, deze kan namelijk snel slinken of groeien. Het is belangrijk om het juiste plaatje van nog af te ronden testwerkzaamheden te hebben.

De reden om hier als bedrijf zo scherp op te zitten is heel duidelijk. Wanneer je dit namelijk los zou laten, zou dat betekenen dat er niet meer goed gewaarborgd is dat alles goed getest is. Men gaat het voor lief nemen omwille van de bouwprogressie en soms omwille van de tijd. Met als gevolg een instabiel systeem vol met softwarefouten.

Eenmaal dit pad ingeslagen valt dit nauwelijks meer terug te draaien. Dit komt omdat wanneer een informatiesysteem een bepaalde mate van progressie heeft doorgemaakt en je voegt daar nog een feature of module aan toe, dat het testwerk niet evenredig toeneemt, maar sterk exponentieel. Met terugwerkende kracht deze testwerkzaamheden weer gelijk trekken is in vele gevallen onmogelijk.

Anekdotisch voorbeeld: stel je hebt drie mensen die een voetbal rondspelen. Hoeveel combinaties van de bal rondspelen heb je dan? Nu voeg je slechts één persoon daaraan toe, nu is men met vier. Hoeveel combinaties van de bal rondspelen heb je dan nu? Dit is is niet slechts één meer, maar er komen vele combinaties bij.

Dit is de reden waarom je software testen nooit achterstallig mag laten worden en dus de reden dat een goed management van het software testen binnen Scrum essentieel is.

Lees verder

• Software testen in Scrum
• De kracht van functionele testers
• Mijn visie op: de moeilijke aspecten in het software testen
• Het software testproces versnellen
• Software testen in ITIL