Copyright All Rights Reserved © 2019 Salves

Ketentesten in de Agile Omgeving

Ketentesten in de Agile Omgeving
10 december '18
  • Deel dit bericht
  • linkedin icon

Ketentesten in de Agile Omgeving

door David Wellens

Ketentesten blijft een moeilijk gegeven. In elke organisatie ziet men het belang van ketentesten wel in. Telkens als er nieuwe functionaliteit wordt opgeleverd roept er altijd wel iemand in het SCRUM-team (hier verder ‘team’ genoemd): “We moeten wel even zeker weten of de keten het wel blijft doen.” En vervolgens blijft het –meestal– stil. Een ander voorbeeld: steek verschillende teams met afhankelijkheden ten opzichte van elkaar in een ruimte en het woord ketentest zal gegarandeerd vallen. Maar als iedereen naderhand de ruimte verlaat, zullen er weinig tot geen afspraken gemaakt zijn hoe de ketentesten binnen de organisatie verbeterd, of nog extremer, opgezet kunnen worden. Mijn ervaring leert me dat er meerdere valkuilen zijn als het gaat om het opzetten van een goede ketentest in een SCRUM-methodiek.

Teststrategie is essentieel

Bij softwareontwikkeling volgens het traditionele watervalmodel zijn alle blokken mooi afgelijnd en gedefinieerd. Men zal bijvoorbeeld nooit starten aan een systeem-integratie test als de componenten zelf nog niet afdoende getest zijn. Het te volgen traject is duidelijk en helder. Uiteraard is dit model niet dynamisch en kost het veel tijd om een potentially shippable product te leveren. Bij SCRUM, wat veel dynamischer is, wordt er gewerkt in iteraties van 1 tot 4 weken en is het minder duidelijk wanneer je de gehele keten gaat testen. Doe je een ketentest na elke iteratie? Of enkel voor een live-gang? Een goed overwogen teststrategie is van levensbelang in een Agile omgeving.

Ketentesten is bewustwording

Als je met meerdere teams te maken hebt met ieder een eigen agenda, planning en prioriteiten, dan is het van belang dat alle neuzen in dezelfde richting staan. Belangrijk om er voor te zorgen dat de teams samen een gemeenschappelijk einddoel hebben. Dat einddoel is een werkend end-2-end systeem waarbij ieder team vertrouwen heeft dat hun bijdrage aan de keten doet wat het moet doen in samenwerking met de rest van de systeem. Er moet daarom een gezamenlijke mindset en doel aanwezig zijn bij de teams. Uiteindelijk is het eindproduct datgene dat waarde toevoegt voor de organisatie. Geregeld zie je teams, bewust of onbewust, enkel belang hechten aan hun eigen deel van de keten. Dat is het deel waar ze verantwoordelijk voor zijn en waar ze op worden ‘afgerekend’ aan het eind van dag.

Ketentesten is verantwoordelijkheid nemen

En dat brengt ons naadloos bij het volgende pijnpunt: verantwoordelijkheid! Wie is er binnen een SCRUM-methodiek verantwoordelijk voor de volledige keten? Zolang dit niet duidelijk is, zal niemand zich geroepen voelen om de ‘burden’ van een ketentest op zich te nemen. Want er heerst al snel de gedachte dat je dan andermans werk aan het doen bent. Dat is volgens mij ook een belangrijke reden waarom er geen concrete afspraken gemaakt worden in een overleg met verschillende teams. Het levert extra werk op en je wordt bekeken als het eerste aanspreekpunt door de hele organisatie mochten er bevindingen uit de ketentest komen. Erger nog, zelfs als het in productie fout zou gaan. Als dit bovenop je dagelijkse werk komt is de kans groot dat je mensen, business of andere teams, binnen de organisatie moet gaan teleurstellen. Daarom speelt iedereen het op safe en kijken ze niet verder dan hun eigen team. Dit komt uiteindelijk de organisatie niet ten goede, omdat het eindproduct daar niet beter van wordt.

Hoe maak je van ketentesten een vanzelfsprekendheid?

Een organisatie moet de ruimte creëren waarin ketentesten worden uitgevoerd. Er moet tijd vrijgemaakt worden, net als dat er handvaten aan het team gegeven moeten worden. Pas dan wordt ketentesten een vanzelfsprekendheid. Dat doe je door bijvoorbeeld teamleden vrij te spelen om de basis op te zetten en een proces in te regelen. Hierdoor creëer je ook de nodige verantwoordelijkheid binnen teams om testen van een keten goed in te regelen.

Verder heerst er binnen een keten ook een stuk onwetendheid. Weten de teams van elkaar dat ze afhankelijkheden hebben? Een belangrijke stap is dat teams onderling weten waar elk team mee bezig is. Denk aan een Scrum of Scrums. Belangrijk is wel om vanuit hier terugkoppeling te geven naar de teams. Een stap in de goede richting is inzicht krijgen wie waar afhankelijk van is en dit in kaart brengen. Van daaruit kan je acties beginnen te definiëren en uitwerken.

Conclusie: ketentesten als wezenlijk onderdeel

Maak van ketentesten een vast onderdeel in de sprint van elke betrokken team waarbij één iemand de algemene regie van de ketentest voor de verschillende teams op zich neemt zodat iedereen zich betrokken voelt. Net zoals een vaste regressietest is een ketentest ook onderdeel van de Definition Of Done van de teams. Behandel het vooral niet als een onbelangrijk onderdeel van je ontwikkelingsproces! Geef daarbij het team de ruimte om deze ketentesten op te zetten en te onderhouden. Het zal in de beginfase wat meer tijd en geld kosten, maar op langere termijn is het vast en zeker de investering meer dan waard.