Dat komt in productie niet voor

Je hebt een requirement, je bouwt er een test voor, de test faalt en na de controle dat het niet aan de testdata etc ligt, voer je een bevinding op.

De bevinding wordt beoordeeld door de teamleider en van hem krijg je de reactie:

“Sluit die bevinding maar, want zoiets komt toch nooit in productie voor”.

Een tijdje later krijg je via de CC een mail van iemand die info vraagt over een soortgelijke situatie, met de vraag of ik die bevinding ook niet gemeld had en wat daarmee gedaan was. Het antwoord van diezelfde teamleider:

“Nee, dat was wat anders, dat betrof corrupte testdata, die bevinding is gesloten”.

Klinkt bekend?

Wat doe je?

 

In mijn geval is het tweeledig. Aan de ene kant lach ik erom. Lach ik om zoveel domheid.

Aan de andere kant moet ik er ook een beetje om huilen. Huilen om zoveel domheid.

 

Maar het geeft ook wel een dilemma aan waar je als tester mee zit. Je wordt aan de ene kant geacht iets te testen, maar je weet ook dat je alleen maar een rol hebt in het aangeven, en dat de leiding bepaalt wat er mee gebeurt. Maar ik weet inmiddels ook dat er slecht gelezen wordt en er al snel een conclusie getrokken wordt die in het straatje past van de beoordelaar. “We willen op tijd naar productie, rare bevinding, gekke data, zal wel corrupte data zijn, sluiten maar”.

Maar wat nou als de bevinding wel degelijk terecht is, wat als deze nou wel in productie voor zou kunnen komen en daar een hoop schade toe zou brengen?

Wat als je van tevoren wist dat je deze bevinding zou moeten sluiten met als argument dat het in productie niet voor zou kunnen komen, zou je de bevinding dan anders hebben gemeld?

We nemen een voorbeeld en maken deze wat concreter.

Er is een requirement dat het programma correct om moet gaan met lege data.

Ongeacht hoe dit in productie bereikt zou kunnen worden, neem je testdata en maakt de vulling daarvan leeg. Bijvoorbeeld naw-gegevens. Vervolgens doe je een aantal testgevallen waarbij je constateert dat er fouten optreden. Bij klantlijsten bijvoorbeeld of bij tellingen.

Je testgeval klopt, je data klopt, je voert een bevinding op.

En je wordt gevraagd deze te sluiten omdat dit toch nooit voorkomt.

 

Het is een maand later, we zijn bezig met een nieuwe sprint. De nieuwe wens is om naw gegevens te anonimiseren na verloop van tijd. En met anonimiseren bedoelen we in dit geval simpelweg het wissen van de naw-gegevens en de overige gegevens behouden.

Je voert een test uit en het werkt correct. Recente klantgegevens worden netjes bewaard en precies op het juiste moment wordt de oudere klantdata gewist. Test geslaagd, product OK.

Of toch niet?

Als het goed is, zou je ook nog een stuk regressietest doen (maar in de praktijk wil dat er natuurlijk nog wel eens bij inschieten) en je draait ook nog even de rapportage.

Hé, dat is gek, dezelfde foutmelding als die ene die we een maand geleden ook hadden. Die fout die optrad omdat de naw-gegevens leeg waren, die zogenaamde corrupte data, waarmee je toen al aan kon tonen dat het programma niet deed wat de requirement juist vroeg.

Als iemand zegt “Dat komt in productie toch nooit voor”, ga er dan maar vanuit dat het eerder voorkomt dat je denkt.

 

(Dit verhaal is op 19 juli 2015 door Fred Steenbergen geschreven, op 2 april 2018 is het geplaatst op Zeepkistje)