Geloof me nou maar, het werkt!

Een gemiddelde dag op het werk.

“Ja, maar hoeveel heb je nu gedekt dan?”. Het is weer zo’n dag, zo’n dag waarop we het over testdekking hebben. De afgelopen jaren is er flink gebouwd aan de applicatie en is het aantal automatische tests flink toegenomen. Omdat we nu op het punt komen dat we steeds sneller naar productie willen kunnen (nu 1 keer per twee weken, maar doel is Continuous), krijgen we echter ook steeds vaker de vraag waarom we zoveel tests hebben, want die duren (te) lang. Bovendien zien sommigen dat we bij nieuwe features ook nieuwe tests maken en krijgen we opmerkingen als ‘…geen tests meer bijschrijven, … is 2500 tests niet genoeg?’.

En daarmee begint de discussie.

Wanneer heb je genoeg tests? Is er een maximum aan het aantal tests dat je mag hebben?

Wat mij betreft, als tester, is het nooit genoeg. En daarmee bedoel ik natuurlijk niet dat je elke mogelijke postcode moet proberen in te voeren bij een postcode-invoerveld, of elk mogelijk huisnummer bij een huisnummerveld, maar je zou wel 100% dekking na moeten streven bij de door jou gekozen testtechniek. Bij equivalentie zou dat een klein aantal testgevallen kunnen zijn (maar daarmee wel 100% dekking bij die techniek), bij grenswaarden zou dat al meer zijn (maar wederom 100% dekking bij die techniek) en zo verder. En welke techniek je kiest, is dan uiteraard weer afhankelijk van het risico.

De gedachte dat ‘het te lang duurt en dus tests weg moeten’, is wat mij betreft een enge gedachte. Tijd is blijkbaar een issue en dan moet je daar naar kijken en kijken wat de opties daarbij zijn. Dat kan uiteraard het verminderen van het aantal tests zijn, maar er zijn nog veel meer opties. Zitten er bijvoorbeeld zogenaamde sleeps in, momenten waarbij een aantal seconden gewacht wordt om zeker te zijn dat iets gebeurt is voordat ergens op gecontroleerd wordt? Een of meer seconden lijkt niet zo erg, maar als dit stuk door meerdere tests aangeroepen wordt, zit je zo aan een minuutje extra, of meer. Of zitten er bijvoorbeeld controlepunten in om te controleren dat er iets juist niet op het scherm staat, en blijft deze test bijvoorbeeld 20 seconden wachten om zeker te weten dat er écht niets op het scherm komt te staan wat er niet hoort? Dat tikt dan zeker flink aan. Maar als tijd een issue is, moet je dan wel alleen kijken naar de testuitvoertijd? Wat is de totale tijd? Hoeveel tijd kost het bouwen van de applicatie? Deployen naar een testomgeving? Testdata goed zetten? Maken van rapportages? Kan daar ook geen winst gehaald worden?

Maar goed, de oplossing zou dus liggen in het weggooien van tests. Welke tests ga je dan weggooien?

“Edge-cases!”, wordt al snel geroepen. Maar wat is een edge-case? 90% van de bezoekers volgt pad A, 10% pad B. Is dat laatste dan een edge-case? Of is dat het, als maximaal 5% van de klanten het raakt, of misschien maximaal 0,5%? Maar ook bij 0,5% van de klanten hebben we het in ons geval nog steeds over 5000 klanten. Da’s toch nog steeds een aanzienlijk aantal. En vinden we het inderdaad niet erg als juist bij die klanten iets mis zou gaan?

De discussie verplaatst zich en gaat verder over dekking. We hebben veel te veel tests, waarbij ik met zekerheid kan zeggen dat we er ook te weinig hebben. Kijk alleen al naar de productieissues die tijdens een sprint op de emergency-lane op het scrumbord komen te hangen en die met hotfixes dwars door de reguliere release heen moeten worden opgelost. Blijkbaar hebben we een heel belangrijk punt gemist met onze test. En met ‘onze’ test bedoel ik dan alles tests bij elkaar, van unittest tot end-to-end-test, in elke laag van de testpiramide dus. Nergens heeft blijkbaar een test gezeten die deze fout heeft geconstateerd. Hoe gaan we daar mee om in de ideale situatie? We bouwen een test waaruit blijkt dat de fout inderdaad optreedt, we repareren de code, draaien de test nogmaals en zien nu dat de situatie goed gaat. De test komt in de regressieset te zitten en draait voortaan mee. Er is dus een test bijgekomen die we eerst niet hadden. En zo hoort het, wat mij betreft.
Op de opmerking ‘We hebben teveel tests’, reageer ik dan ook steevast met een ‘maar we hebben er ook te weinig’. Waarom hadden we die ene specifieke test, die we nu dus bewust wel maken, toen nog niet?

Sommigen zijn zelfs van mening om de test, als hij eenmaal slaagt, weg te gooien. Je hebt het op dat moment getest, het gaat goed, wat is de kans dat het ooit niet meer goed gaat? Dus weggooien, scheelt weer een test, tijdwinst dus. Trek die gedachte door, waarom gooien we dan niet gewoon alle tests weg die ook succesvol gedraaid hebben?

En het ene punt is nog niet besproken of het volgende punt komt langs. Een opdracht om over na te denken en volgende week het antwoord op te geven: “Hoe kan je ervoor zorgen dat je weer vertrouwen krijgt in de developers?”.

Uhm, pardon?

De opdracht is niet naar mij persoonlijk, maar naar het hele team, maar aan de reacties te horen, voelen sommige anderen precies hetzelfde. Is er dan geen vertrouwen? Die gedachte leeft blijkbaar onder sommigen en daar moeten wij wat aan gaan doen.

Ik herken me er niet in en kan er dan ook niets mee. Ja ‘tuurlijk weet ik wel een paar dingen om vertrouwen te kweken. Leer elkaar kennen, ken de persoon achter de naam, ‘als je me echt kende, dan wist je dat…’, deel zaken etc, maar goed, zoals gezegd, wat vertrouwen betreft zit het volgens mij wel goed.

Maar als ik toch nadenk over vertrouwen, dan denk ik ook ook aan andere zaken. Is het feit dat we testen niet het duidelijkste moment dat we het (ze?) juist niet vertrouwen?  Als een developer tegen je zegt, ‘dit hoef je niet te testen, geloof me nou maar, dat zit wel goed’, wat doe je dan, of wat denk je dan? Ga je dan juist testen? Of inderdaad juist niet? Of test je wel, maar niet door die opmerking, maar omdat je altijd test? Of kan je er vanuit gaan dat de developer ook goed getest heeft als hij dat zegt? Wil je dat bewezen zien, of accepteer je het blind?

Het zijn zo maar wat vragen die op een willekeurige dag aan de orde komen. Ik zeg het wel vaker, en geloof me nou maar, het testvak is een mooi vak!