Lessons Learned in Software Testing, les 210, Mediocrity is a self-fulfilling prophecy

Lessons learned in Software Testing, toen en nu

 

Het is een boek wat veel testers wel zullen kennen.

Voor degenen die het niet kennen, het is een boek uit het begin van deze eeuw waarin Cem Kaner, James Bach en Bret Pettichord zo’n 300 ‘lessons learned’ beschrijven en waarbij aangeraden wordt zo nu en dan gewoon eens een les eruit te lezen en hieraan te denken in je werk.

Inmiddels zijn we bijna 15 jaar verder en gelukkig leren we veel vanuit het verleden dus leek het mij wel grappig om eens een paar lessen hieruit te beschrijven. Eens stil te staan bij datgene wat toen blijkbaar een Lesson Learned was. Zeker voor de nieuwen in het vakgebied zullen het waarschijnlijk verhalen zijn waar je je niets meer bij voor kan stellen maar wat toen echt een issue was.

Misschien wel een beetje als mijn nichtje die geen idee heeft wat ze ziet als ik haar een casettebandje laat zien.

 

We slaan het boek open op een willekeurige pagina. We komen uit bij bladzijde 189 waarop les 210 staat “Mediocrity is a self-fulfilling prophecy”.

Mediocrity (middelmatigheid) is iets wat je vanzelf realiseert als:

  • Je alle creativiteit laat verdwijnen door het hele menselijke aspect uit al je processen te halen
  • Het je doel is om van elk teamlid een vervangbaar radertje te maken
  • Je het werk van je medewerkers zo standaardiseert dat iedereen kan doen wat zij kunnen, op dezelfde manier als zij;
  • Je je team beoordeelt zonder te letten op hun creativiteit, overtuigingskracht, oordeel, of gevoeligheid
  • Je je team vervreemd van het resultaat van hun werk, als je ze vertelt dat het hun doel is om bevindingen te rapporteren, en dat iemand anders zal bepalen of het wel of niet opgepakt zal worden, zonder hun verdere input, zonder dat ze hun bevindingen verder kunnen toelichten

 

Als dit je werkwijze is, verwacht dan ook niet dat

  • ze zich laten zien als het project ze nodig heeft, (verkeerde vertaling)
  • ze zich uitspreken op principekwesties,
  • ze lange dagen gaan maken op de momenten dat het project het nodig heeft
  • ze briljante tests ontwerpen voor de moeilijke maar o zo kritieke bugs
  • ze zich vastbijten om het de manager net zo lang uit te leggen totdat hij dat belangrijke probleem snapt
  • ze zich loyaal tonen naar jou, of het bedrijf, op het moment dat je dat juist zo hard nodig hebt.

 

Als je verkondigt dat er geen helden in je bedrijf zullen zijn, dan krijg je er ook geen.

 

Let wel, dit was een les die opgeschreven werd kort na de eeuwwisseling, jaren geleden. De tijden zijn veranderd.

Toch?

 

Laat ik even naar mezelf kijken, ik kan opdrachten in gedachten oproepen waarin we de hele week werkten en dan op vrijdagmiddag doorgingen voor de daadwerkelijk implementatie van het eindproduct. De eindsprint, de zogenaamde kers op de taart. Vrijdag werd het erg laat, maar zaterdagochtend stonden we er weer. Om door te gaan tot laat in de avond, of moet ik zeggen nacht. De zondag hetzelfde verhaal. De maandag erop, toen iedereen vrij was vanwege een feestdag was voor ons een dag voor noodgevallen. En die bleken we hard nodig te hebben. Maar die maandagochtend stond iedereen er weer en werkten we de hele dag door. Dat deden we voor elkaar, voor de opdrachtgevers, voor het bedrijf. We geloofden erin, we stonden voor ons werk, er werd in ons geloofd en wij geloofden erin. We waren een team. Het lange weekend werd uiteindelijk met succes afgesloten.

 

Maar ik ken ook de andere kant. Te horen krijgen dat je niet weet wat je doet, dat je niet kan testen. Niet omdat je daar de skills niet voor hebt, maar gewoon, omdat je de domeinkennis niet zou hebben en dit ook niet moet hebben omdat je dan niet meer objectief zou zijn. Dat waar je voor leeft, testen, wordt onderuit gehaald tot een ‘kijk maar of je rare dingen ziet en leg die constateringen maar voor aan de business’. Bevindingen die je opvoert omdat je (na een paar jaar heb je uiteraard wel degelijk domeinkennis) weet waar iets niet klopt, blijken later, zonder terug te koppelen, gesloten zijn omdat ‘het inderdaad niet correct functioneert, maar voor nu geen probleem is in productie’ of ‘de bevinding is een duplicaat van bevinding-xxx’, terwijl je, als je die andere bevinding erbij pakt constateert dat dit een heel andere bevinding is. De bevinding is echter gesloten, input niet gewenst en terugkoppeling blijkbaar niet nodig.

De medewerker wordt, al dan niet bewust, gemaakt tot een uitwisselbaar radertje.

 

Er kan nog zoveel geleerd worden van Les 210.

 

(Dit verhaal is op 15 oktober 2013 door Fred Steenbergen geschreven, op 2 april 2018 is het geplaatst op Zeepkistje)