De authentieke tester: kunst of kitsch?

Auteur: Damien van der Wal ● damien.van.der.wal@bartosz.nl

Damien van der Wal2De veranderende markt- en klantvraag in de nieuwe ‘Scrum en Agile’ wereld brengt voor zowel werkgevers als werknemers verscheidene vragen met zich mee. Denk hierbij aan verandering in visie, strategie en de core-business. Wat gaan we leveren en waarin gaan we ons onderscheiden van de concurrenten? Testautomatisering, performancetesten en securitytesten hebben momenteel de volle aandacht.

De technische tester
Sinds Agile zijn intrede heeft gedaan zien we veel verbeteringen binnen het ontwikkel- en testproces. Onderdeel hiervan is het direct automatiseren van de testgevallen om zo bijvoorbeeld een doorlopende regressietest te kunnen draaien op elke wijziging op de programmatuur. Vooral de tester heeft deze automatiseringstaak bij zijn werkzaamheden gekregen. En er wordt hierdoor steeds minder een beroep gedaan op manuele testers.

De tester van tegenwoordig moet steeds technischer zijn om zodoende met tooling de testgevallen te kunnen automatiseren. Onder invloed van Agile neemt het automatiseren van testgevallen zo het terrein over van het handmatig uitvoeren van tests. Wat betekent dit voor de niet-technische tester, oftewel de authentieke tester? Zijn dit echt de hoefsmeden van de toekomst zoals Rini van Solingen opperde tijdens het TestNet Najaarsevenement? Nee. Ik ben van mening dat de authentieke tester ook in de Agile omgeving blijft bestaan.

De meningen zijn verdeeld
Voorstanders van het automatiseren van testgevallen claimen dat testers technische kennis moeten opdoen. En dat zij het programmeren van testgevallen in elke denkbare tooling moeten kunnen uitvoeren. De kwaliteit van het testen zou hiermee verbeterd worden. Anderen zijn van mening dat programmeurs de testgevallen dienen te programmeren. Zij kunnen dat immers veel sneller en waarschijnlijk ook beter. In de praktijk ervaar ik dat het automatiseren van testgevallen flinke toegevoegde waarde heeft en niet meer weg te denken is uit het gehele proces. Ik kom zowel opdrachten tegen waar de testautomatisering door toolexperts gedaan wordt, als opdrachten waarbij de tester de testautomatisering voor zijn rekening neemt. In dit artikel kijken we naar de situatie waar de tester niet automatiseert.

De authentieke tester is Agile
De authentieke tester is een tester die tussen de business en IT staat. We hebben het dan over de persoon die het Detail Test Plan schrijft, testgevallen ontwerpt en deze handmatig uitvoert. Maar zich ook bezighoudt met het toepassen van testtechnieken, het signaleren van risico’s en het pragmatisch schakelen tussen prioriteiten. De authentieke tester is de tester die het functioneel ontwerp controleert en deze bij de business met vraag en aantekening aanbiedt. De tester die meedenkt met de business. Dit zijn onderdelen van het testvak die je als tester leert door ervaring, niet door drie maanden lang trainingen te volgen op het gebied van testen en automatiseren. Hierdoor is de ervaren authentieke tester nog steeds onmisbaar bij opdrachten waarbij testmanagers, testcoördinatoren en testers betrokken zijn. Klinkt bovenstaande als waterval? Ik ontdek juist veel onderdelen die ook binnen Agile genoemd worden.

Dezelfde werkzaamheden in een Agile jasje
De organisatie wordt meer en meer IT. Iedereen binnen Agile wordt technischer, ook de business afgezant; de zogeheten Product Owner. Je bent als tester dus niet meer de directe spil tussen de business en IT, je bent onderdeel van een team. Het werk verandert echter niet. Eerdergenoemde onderdelen van het testvak zoals risico’s signaleren, direct schakelen met de business, pragmatische aanpak en testtechnieken toepassen, veranderen niet, ze worden alleen in het Agile jasje gegoten. Wanneer je het Agile Manifesto leest, zie je alleen maar taken staan die volstrekt logisch zijn en die je eigenlijk al deed. Het vervelende papierwerk daargelaten… Hoe kan de niet-technische authentieke tester dan ingezet worden?

Agile: team wel, organisatie niet
De authentieke tester is allereerst van groot belang in een Agile project waarbij de organisatie zelf niet Agile is. Vaak wordt er een multidisciplinair Scrum team samengesteld met ontwikkel en test. En de Product Owner dan? Nee, als tester haal je de informatie bij de business, zoals vanouds. Veel papier, veel review, vaak veel onzinnige tijdsverspilling. Hier is de authentieke tester nodig. Hij weet als geen ander hoe het ‘ooit’ werkte. Tegelijkertijd kan de tester de business begeleiden en hen meenemen in de transformatie.

Authentiek in Agile
Nu hebben we benoemd hoe waardevol de ervaren tester is in omgevingen die nog niet of slechts deels over zijn naar Agile. Dan blijft de goed ingerichte Agile organisatie over. Uiteindelijk bepaalt het team de invulling van de rollen, niet de organisatie. Jij kan met jouw team beslissen dat het test automatiseren gedaan wordt door de ontwikkelaar. Want uiteindelijk wil je als tester jouw tijd toch het liefst gebruiken om meer testgevallen te ontwerpen? Testgevallen die de kwaliteit van het product nog beter aantonen. Geen tijd spenderen aan het ‘programmeren’ van testgevallen terwijl de ontwikkelaar met zijn ervaring dit veel sneller en wellicht beter kan! Je moet de ontwikkelaar wel van dienst zijn. Door bijvoorbeeld de testgevallen zo te omschrijven dat ze gemakkelijk te automatiseren zijn. Daar kom je samen wel uit!

Conclusie
De authentieke tester blijft waardevol. De toepassing van testkennis en -ervaring is waar het om draait en niet enkel het automatiseren van tests. Agile zorgt ervoor dat het voortbrengingsproces binnen het team telkens wordt verbeterd en aangepast, en hetzelfde geldt voor de rollen binnen het team. Dit betekent niet dat testers per definitie moeten test automatiseren. Het snel en iteratief ontwikkelen in korte sprints vraagt om geautomatiseerde tests, wie dit doet maakt voor de klant niet uit. Het gaat erom dat het team dit oppakt en inricht, en van belang is dat daarbij zoveel mogelijk testkennis behouden blijft. Daarmee is de authentieke tester een Agile teamlid met de kwaliteit van software als aandachtsgebied. Hierdoor is er sprake van kunst, zeker geen kitsch!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *