De stagnatie van innovatie

Ik ben al oud en heb de jaren 90 nog meegemaakt als tester. In die tijden deden we vreemde dingen: zo was ik onderdeel van een testcentrum dat als doel had om voor iedere ontwikkelaar tenminste één tester in het project te hebben. Dat kon ook bijna niet anders, want we waren enorm druk met het schrijven van mastertestplannen, detailtestplannen, het herschrijven van specificaties tot honderden logische en fysieke testgevallen (en die steeds aanpassen), het schrijven van bugrapporten (inclusief overleggen en de verslagen daarvan), het schrijven van rapportages over het aantal bugs, het aantal testcases, het dekkingspercentage,  etc.. Ook hadden we nog zaken als TMMi (Test Maturity Model integration) om te laten bevestigen dat we toch echt nog meer mensen nodig hadden. Gestructureerd testen was een mooie innovatie die ook mooi aansloot bij de noden van dat moment.

Inmiddels heeft er sinds de komst van agile een enorme verandering plaatsgevonden in softwareontwikkeling en daarmee ook in het testvak. Zo zijn er diverse bedrijven die hebben bepaald dat er helemaal geen testers meer nodig zijn. De testen kunnen immers worden geautomatiseerd en dat kunnen ontwikkelaars er gewoon bijdoen. Die zijn daar tenslotte veel beter in. Of in de nabije toekomst: middels Artificial Intelligence(AI) moet het binnenkort toch niet super ingewikkeld meer zijn om een mooie set aan checks te laten bedenken, coderen en uitvoeren.

Deze denkwijze dat testers niet meer nodig zijn kan ik wel volgen: wat testers deden pre-agile was vooral het bedenken en uitvoeren van checks op basis van documentatie. Dat kun je nu al voor 95% automatiseren en in de toekomst met AI wellicht nog wel meer, en vast ook sneller en beter.

Toch zien we ook dat veel bedrijven zijn teruggekomen op de beslissing om geen testers meer in dienst te hebben. Deze bedrijven hebben gemerkt dat ondanks een hoge mate van testautomatisering (door ontwikkelaars) de producten toch vol met onontdekte fouten zit en dat deze nu vooral door klanten worden ontdekt. Dat brengt schade toe aan het bedrijf zelf en aan het imago van het bedrijf. De kritische blik, het stellen van de juiste vragen en het onderzoeken van de software blijkt bij nader inzien toch een kwaliteit te zijn die meestal niet kan worden belegd bij andere teamleden. De andere teamleden bezitten ofwel deze kwaliteiten niet of hebben te veel andere verantwoordelijkheden om dit er even bij te doen.

Daarnaast zien we ook dat testers enorm worstelen hoe ze dan in de nieuwe wereld de meest zinvolle bijdrage kunnen leveren aan de kwaliteit van de producten, teams en processen.

Dit brengt ons tot de uitdaging uit de titel: we moeten meer innoveren om als testers toegevoegde waarde te blijven leveren in de nieuwe wereld. Onze testmethodes moeten feilloos aansluiten bij de moderne methoden van softwareontwikkeling. Toch lijkt het vaak dat we ons nog krampachtig vasthouden aan de jaren 90. De oorsprong van die verkramping is daar ook te vinden: de tijd waarin IT-ers en ook specifiek testers niet aan te slepen waren (denk aan de Euro invoering en de Millenniumbug). In die tijd werden in hele korte tijd veel mensen opgeleid tot software tester, al dan niet onder treurige verlokking van een mooie leaseauto die direct uit de showroom te rijden was. De opleiding bestond veelal uit een aantal computer-based trainingen gevolgd door een TMap training. Over het algemeen leidde dit niet tot heel groot succes bij de klanten, maar de IT-cowboys uit die tijd hadden daar weinig oog voor, zolang er maar omzet werd gedraaid.

Ook nu bevinden we ons in een situatie waarin de vraag het aanbod overstijgt. En dus worden er ook nu weer hele klassen vol testers opgeleid. Je zou denken dat we inmiddels iets geleerd hebben, maar het tegendeel lijkt waar. Waar in de jaren 90 het geleerde tenminste nog enigszins aansloot bij de werkelijkheid (waterval, functionele en technische ontwerpen van 200 pagina’s, alleen checken van specificaties en een doorlooptijd van maanden tot jaren), leren de nieuwe testers van nu in basis nog steeds hetzelfde. Zo zijn er nauwelijks vacatures te vinden voor testers waarin niet als eis is opgenomen dat men een TMap of ISTQB certificaat dient te hebben. Vaak is de argumentatie: “de basis van testen is niet veranderd”. En daar zit wel een serieus probleem, want de basis is wel degelijk veranderd!

Waarom leiden we testers op om checkers van specificaties te worden? Waarom leiden we ze niet op tot testers die waarde toevoegen aan een team en product? Hoe kunnen we de mensen die besluiten dat nieuwe moderne testers dergelijke oude certificaten moeten halen, beinvloeden om ervoor te zorgen dat dit soort eisen verdwijnen? Je vraagt een ontwikkelaar toch ook niet om zijn Cobol certificaat?

Wat zou het mooi zijn als we de beslissers op dit vlak eens zouden kunnen meenemen naar platformen van innovatie zoals bijvoorbeeld The Agile Testings Days of Testbash. Wellicht dat dat helpt om een moderne blik op testen te verkrijgen en welke skills daarbij komen kijken.

Het is tijd om in opstand te komen tegen de hyperinflatie van test-kennis en -kunde en te blijven innoveren en de huidige en komende generaties van testers op te leiden om serieus waarde te blijven toevoegen. Het halen van een TMap of ISTQB certificaat is daar geen onderdeel meer van.

Ergo: we moeten meer tijd stoppen in leren innoveren om ons vakgebied up-to-date te brengen en te houden. Daarvoor moeten we onze nek uitsteken en bijvoorbeeld nieuwe methodes en bijbehorende trainingen ontwikkelen en deze delen met de wereld. De Agile Testers hebben een startschot gegeven middels FAST (Flexible Approach in Software Testing) en de onderliggende Agile United trainingen waarin we heel veel aanwezige innovatie bij elkaar hebben gebracht tot een praktisch toepasbare methode die aansluit bij moderne systeemontwikkeling om met minimale inspanning een maximale toegevoegde waarde te leveren voor de klant, het team en het product.

De vraag die wat ons betreft rest is deze: wie volgt?

 

Wil je ook innoveren en een bijdrage leveren aan het moderne testen? Kijk dan op onze site.

Naar het overzicht