Agile kwam, nee echt agile kwam niet, scrum kwam en daarmee dachten we ook agile te zijn. Overal in het land werden de silo’s omgevormd tot scrum teams. Een goede ontwikkeling want ineens zat je echt naast de analist of ontwikkelaar. Je pikte dingen op over andere disciplines en als tester had je directer invloed op bijvoorbeeld ontwerpen. Vandaag de dag is elke tester een agile tester, agile testcoördinator of zelfs agile testmanager. Die laatste twee snap ik niet en ook met de eerste heb ik nog steeds moeite. Wat is toch die agile tester? Een tester die in een scrum team zit? Wat maakt een tester nou precies agile? Ik steek daar expres de draak mee want ik zie om mij heen nog zoveel (agile) testers die hun TMap boek pakken en testgevallen destilleren uit de testbasis – welke gevormd is door een ready team voordat de sprint begint – en daarmee twee wekelijks watervallen. We hebben echt veel moeite om een potential shippable increment op te leveren omdat nog veel organisaties en scrum teams er nog niet klaar voor zijn. Hoe dat komt? Omdat we denk ik nog onvoldoende samenwerken en nog onvoldoende multidisciplinair zijn. Daarnaast is het hebben van een ISTQB en/of TMap certificaat vereiste voor bijna alle testvacatures voor zowel op vaste basis als op opdrachtbasis. Dit terwijl er te weinig aandacht is voor Exploratory Testing in deze twee methodieken.

Testautomatisering is zo belangrijk geworden dat we een tekort hebben aan testautomatiseerders. Alles draait om Selenium en er ontstaan bedrijven die zich richten op technisch testen en alleen testautomatiseerders leveren. Vanuit marketing noemen we het ‘geautomatiseerd testen’ en hebben we zelf een functie: ‘een geautomatiseerde tester’. Ik zoek overigens iemand die mij kan uitleggen wat geautomatiseerd testen is want er lijkt veel mis te zijn met dit begrip. Hebben we niet met zijn allen een scheve testwereld gecreëerd? Testers die niet kunnen automatiseren en automatiseerders die niet kunnen testen? Waarom maken we zo’n groot onderscheid tussen de tester en de testautomatiseerder?

Nu, tien jaar later, twee koopwoningen verder, twee werkgevers verder, inmiddels getrouwd en regelmatig vind ik een grijze haar bij mijn bakkebaarden (overigens geen relatie tussen de laatste twee) vraag ik mij af of de veranderingen die we nu zien in het testvak een evolutie of revolutie zijn. Zoals ik hierboven schets, de evolutie is er altijd geweest op het gebied van technologie en ontwikkelmethodieken. Testen, op zich zelf geen trendsetter, heeft altijd netjes gevolgd met de trends in de markt.

Nu zie ik de testwereld toch echt veranderen. Acht jaar lang kon ik redelijk makkelijk mee laveren met de kennis die ik opgedaan heb tijdens mijn masterclass testen. De invulling van de testwerkzaamheden veranderde langzaam met de markt mee. Maar nu, nu is er toch wat aparts aan de hand in de markt. Ontwikkelaars worden steeds meer bewust van de kwaliteit, testen zelf hun opgeleverde software beter en beter en de snelheid waarmee Continuous Delivery en DevOps software neerzet is fenomenaal. Het is de weg naar echt agile zijn en daar kom je als tester niet meer weg met je testcase, bevindingenregistratie en een berg geautomatiseerde end-2-end testen via Selenium. Aan het eind van de sprint is die potential shippable increment echt een vereiste of plaatsen we de software zelfs na elke kleine aanpassing opnieuw in productie. Gescript testing wordt vervangen door voorbeelden welke we samenstellen door middel van BDD en we hanteren SbE. Exploratory Testing is daarnaast een must maar helaas zijn er niet zoveel testers die hier echt goed in zijn. Ik kan iedereen daarom de training Rapid Software Testing (RST) aanraden. Geweldige training! Iedereen begint te testen, ook de ontwikkelaar die deze RST-training heeft gevolgd en een ET-charter opstelt. Testautomatisering? Dat doen we niet meer separaat. BDD/TDD zijn zo ingebakken in de werkwijze dat we een correcte invullen krijgen van de test automation pyramid danwel ice-cone. En we noemen het nu check automation. En wie realiseren die geautomatiseerde checks met outside-in-development? De ontwikkelaars en niet meer de testautomatiseerders. Hoe gaaf is dat?! We krijgen goed onderhoudbare testautomatiserings code die net zo belangrijk wordt geacht als de productiecode. Betekent dat het einde van de testautomatiseerder?

Kwaliteit is nog nooit zo belangrijk geweest omdat fouten grote schade kunnen aanrichten aan de reputatie van bedrijven. Dit speelt nu meer dan ooit, de concurrentie is groter dan ooit, de time-to-market moet korter zijn dan ooit. De noodzaak van testen is daarbij ook nog nooit zo groot geweest. De tester zoals we deze nu kennen zal gaan verdwijnen, althans, in omgevingen welke naar Continuous Delivery en DevOps bewegen. Er zal een nieuwe functie ontstaan, noem het maar de feedback engineer. Deze engineer zal continu feedback verzamelen. Feedback over of het product op de juiste manier is gebouwd, op het juiste moment en ook zal door middel van monitoring vastgesteld worden of het daadwerkelijk in productie zijn waarde toevoegt. Ik vind dit toch echt een hele andere invulling van het testvak dan de voorgaande veranderingen. Wat mij betreft een revolutie en daar is lang niet iedereen het mee eens, laat staan blij mee.

Het vreemde is dat het lijkt alsof deze revolutie niet of nauwelijks gedragen wordt door de echte testondernemingen of test businessunits bij bedrijven welke beide grote getalen testers leveren vanuit de detachering. De revolutie wordt gedragen door met name de software ontwikkel partijen. Slapen de testondernemingen niet te veel of houden ze niet te veel vast aan het oude? Of verloeder ik mijn eigen vakgebied door er – zo lijkt het tenminste – anders naar te kijken? Is er nog wel werk over een aantal jaar voor de gemiddelde tester en/of testautomatiseerder? Het zijn zomaar een paar vragen die mij bezighouden en ik praat er graag en enthousiast met je over.

Wat ik wel kan vertellen is dat mijn leercurve de afgelopen tien jaar nog nooit zo stijl is geweest als op dit moment en dat mijn passie en plezier in het vak nog nooit zo groot is geweest. Ik geniet van de opmerkingen van ontwikkelaars die blij zijn met de CI-build die binnen 10 minuten feedback geeft of hun refactor slag niet per ongeluk iets stuk gemaakt heeft. Ik geniet ervan om te faciliteren, om te zorgen dat ontwikkelaars sneller kunnen ontwikkelen. Ik geniet om echt te leren programmeren met mock objecten en in-memory testdata generatoren in plaats van scripten. Ik geniet ervan om de voorbeelden uit te werken met een analist en ontwikkelaar tijdens een three amigo sessie, en ik geniet ervan om de CD-pipeline in te richten. Ik geniet van de coaching die ik geef om jawel, mijzelf overbodig te maken.

Maar vooral geniet ik van het feit dat de kwaliteit van de software die we opleveren steeds beter wordt. Dat zonder een van tevoren geschreven testplan van 30+ a4tjes of door een vervelend ingerichte bevindingenregistratiesysteem. Samenwerking, pair-programming, mindmaps & schema’s aan de muur en veel feedback over en weer, op alle fronten en een enorme dekking met snelle geautomatiseerde checks. Ik raad het je aan om het avontuur aan te gaan, het is zoveel leuker!