Cris Konert is Test Engineer, Scrum Master, maar vooral een veelzijdig doen-wat-gedaan-moet-worden persoon. Door zijn open houding en filosofische mentaliteit heeft hij door de jaren veel gesprekken met collega’s gehad over waarom ze doen wat ze doen en zijn zoals ze zijn. Hij durft ongebruikelijke vragen te stellen en ook ongebruikelijke meningen te geven. Ondanks dat, of juist daardoor heeft hij een onuitputtelijk vertrouwen in de Goede Afloop.
Ook heeft hij gezien dat mensen altijd continu aan het veranderen en ontwikkelen zijn. Of ze willen of niet. Dit constante proces vindt Cris het meest interessante wat er is. Hij vindt het geweldig als mensen hun perspectief en bewustzijn blijven verbreden.

Testautomatisering, maar ook handmatig testen, is niet een zoektocht naar de perfecte test. In de poging wel die perfectie te vinden heb ik vaak gezien dat dit ten koste gaat van de dekking en kwaliteit. Op welk punt mag je beseffen dat de testgevallen die je aan het ontwikkelen bent “goed genoeg” zijn om je doelstellingen te halen?
Je wilt voorkomen dat je ongewild je sprintdoelen blokkeert omdat je de testen perfect probeert te krijgen. Je wilt voorkomen dat je vast komt te zitten in je eigen gedachten of werk terwijl je team je verder zou kunnen helpen.
Wat zijn dan zinvolle gedachten- en gedragspatronen om je als Test Engineer in een Scrumteam het juiste binnen de gestelde tijd te laten opleveren? Welke vragen moet een tester zichzelf stellen om van “kijken of ‘ie het doet” naar “de juiste dingen doen” te gaan?

Binnen een Devops/Agile wereld waarin Testers en Bouwers nauw samenwerken, en de Tester zelfs een soort Bouwer is geworden, moet je aan het eind van de sprint een werkend (deel-)product hebben. Er moet dus opgeleverd worden. En dat is niet alleen een stuk werkend programmatuur, maar ook een stuk kwaliteitscontrole op die software. Met andere woorden, afgeronde testen.

Als Tester wil je tegenwoordig alles automatiseren. Om allerlei verschillende redenen kan je soms beslissen dit niet te doen. Tijd, geen noodzaak tot herhaalbaarheid, gebrek aan kennis en kunde op het gebied van automatisering, afwezigheid van een CD pipeline, noem maar op.

Als je heel eerlijk naar jezelf kijkt en gewetensvol antwoord geeft, kan het zelfs zo zijn dat je te eigenwijs bent om toe te geven dat je testautomatisering heel lastig vindt. Of nog erger, je bent zo perfectionistisch dat je jezelf zoveel werk op de hals haalt dat de testen veel meer doen dan eigenlijk nodig is.

Door die bomen zie je het bos niet meer. Je bent zo aan het automatiseren dat je je testontwerptechnieken vergeet. Je probeert het tempo van de bouwers bij te houden en test het minimaal nodige, waar de kwaliteit van de testen onder te lijden hebben. Perfect krijg je het ook niet, want dat kost te veel tijd.

Je bent als het ware gevangen tussen twee uiterste doelstellingen. Enerzijds het werk afkrijgen, anderzijds het werk goed krijgen.

Door bepaalde gedachtepatronen bij jezelf te herkennen weet je waarom je kiest voor tijd of kwaliteit. En het herkennen van die patronen kan je helpen die afweging beter te maken.
Als je door het stellen van andere vragen aan jezelf tot een meer effectieve manier van testen kunt komen, waarbij je kwaliteit niet persé hoeft in te leveren omwille van tijd, kan je als team een beter product opleveren.
Deze verhoging van effectiviteit eist een verschuiving in je persoonlijke paradigma.

In deze presentatie worden voorbeelden van beperkende patronen gegeven en worden alternatieve patronen aangereikt aan om je doelgerichter te laten testen.