We schrijven oktober 2016 en ineens kom ik tot de conclusie dat ik in de “double digits” zit met mijn testervaring. Ik weet nog goed dat ik vroeger in een willekeurige training mijzelf kon ergeren aan mensen die zich voorstelden met: “Ik ben … en heb 10+ jaar ervaring in de testwereld”. Tijdens het geven van mijn laatste gastcollege betrapte ik mijzelf op dezelfde introductie en kon een klein binnenpretje niet onderdrukken.
Ik hoorde voor het eerst over de opkomst van “Agile” en de impact op testen in 2008 op Eurostar met als centraal thema “The Future of Software Testing”. In de jaren die volgden ging het hele Agile-gebeuren aan mij voorbij. In 2014 veranderde dat. Ik startte bij de Rabobank in een nieuw te vormen team waarin we verantwoordelijk waren voor zowel nieuwbouw als onderhoud. Binnen dit team probeerden we Agile te werken via de Scrum methode. Ik haalde mijn scrummaster certificaat en kreeg de mogelijkheid om de scrummaster van het team te worden (of dit een logische stap is voor een testmanager vraag ik mijzelf nog steeds af, maar dat wordt een volgende blog).
Als ik terug kijk op de afgelopen twee jaar heb ik meer geleerd dan de 10 jaar daarvoor. Met de omslag naar Agile werken komt de meerwaarde van teams als bijna vanzelfsprekend naar voren en laat ik dat nu precies leuk vinden: “We may be strong as individuals – but as a team we are invincible“. Echter, met de kort-cyclische aanpak zien we ook dat projecten meer en meer gedreven worden door techniek, door een van mijn teamgenoten ook wel de “Tekkie Take-over” genoemd. Zelf ben ik behoorlijk meegegaan in trends van testautomatisering, Dockers, Jenkins Pipelines, testautomatisering op de service laag en ga zo maar door. Toch bekroop mij meer en meer het gevoel dat door deze beweging het “echte” testen verdrongen werd door wat ik noem het automatisch checken en het afmelden van een userstory zodat we deze weer als “af” kunnen bestempelen. Begrijp me niet verkeerd. Alles wat je kan automatiseren zou je ook moeten automatiseren indien je daar de capaciteiten en de ruimte voor hebt binnen je team. Zeker gezien het kort-cyclisch werken is de business case voor testautomatisering naar mijn mening allang een achterhaalde discussie. Maar kan je alles wel automatiseren? Laat een gebruiker zich automatiseren? En gaat testen niet over meer dan automatisch checken?
Met mijn eigen ervaringen en bedenkingen besloot ik om de training “Rapid Software Testing” te volgen welke dit jaar door James Bach in Nederland werd gegeven. Open-minded arriveerde ik, stelde mijzelf voor (zonder het aantal ervaringsjaren ;-)) en niet al te snel daarna verscheen daar de eerste oefening. Een simpele vraag: “Hoe zou jij Wordpad testen?”. Wordpad is dat kleine tekstverwerkingsprogrammaatje dat je krijgt bij Windows. Iedere cursist gaf een aantal suggesties en James reageerde op zijn James (Amerikaans, kortaf, bot en grappig tegelijk).
Eerlijkheidshalve wist ik eigenlijk ook niet waar te beginnen. Het idee achter deze oefening is dat testen draait om context. Waarom wil je dit testen? Wat vraagt de opdrachtgever nu precies? Hoeveel tijd is er? Allerlei standaardvragen welke ik in het verleden van nature stelde en nu stiekem wel eens vergeet. Zonder verder in te gaan op de training vond ik de slide hiernaast misschien wel de belangrijkste van de gehele training. En laten we eerlijk zijn, eigenlijk is dit niets nieuws maar geeft het goed weer wat testen is en zou moeten zijn. Ook bij technologie gedreven projecten zouden we dit niet moeten vergeten. Testen is naar mijn mening een creatief proces dat zeker niet vervangen kan worden door automatische checks.
Ook dit jaar stond het Testnet Najaarsevenement weer in mijn agenda. Tijdens dit evenement woonde ik o.a. de presentatie bij met de pakkende titel “Testautomatisering werkt niet bij CD en DevOps”. Tijdens deze presentatie werd openlijk de vraag gesteld of we misschien geen afscheid moeten nemen van de “testautomatiseerder”. De presentator kwam met de markante mening dat, over het algemeen, testers die testautomatiseerder zijn vaak slecht gestructureerde code opleveren (en daardoor vaak slecht onderhoudbare automatische testen). Stiekem deel ik deze mening wel een beetje. Dus aan ons als testers de taak om betere programmeurs te worden, indien je de ambitie hebt om goede oplossingen voor testautomatisering te realiseren. Of misschien toch maar de testautomatisering uitbesteden aan de developer in je team. Maar misschien is het nog mooier om dit samen met de developer in de vorm van “pair programming” te doen!
Naar mijn mening is de Agile manier van werken een geweldige verandering welke aansluit bij de “nieuwe wereld” met (in buzz-woorden) korte time-to-market, direct feedback via social media en appstores en applicaties met een korte lifecycle. De “automation first” strategie binnen de meeste agile teams is een must-have. Continuous integration en continuous delivery met de daarbij behorende testautomatisering (automatische checks) geeft een goede basis om de kwaliteit te verhogen en te checken. Echter wel met de gedachte om onder andere ruimte te creëren voor het echte testen. Je weet wel, dat creatieve proces dat alleen door echte testers gedaan wordt, gebaseerd op kennis, impliciete verwachtingen en niet meetbare eigenschappen.
In mijn dagelijkse werk en omgeving probeer ik de mensen bewuster te maken van de noodzaak van het echte testen naast het automatisch checken, omdat dit naar mijn mening in veel agile teams verloren is gegaan. Natuurlijk vergeet ik daarbij niet de noodzakelijk aanvulling van automatische checks, waar ik zelf inmiddels zeer veel plezier aan beleef! Technologie vind ik geweldig en ik heb dit ook weer opgepakt met een basiscursus Java. Mijn conclusie is dat mijn werk wel degelijk verandert en technischer wordt en dat ik dat erg leuk vind! Echter de basis van testen blijft onveranderd en mogen we zeker niet vergeten!
