De terugkeer van de onafhankelijke tester

dinsdag 8 februari 2022

Door Egbert Bouman

De digitale wereld heeft onafhankelijke testers en keurmeesters nodig met een constructief kritische blik. Tegelijkertijd willen die testers ook prettig samenwerken met hun team. Dat blijkt een lastige psychologische spagaat te zijn. Hoe bevecht je als tester je onafhankelijkheid zonder ongezellig te worden?

Uitgestorven?

Onafhankelijke testers, dat is waar ook, die had je vroeger! Ooit was het een tamelijk dominante soort, maar de impact op het softwareklimaat van de grote agile meteoriet, nu al weer 20 jaar geleden, heeft de onafhankelijke tester de das omgedaan. Nieuwe soorten dienden zich aan: éénpotigen (T-shaped), tweepotigen (Pi-shaped), driepotigen (W- shaped) en veelpotigen (Comb-shaped). En niet te vergeten de geleedpotige testers uiteraard, die met hun flexibiliteit onopvallend in elk gaatje passen, nooit iets blokkeren en niemand in de weg zitten.

Sorry hoor, de would-be bioloog in mij wilde even vrij zwemmen en chargeren. Tijd nu voor een serieuzere toon.

In het agile klimaat werk je in multidisciplinaire teams en daarmee is teamspirit en gezellig omgaan met je teamleden een belangrijk ding. Als tester wil je niet de strenge boeman en zeker niet de gebeten hond zijn. Dus je buigt mee, je doet niet moeilijk, je spreekt de taal en je leert de ‘kunstjes’ van het team. En ook jij omarmt dat ene grote doel: ‘werkende software, gereed om uit te rollen’. Fijn, iedereen blij! Maar …

Group think floreert

Agile teams functioneren net als elke groep mensen. Hoe hechter de groep, hoe beter de samenwerking en hoe productiever het team. En dat is goed.

Maar ‘elk voordeel hep z’n nadeel’. In dit geval: group think en collectieve blinde vlekken. Met een grotere kans dat risico’s niet worden gezien of verkeerd ingeschat. Dat is gewoon een natuurwet. Wie daar een mooi voorbeeld van wil zien moet het fantastische teamwerk op deze USS Montana video maar eens bekijken.

Dwarsdenkers en keurmeesters

Goede developers staan voor hun kwaliteit, het zijn slagers die eigen vlees keuren en daar is niks mis mee. Goede developers zijn ook prima in staat om door de bril van de klant te kijken. Echter, als het software-technisch uitdagend wordt, is het nog niet zo eenvoudig om dat perspectief goed vast te houden. En zo ontstaan de mismatches tussen wat de klant nodig heeft en wat de developer oplevert. Dat is geen diskwalificatie, het is heel menselijk en heel normaal.

Wat heb je dus nodig? Professionele dwarsdenkers! Geen muggenzifters, spijkers-op-laag-water zoekers en querulanten natuurlijk, maar positief-kritische keurmeesters.

Zo iemand kijkt van buiten naar binnen. Niet vanuit de techniek en ook niet alleen vanuit de user stories. En zelfs niet via soms blikvernauwende tools voor geautomatiseerd testen, hoe goed en onmisbaar die ook zijn. De onafhankelijk tester kijkt vanuit het proces, de klantreis, de gebruikerservaring, de burger en zijn/haar concrete behoefte.

So far, so good, zul je denken, ieder zijn rol, gewoon doen, wat is het probleem? Lees vooral verder!

De praktijk…

Een collega, laat ik niet zijn echte naam gebruiken maar hem Kees noemen, deelde het volgende met me, in tranen: “Ik zit helemaal stuk want mijn team pruimt me niet. Ik roep vaak ‘dit lijkt op een bug’, ‘misschien is het geen bug, maar het is wel een probleem’, ‘handig, maar niet veilig’, ‘dat gaan de gebruikers niet doen of niet snappen’, ‘wat doet dit met de performance? ’, ‘ik mis een brede risicoanalyse’, ‘ik heb geen testdata en not tested is not done’, ‘wat als…’. Dat soort dingen. Maar vaak word ik genegeerd of krijg een veel te technisch antwoord. Ze vinden me vervelend, ik hou de boel op.”

“Ik twijfel steeds vaker en om het voor mezelf een beetje gezellig te houden hou ik steeds meer mijn mond. Maar de laatste release is goed mis gegaan. Door een bug die er door is geslipt zijn er foute uitbetalingen gedaan. Dat heeft ontzettend veel geld en gedoe gekost en iedereen rolt over ons heen. En vooral over mij, als tester krijg ik de schuld”.

Kees: “Het moest een keer gebeuren, want we kunnen in de test- en acceptatieomgeving de koppeling met de betaalsystemen niet testen. Dat heb ik verschillende keren aangekaart, maar het was allemaal te moeilijk en het zou allemaal wel meevallen. Maar nu hoor ik ze niet en ben ik op het matje geroepen door de programmamanager: ik had dit als tester moeten voorkomen, ze vindt dat ik heb zitten slapen. En ze heeft nog gelijk ook, ik voel me een watje.”

Psychologische spagaat

Ik zeg niet dat elke tester en elk agile team bovenstaande ervaring deelt. Maar ik hoor het wel te vaak: de tester als kop van jut in een onmogelijke spagaat. Enerzijds elke dag (virtueel) gezellig samenwerken en een loyale teamplayer zijn. Anderzijds de vervelende ‘wat als’ vragen moeten stellen. Tegen de stroom in roeiend en ook nog eens als brenger van het slechte nieuws: “Beste collega en trotse software ontwikkelaar, jouw kindje is niet zo gezond als je misschien dacht, ik heb deze drie lelijke bugs gevonden”.

"It’s psychology, stupid!"

Ja, sociaal handige testers die dit allemaal met gemak combineren bestaan gelukkig. Kritisch, deskundig, handig, verbaal sterk, streng doch rechtvaardig en ook nog gewaardeerd en populair. Dat zijn de vijfpoters en ze zijn hun gewicht in goud waard. Maar de meesten passen zich in meer of mindere mate aan en worden ‘gewoon’ gezellige teamleden. Exit onafhankelijk testen!

Wie denkt ‘in mijn team gaat dat gelukkig niet zo’ moet in de volgende retro maar eens aan de testers vragen of ze zich nog én onafhankelijk én volledig geaccepteerd teamlid voelen, met dezelfde status als de developers en de analisten. Misschien komt er een verrassend antwoord…

Refactoring van de communicatie

Als het goed is heeft de scrummaster een scherp oog voor dit soort zaken. Hij of zij zorgt dat in de retrospective dingen gezegd kunnen worden als “ik heb de afgelopen sprint overleefd, maar heb me heel eenzaam gevoeld”, of “we roepen wel dat kwaliteit van het hele team is, maar als er een issue is ben ik altijd de gebeten hond”, of “ik voel me niet vrij om Kemdem style een bug te melden als ik niet 100% zeker van mijn zaak ben”.

Zeker nu we allemaal op afstand werken en we elkaar niet even in de ogen kunnen is de communicatie een aandachtspunt. Stroefheid, een gevoel van onveiligheid en minder openheid liggen op de loer. Een goede ‘People-Process-Tools’ scrum master creëert een open sfeer waarin dat besproken kan worden, ook al zijn het ‘slechts’ buikgevoelens.

Want soms heeft niet alleen de software refactoring nodig, maar ook de communicatie en de samenwerking. Zodat ook het kritische en onafhankelijke geluid van de tester tot zijn recht komt. In een sfeer waarin iedereen er mag zijn. Scrum masters die in staat zijn om zo’n open sfeer te creëren zou je onze ‘magerzijnbeheerders’ kunnen noemen en ik zie ze graag. Dat klinkt soft, maar betaalt zich uit in minder uitval en betere teamprestaties. En in het geval van testen: in meer kwaliteit en minder bugs en problemen na livegang.

Niet terug naar eilanddenken

Moeten testers terug op een eiland? Nee, natuurlijk niet, het is winst dat ze daar vanaf zijn. Daar heb ik afgelopen jaren, met veel anderen bij Valori, stevig aan bijgedragen door dingen te roepen als:

  • Built in Quality: kwaliteit kun je er niet achteraf in testen maar zit in je totale proces
  • Kwaliteit is van het hele team, Kemdem! (zie m’n eerdere blog hierover)
  • Goede testers zijn ‘full-stack’ en ‘T-shaped’ en spreken de taal van de developers

Dus, tester, ga niet op afstand onafhankelijk zitten wezen, maar ‘join the team’ en doe mee met ‘failing forward’. Samen kom je verder!

Dat besef, dat je het samen moet doen en elkaars taal moet spreken is nog steeds relevant, laat dit vooral niet los. Maar zorg dat je niet doorschiet en breng het onmisbare stuk onafhankelijkheid terug dat misschien verloren is gegaan.

Hoe dan?

Ik denk dat iedereen die zich van het bovenstaande bewust is naar eigen inzicht en bevind van zaken actie kan nemen en de valkuilen kan vermijden. Ter inspiratie en ter afsluiting toch tien praktische tips:

  1. Vertel als opdrachtgever of scrum master de testers in je team dat je van ze verwácht dat ze dwarsdenkers en ‘advocaat van de duivel’ zijn en dat je achter ze staat.
  2. Vertel ze ook dat je realiteitszin verwacht: samen in de duivelsdriehoek Tijd-Geld-Kwaliteit. En ja, dat is altijd zoeken en balanceren, waarbij de tester best iets meer op Kwaliteit mag drukken.
  3. Kies als tester een thuisfront waar ‘testers onder elkaar’ over dit soort uitdagingen kunnen spreken. Werken bij een organisatie met testen als specialisme helpt enorm. Ik ben persoonlijk ontzettend blij met het Valori thuisfront waar hiervoor alle ruimte is.
  4. Zit je aan de inhuur/demand/klant/opdrachtgever kant, zorg dan voor testers die zo’n professionele organisatie achter zich hebben.
  5. Zorg dat developers blijven inzien dat hún kindje gebaat is bij een onafhankelijk blik, het wordt er alleen maar beter van. En natuurlijk slaat een tester de plank ook wel eens mis.
  6. Neem goed (regressie)testen en de input van de testers vanaf het begin mee in je sprintplanning en je story points.
  7. Automatiseer je regressietestset, dat maakt tijd vrij voor creatief, out-of-the box, critical thinking for testers (met dank aan James Bach en Michael Bolton).
  8. Creëer een open sfeer, in en buiten de retro’s, nodig iedereen uit om ook buikgevoelens uit te spreken, ook als je het (nog) niet hard kunt maken.
  9. Laat je niet wijsmaken dat dit alles niet opgaat bij Standaardpakketten, Low Code, No Code, etc. De principes zijn precies hetzelfde. Lees b.v. onze blogserie Gaining Speed Yet Losing Altitude over kwaliteit in Low Code.
  10. Optimaliseer het volledige DevOps proces, testen is geen eiland.

Meer weten over de balans tussen conformerend en niet-conformerend gedrag? Google eens op Idiosyncrasy credit (met dank aan dochter en student psychologie Aleid Bouman).

"Succes en happy testing!"