Testen in een team in overlevingsstand

Stel je voor, je bent tester. Je wilt kwaliteit. Maar als je bugs ontdekt, krijg je ze niet opgelost. En dan hebben we het niet over een spelfout in een stukje tekst. Nee, we hebben het over critical bugs. En als je pech hebt zelfs blocking bugs. Hoe dat komt: je development of scrum team is in overlevingsstand.

Hoe herken je een overlegevingsstand?

Bugs horen als basis geprioriteerd te worden op de ernst: is een bug blocking, critical, major of minor. En deze prioritering hoort gedaan te worden door onpartijdige personen binnen de organisatie. Natuurlijk zijn er uitzonderingen, bijvoorbeeld een belangrijke deadline, maar deze uitzonderingen komen slechts zelden voor. En ook deze uitzonderingen worden bewaakt door onpartijdige personen in de organisatie.

Dus herken je aan het omgekeerde de overlevingsstand. Er wordt zeer regelmatig gewerkt aan minor bugs, terwijl je weet, dat er critical bugs nog op de lijst staan. De persoon, die de prioriteiten bepaalt, mag of wil dit niet onpartijdig doen, maar kiest de kant van de manager, de klant, het project, enz. En beide situaties zijn dus geen uitzonderingen. Nee, het is standaard. Het is soms zelfs helemaal ingeprogrammeerd in de hersens van het team en/of van andere betrokkenen. Hierop wijzen wordt misschien zelfs gezien als iets raars of ongewenst.

Hoe ontstaat een overlevingsstand?

Het volgende lijstje is gebaseerd op mijn ervaringen. Mogelijk zijn er meer oorzaken, maar dit is wat ik in al mijn jaren testervaring ben tegengekomen. En vaak is het een combinatie van meerdere factoren.

Ernstige ondercapaciteit
Het team is niet groot genoeg om de werkvoorraad goed bij te houden. Nu gebeurt het al snel, dat een team meer werk krijgt, dan het aankan. Maar dan is er nog niet altijd sprake van ernstige ondercapaciteit. Ernstige ondercapaciteit merk je aan de "creatie-datum" van het werk dat opgepakt wordt. En de "creatie-datum" is de datum waarop de bug of wens voor een wijziging voor het eerst in de organisatie is gemeld. Als je team meer dan 75% werkt aan bugs of wijzigingen, die minder dan een maand oud zijn, dan is er sprake van ernstige ondercapaciteit. Je werkt te vaak aan nieuwe zaken en kan daardoor niet goed structureel andere problemen oppakken.


Druk
De prioritering of hoeveelheid te besteden tijd wordt niet bepaalt door kwaliteit of kans op falen, maar door een deadline, een manager, een klant, een afdeling, een collega, enz. Deze kwam je al tegen bij de beschrijving van de overlevingsstand. Dat komt, omdat dit een van de meest eenvoudige is om te herkennen. En deze is bijna altijd van toepassing, als een team in overlevingsstand is. De bugs worden voornamelijk geprioriteerd op grootte van klant, deadline van het project, afwijken van een standaard, enz. Het grote gevaar is, dat dit vaak niet raar wordt gevonden. Want moet je met die zaken dan geen rekening houden? Natuurlijk wel. Het verschil is tussen reactief en preventief bugs oplossen. Bij reactief oplossen gebeurt het oplossen van bugs grotendeels in opdracht van iemand, die eigenlijk qua functie niet verantwoordelijk is voor de prioritering. Je bent dan meestal mensen tevreden aan het stellen of crisissen aan het bezweren. Bij preventief bugs oplossen, los je bugs op op basis van de prioriteit, zoals bepaalt door de persoon of personen, die in zijn functie heeft staan "Bepaal de prioriteiten van het op te pakken werk". En deze persoon maakt  of deze personen maken wel gebruik van anderen, maar is of zijn vrij om de mening van ieder ander naast zich neer te leggen. En ze doen dat ook. Als je vraagt: "Waarom pakken we dit op", is het antwoord dan ook bijna nooit "Omdat X dit wil". Dit geeft rust en geeft daarnaast ook weer de tijd om goed structureel andere problemen op te pakken.

Kennisgebrek
Men wil wel, maar men kan niet. De kennis van de applicatie is zo weinig geworden, dat bugs fixen of wijzigingen inbouwen ongeveer gelijk is aan schieten in het donker. Het is duimen, dat er niets vergeten wordt of er geen nieuwe bugs ontstaan. Dit is de meest ingewikkelde om te herkennen, want niemand kent de hele applicatie uit zijn hoofd. Maar ikzelf herken hem aan het aantal keren waarop de code het antwoord moet geven op functionele vragen. Natuurlijk, als ik een heel gedetailleerdere vraag stel: "Wat gebeurt er als ik eerst X doe, dan Y en dan Z?", verwacht ik niet dat iemand direct het antwoord weet. Maar als ik vraag "Op hoeveel plaatsen kunnen we een klant invoeren?" of "Hier werkt het op manier A en daar op manier B, wat is correct?", zou het antwoord meestal eenvoudig te geven moeten zijn. En zeker geen uur code analyse moeten vragen. Helemaal duidelijk wordt het, als mensen je vragen verkeerd beantwoorden en ze het zelf niet doorhebben. Natuurlijk, beide situaties kunnen een keer gebeuren, maar als dit (bijna) de standaard is, wordt bijna elke bouwklus aan je applicatie gevaarlijk. En kan daardoor leiden tot ondercapaciteit, doordat bij bouwklussen te regelmatig nieuw werk ontstaat. Of het leidt tot druk, omdat anderen de problemen van het bouwresultaat moeten ontdekken.

Hoe ga je er als tester mee om?

Het allerbelangrijkste advies aan testers bij een team in overlevingsstand? Ga zelf niet in overlevingsstand. Natuurlijk, je werkt wordt erdoor beïnvloedt. Je kan niet genoeg testen, de bugs, die je vindt, worden niet voldoende opgelost of je hebt te weinig informatie voor een betrouwbare test. Maar blijf zelf in ieder geval goed prioriteren. En het belangrijkste advies: prioriteer zelf! Prioriteer zelf je testwerk: wat moet het eerst getest worden, wat het tweede, wat het derde. En bepaal ook van deze taken het testbelang: welke testtaken zijn must haves, omdat ze blocking bugs voorkomen en welke zijn would haves, omdat ze trivial bugs voorkomen. Prioriteer ook zelf de bugs: welke zijn critical, welke major, enz. Leg die prioriteiten vast en leg ze zo vast, dat je ze later terug kan vinden.

En als laatste: gebruik deze prioriteiten om feedback te geven op de situatie. Geef deze feedback minimaal aan je manager en aan je team. En blijf deze feedback geven, ook als het geen effect heeft. Blijf melden, als je belangrijke testtaken niet uitgevoerd krijgt of als ernstige bugs niet opgelost worden. Maar (en dit geldt niet altijd, maar wel bij een team in overlevingsstand) meldt niets als je al je must have taken hebt kunnen uitvoeren en je alle bugs hoger dan major zijn opgelost. Dit laatste is om over te komen als iemand, die zich inzet voor belangrijke zaken. En niet als iemand, die altijd wel iets te klagen heeft. Juist in een team in overlevingsstand is hoe je overkomt heel belangrijk. Je omgeving moet begrijpen waar je voor staat. En bij voorkeur hier respect voor hebben, ook als ze je mening niet delen. Serieus genomen worden is je enige kans op verbetering.