Delen Printen E-mail

Toen ik vorig jaar na drie weken vakantie terugkwam op mijn opdracht, bleek tot mijn verbazing dat er in de tussentijd niets was getest door mijn teamleden.

Ondanks dat ik van tevoren testscripts had voorbereid en aan hen had overgedragen, kon ik bij terugkeer precies verder waar ik voor mijn vakantie was gebleven. Alleen de deadline was nu een stuk dichterbij gekomen – en die haalden we dan ook niet.

In ons team met twee backenders en een functioneel ontwerper was ik de enige tester, maar ik vond dit geen goede gang van zaken: we konden niet beweren dat we een Agile team waren terwijl in afwezigheid van iemand het werk stilviel. Daarom besloot ik hier wat aan te doen: ik ging mijn teamleden leren om mee te testen. Dat bleek alleen makkelijker gezegd dan gedaan. Daarom ging ik op zoek naar de redenen waarom mijn teamleden niet mee testten.

Ik vond verschillende oorzaken, zowel in ons team als in ons proces. Binnen ons team leken mijn teamleden ten eerste niet zo gemotiveerd om te testen. Dat vonden ze toch meer iets voor de tester. Dit was gelukkig makkelijk verholpen door hen eraan te herinneren dat we als Agile team samen verantwoordelijk zijn voor de kwaliteit van ons werk, en niet alleen ik als tester. Ten tweede hadden mijn teamleden geen ervaring met het bedienen van de applicaties in de keten. De backenders wisten precies welke interfaces er onderwater tussen twee applicaties lagen, maar hadden de frontends van die applicaties vaak nog nooit gezien. Dat gaf een drempel om een testscript uit te gaan voeren.
Binnen ons proces werden we gehinderd doordat de product owner de scope van onze sprint steeds aanpaste en er issues in bleef zetten. Daardoor hadden we geen overzicht van welk werk we nou echt moesten doen en hadden we ook geen idee van onze velocity. Dat gaf veel afleiding in onze sprints.

Ik besloot het makkelijkste eerst aan te pakken: door mijn teamleden onder begeleiding een happy flow door de keten te laten halen ging ik ze ervaring laten opdoen met de ketenapplicaties. Het probleem was alleen dat we daar nooit de tijd voor vonden en dat dit achterop geschoven raakte. Toen realiseerde ik me dat we daar nooit aan toe kwamen door de scopewijzigingen in onze sprint – een probleem dat aanvankelijk weinig met het niet mee testen te maken leek te hebben, maar toch als eerst aangepakt moest worden. We hielden scopewijzigingen in onze sprint tegen en spraken de product owner hierop aan. Lange tijd had dat geen effect, tot de boodschap na een discussie tussen team en product owner eindelijk aankwam.
Toen gebeurde er iets dat ik niet had verwacht: mijn teamleden stonden ineens aan mijn bureau met de vraag of ze konden helpen testen, zodat we de sprint nog zouden halen. Ik deelde ze wat testwerk uit en we haalden de sprint. Het niet mee testen door mijn teamleden bleek niet het probleem, maar een symptoom van het werkelijke probleem: ons gebrek aan controle over onze sprint. Toen dat was opgelost hadden we een gezamenlijke focus – onze sprint halen – en kwam het samen testen vanzelf!

Naast dat mijn team nu mee test als de deadline dringt, zijn er meer voordelen aan deze verandering: er wordt nu bijvoorbeeld tijdens refinements meer meegedacht over testaanpak en testbaarheid, en het schrijven van unittests heeft een impuls gekregen. Testwerk is beter overdraagbaar geworden en daardoor halen we meer deadlines. Gaandeweg kwam ik ook persoonlijke leerpunten tegen, zoals controle uit handen durven geven wanneer teamleden eindelijk mee willen testen. Bovendien ging ik door dit proces van een puur uitvoerende testrol naar een meer faciliterende rol: ‘van tester naar leader in test’.

Afsluitend nog een paar tips voor mensen die hun teamleden willen laten mee testen:

  • Zoek het werkelijke probleem – het niet samen testen kan ook een symptoom van het echte probleem zijn.
  • Zorg voor controle over je sprint – in ons geval was dat doorslaggevend.
  • Testengineer Welmoed Bruring vertelt in deze blog post hoe zij haar teamleden zo ver kreeg dat ze gingen mee testen. "Van tester naar 'leader in test'"

    Welmoed Bruring, testengineer bij Polteq

    Weeg af welke testwerkzaamheden je aan teamleden kunt uitbesteden en welke dingen je beter of sneller zelf kan doen in de tijd die je hebt.

Welmoed Bruring

Meer informatie

Heeft u een vraag of wilt u een vrijblijvende afspraak maken? Laat hieronder uw gegevens achter, dan nemen wij zo snel mogelijk contact met u op. U kunt ons natuurlijk ook bellen:

+31 (0) 33 277 35 22 (Nederland)
+32 (0) 16 39 48 04 (België)

Uw gegevens gebruiken wij alleen voor een correcte afhandeling van uw vraag. Lees voor meer informatie onze privacyverklaring.

Hoe wij dat doen?
Lees meer
Focus
Focus
Vakmanschap
Vakmanschap
Kennisdeling
Kennisdeling
Persoonlijk
Persoonlijk
Lokaal
Lokaal
Oprecht
Oprecht
Plezier
Plezier
Meer
Deze website is gerealiseerd door Webheads.

Neem contact op!