De rol van testen binnen Agile/Scrum
11 mei 2020 
in Scrum

De rol van testen binnen Agile/Scrum

Er wordt veel gesproken en geschreven over het realiseren van de Agile waarden door het toepassen van Scrum.

Veel organisaties zijn dan ook de afgelopen jaren overgestapt op het werken volgens Scrum. Wat ik in de praktijk echter hoor en zie (en ik ben helaas niet de enige) is dat medewerkers in een organisatie ervaren dat er enkel Scrum in the name only wordt gedaan. Blijkbaar lukt het nog niet helemaal of ervaren de medewerkers het nog niet zo.

Een ander punt dat veel gespreksstof oplevert is dat er organisaties zijn die vinden dat:

  • testers geen plaats meer hebben binnen Scrum. De developers moeten gaan testen en dat dan met name door geautomatiseerd te testen
  • testers moeten meer technische skills krijgen om zodoende breder inzetbaar te zijn binnen het development team. Dit kan betekenen meer kennis over het gebruiken van testtools tot het kunnen programmeren. Bij Scrum gaat het tenslotte om teams met multidisciplinaire teamleden. Of anders gezegd teamleden die meerdere dingen kunnen doen.
  • etc.

Deze punten zorgen ook voor onrust onder testers. In dit blog wil ik een praktijkvoorbeeld onder jullie aandacht brengen, die ik een tijdje geleden tegenkwam op het internet. Een voorbeeld die laat zien dat het ook anders kan lopen.

Doel van Agile werken

Maar eerst even terug naar de basis. Wat verwacht een organisatie eigenlijk te bereiken met Agile werken? Agile kan helpen om organisatiedoelen te realiseren.

Dat doel kan voor iedere organisatie anders zijn, maar denk bijvoorbeeld aan:

  • realiseren van een kortere time to market
  • verhogen van de klanttevredenheid en nieuwe klanten werven
  • met gemotiveerde professionals innovatieve producten te maken
  • het verlagen van de kosten van ontwikkeling en beheer
  • de kwaliteit van producten en diensten te verbeteren
  • realiseren van een effectievere samenwerking tussen ontwikkeling en beheer
  • …?

Doelstellingen die door de organisatie moeten worden gedefinieerd en uiteraard breed binnen de organisatie moeten worden gecommuniceerd.

En dan hebben we gelijk de eerste valkuil te pakken. Veel organisaties blijven namelijk steken bij het directiebesluit dat hun organisatie Agile moet gaan werken.

En welke rol speelt Scrum dan?

Scrum is één van de Agile frameworks en kan worden ingezet om in teamverband op een effectieve, flexibele manier software te ontwikkelen.

De kern van Scrum is een multidisciplinair en zelfsturend team. Samen pakt het team het werk op. Iedereen is betrokken bij het plannen, benoemen van blokkades en het verdelen van de taken. Daarbij gaat Scrum ervan uit dat de benodigde kennis in het team zelf aanwezig is.

 

 

 

 

Welke voordelen zijn er met scrum te behalen?

  • Het kan de effectiviteit van een team verhogen.
  • Het kan bijdragen aan een optimale Return On Investment (ROI) .
  • Het kan ervoor zorgen dat je iedere 2-4 weken een stuk werkende software oplevert.
  • Het kan ervoor zorgen dat je inzicht hebt in de voortgang van de ontwikkelingen.
  • Het kan ervoor zorgen dat je enkel bouwt wat je nodig hebt.

Ik heb bewust bij bovenstaande punten het woord “kan” gebruikt. Het is namelijk niet zo dat door het enkel toepassen van Scrum je  de genoemde voordelen altijd zult behalen. Er komt namelijk meer bij kijken. Wanneer je verschillende rollen (informatie analist, developer, tester, business, etc.) bij elkaar zet heb je wel een multidisciplinair team, maar niet per definitie ook een team met multi inzetbare teamleden. Agile werken vraagt om een verandering in de mindset van de teamleden, een verandering die in gang moet worden gezet en die niet zomaar met een druk op de knop voor alle teamleden te realiseren is. Wanneer deze verandering niet in gang wordt gezet zie je in de praktijk dat de teamleden hun oorspronkelijke rol zullen gaan vervullen. En dit zorgt er dan weer voor dat scrum uitmondt in kleine watervallen, met dezelfde problemen. Zoals bijvoorbeeld dat het testen weer op het kritieke pad komt, dat binnen een sprint niet alles afgerond wordt en dat het resultaat van een sprint een niet releasebaar product is.

Een voorbeeld uit de praktijk

Natuurlijk zijn er coaches die scrum teams kunnen begeleiden in het noodzakelijke veranderingsproces. Menigeen heeft echter geen goed beeld van hoe zo'n veranderingsproces in de praktijk er uit kan zien en hoe lang het kan duren voor er resultaat behaald kan worden. Dat is voor mij de aanleiding om bij jullie een praktijkvoorbeeld van Atlassian onder de aandacht te brengen. Atlassian is onder andere de ontwikkelaar van Jira. Een systeem dat door menigeen van jullie in de praktijk wordt gebruikt voor bevindingenbeheer en/of ondersteuning van het Scrum proces. In dit praktijkvoorbeeld kun je zien welke stappen zijn ondernomen om van developers betere testers te maken en de inbreng van testers te veranderen naar coach, opleider en reviewer.

Dit praktijkvoorbeeld is niet bedoeld als de oplossing, maar als een mogelijk oplossing. Er zullen ongetwijfeld sceptici zijn die allerlei tegenwerpingen hebben zoals:

  • zo werkt dat niet bij ons
  • developers kunnen niet testen
  • testers kunnen niets anders dan testen
  • wat is er gebeurt met developers of testers die niet konden of wilden veranderen
  • kost het het wel minder geld
  • etc.

Bekijk het echter met een open mind, kijk naar wat wellicht wel mogelijk is binnen jouw team of organisatie. Zie het als een inspiratiebron. Wat mij met name opviel is dat het allemaal om personen gaat en niet om code, dat het werk van zowel developers als testers is veranderd, dat er meerdere veranderingen in de loop van de tijd zijn geïmplementeerd (Rome is ook niet in een dag gebouwd), dat coaching, opleiden en doorzettingsvermogen een belangrijke rol speelt en dat het niet in een paar weken is te realiseren.

Daarnaast zal het ook zo zijn dat niet alle teamleden zullen kunnen meekomen in het veranderingsproces. Zijn het daarmee dan ook per definitie slechte developers of testers? Nee, sterker nog het zouden wel eens hele goede developers/testers kunnen zijn, die een waardevolle bijdrage kunnen leveren aan het behalen van de bedrijfsdoelstellingen, alleen niet binnen een scrum werkwijze. Het management van organisaties moet dan ook goed nadenken over hoe hiermee om te gaan. De “makkelijkste” weg is om afscheid te nemen van deze medewerkers. Maar is dat wel zo'n goed idee in een arbeidsmarktsituatie waarbij het tekort aan IT'ers de komende jaren enorm gaat toenemen. Of moeten organisaties de keuze maken om niet alle ontwikkeling met Scrum te doen. Ik denk het laatste en wel om de reden dat Scrum niet voor alle “projecten” de enige mogelijke aanpak is om succesvol te zijn.

Veel kijkplezier en ik ben uiteraard benieuwd naar jullie reactie.

Over de schrijver
Ik ben sinds 1983 werkzaam binnen de ICT. Ooit begonnen als Cobol en Credit programmeur en vervolgens de wereld van kwaliteitszorg en testen in gerold. In 1990 ben ik betrokken geweest bij de ontwikkeling van TMap® De jaren daarna heb ik vele functies vervuld binnen het testwerkveld. Waarbij coaching en doceren mij altijd erg is bevallen. Bij Cygnus ben ik met name verantwoordelijk voor het ontwikkelen van content en opleidingen. Heb je een testinhoudelijke vraag of wil je sparren over het stoppen van software fouten bij de bron? Neem dan gerust contact met mij op. Uiteraard ben ik ook beschikbaar voor consultancy opdrachten en coaching.
Reactie plaatsen

arrow_drop_up arrow_drop_down