Agile / scrum vs waterval wat zijn de verschillen voor de tester

Veel organisaties zijn de laatste jaren van een Waterval methode naar een Agile methode overgeschakeld, met name in de software ontwikkeling is het aantal agile projecten sterk gestegen. In deze blog zal ik beschrijven welke veranderingen dit teweeg brengt voor een tester.

Wat is het verschil tussen Waterval en Agile/scrum

Traditionele projecten (Waterval) werden over het algemeen als volgt doorlopen. Eerst voerde de analist de analyse uit en bedacht wat er gebouwd diende te worden. Vervolgens maakte de designer op basis van deze informatie een ontwerp. Als dit klaar was ging de programmeur aan de slag om de code te schrijven. Als dit allemaal klaar was ging de tester aan het werk om te kijken of de eerder gemaakte afspraken bewerkstelligt waren.

Bij een agile/scrum project werkt dit anders. Bij een Agile/scrum project word het grote project opgebroken in kleine stukjes (user story’s genoemd) deze user story’s worden dan 1 voor 1 opgepakt alle disiplines werken tegelijk aan de zelfde user story (zoals de afbeelding hieronder weergeeft). Dit is goed mogelijk doordat je als tester binnen een user story ook alleen maar dat stukje functionaliteit hoeft te testen wat in de user story beschreven staat, zolang er nog niks fuctioneels af is kan een tester zich bezig houden met het opstellen van de testgevallen/testscripts.

Dit is slechts een klein deel van de verschillen tussen agile/scrum ten opzichte van waterval. Omdat dit niet een blogpost is om uit te leggen hoe agile/scrum projecten precies werken zal voor nu niet verder worden ingegaan op deze verschillen.

Testen binnen waterval (V-model)

Als we het over testen hebben binnen een waterval project dan kan je bijna niet om het V-model heen. het V-model is een software ontwikkel methode die gebaseerd is op de relatie tussen elke fase van ontwikkeling ten opzichte van elke fase van testen (zie afbeelding hieronder).

In de linkerkant van het V-model staan de fasen waarin het systeem wordt gebouwd/verbouwd van requirement t/m coding. Aan de rechterkant van het model staan de verschillende testsoorten. deze testsoorten worden niet allemaal uitgevoerd door de tester, hier zitten ook testen tussen die door bijv de ontwikkelaar (unit testing) of klant/accepterende partij (User acceptance testing) worden uitgevoerd.Het idee van het V-model is om voor elke fase in ontwikkeling een bijpassende testmethode te hebben. de verkregen informatie in de ontwikkelfase is dan ook de input voor het opstellen van testgevallen.

Wat zijn de voordelen en nadelen van waterval (V-model)

Wat zijn de nou eigenlijk de voor en ook nadelen van het uitvoeren van een project via de waterval methode

Voordelen van waterval (V-model)

Elke fase van integratie wordt getest, dus er wordt op alle verschillende niveaus getest.
Eventuele fouten die zich voordoen in een bepaalde fase worden ook in die fase opgelost.
De nadruk ligt op de proces doorstroming wat het goed mogelijk maakt een kwalitatief goed product te maken.

Nadelen van waterval (V-model)

Waterval gaat er vanuit dat tijdens de bouw de requirments niet veranderen, iets wat in de praktijk regelmatig wel voor komt.
Het ontwerp wordt niet tussentijds geverifieerd.
De vereisten worden niet geverifieerd.
Het testen van een fase wordt pas gedaan als deze fase ook echt klaar is. dit zorgt ervoor dat fouten soms ‘laat’ gevonden worden. Bij agile/scrum projecten vindt het testen al plaats tijdens het ontwikkelen hierdoor kom je potentiele problemen eerder tegen. Hoe eerder je fouten in je proces kunt herstellen des te goedkoper het is.

Wat is de Agile/scrum methode

Agile/scrum is ontwikkeld als antwoord op de negatieve eigenschappen van de waterval methodiek. Binnen waterval is 1 van de grootste problemen dat requirements vaak veranderen, dit is iets waar de waterval methode niet goed mee om kan gaan. Binnen agile/scrum wordt hier wel erg goed mee om gegaan.Het gehele team is verantwoordelijk voor de kwaliteit van het op te leveren product. Er wordt strak samen gewerkt tussen de verschillende disciplines. Het is niet zo dat de tester als enige testen uitvoert/opstelt dit kan ook door andere teamleden opgepakt worden. Eveneens kan de tester ook bezig gaan met analyse, ontwikkelwerk of documentatie. Binnen de waterval methodiek zie je vaak dat de testers alleen verantwoordelijk voor worden gehouden voor de kwaliteit van het op te leveren product.

Als een project wordt gestart wordt de te bouwen software in zo veel mogelijk kleine stukjes werk (ook wel User Story’s genoemd) verdeelt dit om er voor te zorgen dat deze zo snel mogelijk uitgeleverd kunnen worden naar de klant. Het doel van een agile project is om zo snel mogelijk een werkend product op te leveren naar de klant, en om die vervolgens steeds verder te kunnen verbeteren/uitbreiden. Om dit te kunnen doen bestaat een project uit een aantal ontwikkelcyslussen (ook wel sprints genoemd).

Om deze methodiek goed toe te kunnen passen moeten bedrijven hun manier van denken ten opzichte van ‘levering naar een klant’ en ‘werken met lose ontwikkel, analyse en test teams’ veranderen. Als dit niet gebeurd is het eigenlijk onmogelijk om een goed agile/scrum project uit te voeren.Er zijn vele variaties op agile/scrum, ieder bedrijf past dit op een manier toe die voor hun het beste werkt. De hierboven genoemde informatie is de basis en deze zal in grote lijnen binnen alle varianten hetzelfde werken.

Testen binnen Agile/scrum

Testen binnen een Agile/scrum team is een groot verschil ten opzichte van de waterval methode. Het grootste verschil is waarschijnlijk wel dat je zo snel mogelijk gaat testen vanuit het perspectief van de klant.

Enkele uitdagingen die je als tester binnen een agile/scrum team kunt verwachten zijn:

Als tester heb je niet de beschikking over een document waar alle requirements (bijvoorbeeld een functioneel ontwerp (FO)) staan. Wel heb je beschikking over kleinere documentatie in de vorm van Story’s hierin zijn de requirements vaak veel minder ver gespecificeerd als in een Functioneel Ontwerp.
Doordat je zo snel mogelijk start met testen test je vaak op code die nog niet af is, dus er kan niet vanuit gegaan worden dat de hele aanpassing in 1 keer goed werkt.
Er zullen meer release momenten zijn hierdoor wordt de regressietest van veel groter belang.

Enkele skills die belangrijker zijn in een agile testproces zijn domein kennis, het begrijpen van de technololgie die gebruikt wordt en technische kennis om beter mee te kunnen praten met de ontwikkelaars binnen je project.

Wat zijn de voordelen en nadelen van agile/scrum

Ook de agile/scrum werkwijze heeft natuurlijk zijn voor- en nadelen.

Voordelen:

Verkort de test cyclus binnen een project doordat testen plaats vindt parallel aan de ontwikkel activiteiten.
Doordat testen parallel loopt aan de ontwikkeling van het product, zorgt dit ervoor dat er eerder bij kan worden gestuurd indien zich kwaliteitsproblemen voordoen.
Doordat stukjes die klaar zijn opgeleverd worden aan de product owner (vaak de klant), kan er nog bijgestuurd worden mochten de requirements van de klant veranderen.

Nadelen:

De requirements zijn laat in het proces duidelijk en over het algemeen in minder details beschreven dit kan doordat er veel communicatie onderling is. dit is met name een nadeel als er een nieuw iemand binnen het team komt te werken omdat hij niet bij alle communicatie aanwezig is geweest. Tevens kan het in minder details beschrijven van de requirements ook negatieve gevolgen hebben wanneer de teamwork of communicatie niet goed is. In dit geval zullen er sneller misverstanden ontstaan.
Doordat requirements veranderen wanneer het project al in ontwikkeling is kan dit er voor zorgen dat de scope niet duidelijk is en deze continue verschoven wordt. Dit kan lijden tot projecten die nooit klaar zijn. Tevens wordt een project veel minder voorspelbaar doordat er nog veel kan veranderen. Dit maakt het moeilijk om een goede business case op te stellen en maakt het eigenlijk onmogelijk een vaste prijs afspraak te maken.

Waarom zou een tester blij moeten zijn dat agile/scrum tegenwoordig vaak verkozen boven de waterval methode

Als vanuit waterval naar een project wordt gekeken zit de testfase altijd aan het eind van het project. Als je er vanuit gaat dat een project nooit uitloopt dan is dit geen probleem maar in de praktijk blijkt het dat projecten vaak uitloop hebben. Binnen de waterval methode zorgt dit er vaak voor dat de testfase ingekort wordt en er dus minder tijd overblijft om goed te kunnen testen. Doordat agile/scrum een methode is waarbij functionaliteit in user story’s wordt verdeeld en deze ook 1 voor 1 opgepakt moeten worden zorgt dit ervoor dat het onmogelijk is om ver achter te lopen als tester.

Bij agile/scrum projecten is een goede regressietest wel van nog groter belang als bij de waterval methode. Dit komt omdat er nog gewerkt wordt aan nieuwe functionaliteit terwijl er al wel getest wordt. Het is dan ook van groot belang om een up-to-date regressietestset te hebben waar ook de nieuw gebouwde functionaliteit in verwerkt zit.