Agile Software Development krijgt steeds meer de overhand en daar is niets mis mee. Alleen houdt dit wel in dat we langzamerhand afscheid gaan nemen van de traditionele tester en steeds vaker te maken krijgen met een schaap met vijf of meer poten. Dus de rol van de tester verandert, maar verandert de tester mee?
Wat kenmerkt de traditionele tester? De traditionelen tester voert zijn werkzaamheden veelal handmatig uit en schrijft zijn testdocumenten op basis van uitgeschreven ontwerpdocumenten en afhankelijk van zijn specialisme zal zijn focus liggen op de unittesten, systeemtesten, ketentesten of acceptatietesten dan wel het coördineren of het managen van het testen.
De 'nieuwe tester' kenmerkt zich door zich niet alleen te kijken naar de testactiviteiten maar wanneer het nodig is of wanneer het moet kan hij of zij zich ook bezighouden met het schrijven van code dan wel het schrijven van ontwerpdocumenten. De nieuwe tester coordineert zijn eigen werk binnen zijn team en werkt nauw samen met de gebruikers, ketenpartijen en andere ontwikkelaars.
Als ik vaak rondkijk bij opdrachtgevers die werken volgens scrum, zie ik meestal de nieuwe tester aan het werk, maar toch ook vaak zie ik nog de traditionele tester aan werk, wachtend op de ontwerpdocumenten, het systeem tot dat hij gaat testen. Waar de nieuwe tester proactief zijn informatie gaat vragen aan de andere ontwikkelaars en op die manier samen met de andere ontwikkelaars het product ontwikkelt.
Dus terugkomend op mijn vraag, de rol van de tester verandert, maar verandert de tester mee? Het antwoord op deze vraag is niet zo evident als de vraag is. Een groot deel van de testers hebben de potentie om mee te veranderen en zich aan te passen aan de nieuwe realiteit en is het antwoord op de vraag dus een duidelijk: JA. Voor het andere deel:
1. zij kunnen proberen om te gaan met de nieuwe realiteit en de veranderende rol van de tester om armen, is het antwoord dus: JA., MAAR; of
2. zij zullen afhankelijk van hun focus een nieuw carrierepad in gaan slaan en is het antwoord dus : NEE.
Tom,
Er valt veel af te dingen op de analyse in je opiniestuk.
Allereerst je stelling dat er niets mis is met Agile Software Development; op deze site hoor ik tegenwoordig wel andere geluiden. Bijvoorbeeld Ewout Dekkinga in een (m.i. zeer terechte) reactie naar aanleiding van “Cloud: focus op de eindgebruiker”:
“Want afstemming in de keten is nogal moeilijk te verkrijgen als SCRUM teams vooral naar functionele oplevering sprinten en aspecten als overdraagbaarheid, efficiëntie en onderhoudbaarheid blijven negeren. “
En ook binnen het testvak blijken juist Agile-testers op zoek naar vaste grond, getuige het prima opiniestuk van Peter van Tulder.
Dat laatste is problematisch als je in dit artikel tot de conclusie komt dat slechts één soort tester zal overblijven, namelijk de ‘nieuwe tester’, die in jouw optiek dus een Agile-tester zal zijn. Dit onjuiste standpunt is terug te voeren op jouw veel betere opiniestuk uit maart 2010, met de titel: Wie test een service-oriented architecture? Helaas heb je de voortreffelijke reactie van Pepijn van de Vorst op dit artikel onvoldoende tot je door laten dringen.
In dit artikel kom je tot een onderscheid in vier soorten testers, namelijk de traditionele tester, de sturende tester, de technische tester en de procestester, en de voorzichtige conclusie dat met name de laatste twee zullen overblijven voor het testen van service oriented architectures. In dit onderscheid heb je mijns inziens één soort tester over het hoofd gezien, namelijk de functioneel tester. Voordat jij nu tegenwerpt dat dit een traditionele tester is, stel ik nu al dat deze tester juist een belangrijke rol kan vervullen in het testen van de nieuwste, op services gebaseerde architecturen.
Op basis van de reactie van Van de Vorst kom ik namelijk tot de volgende indeling:
– Selfservice/Portaal/Frontend (of misschien ook: Business-) tester
Moet in staat zijn op een agile manier met voortschrijdend inzicht, wijzigingen in het procesontwerp en weinig gedocumenteerde specificaties om te gaan.
– Functioneel tester (of: Applicatietester)
Speelt een rol bij het voorbereiden van testdata in gekoppelde systemen en het uitvoeren van testen vanuit de user interface van bestaande systemen. Maar let op: deze gekoppelde systemen betreffen backend applicaties die bij voorkeur onder architectuur zijn gebouwd, maar kunnen evengoed nog behoren tot de robuuste legacy van een organisatie.
– Technische tester
De ervaring leert dat zowel aan de voor- als aan de achterkant meer technisch georiënteerde testers nodig zijn voor platformafhankelijke zaken & testtooling.
– Aansturende tester.
Conform het aangehaalde opiniestuk en de gegeven reacties.
Zie hier de verschillende soorten testers die nodig zijn voor het testen van een grootschalige SOA.
Resteert de vraag wat precies de traditionele tester is van wie wij zo langzamerhand afscheid gaan nemen. Als jij deze beschrijft als een persoon die zijn werkzaamheden vooral **handmatig** uitvoert, dan lees ik snel verder naar je beschrijving van ‘de nieuwe tester’ die dan wel volledig zal inzetten op testautomatisering. Daarmee kom ik bedrogen uit, want die nieuwe tester blijkt volgens jouw opiniestuk helemaal niet aan testautomatisering te doen; wel blijkt hij als dat zo uitkomt opeens code te kunnen schrijven (bijvoorbeeld in Java?) of mee te kunnen schrijven aan ontwerpdocumenten.
In mijn optiek behoort testautomatisering juist tot de core business van testers. Er is dus behoefte aan een tool voor geautomatiseerd testen die de samenwerking tussen agile testers, functioneel testers en technische testers maximaal ondersteunt.
De traditionele tester waar we t.z.t. – door natuurlijk verloop uiteraard – afscheid van gaan nemen is die tester die niets van testautomatisering wil weten en hardnekkig alles handmatig wil blijven doen.
Heb je nog testers nodig als je met een abstracte model-, sjabloongedreven ontwikkelomgeving werkt zoals Mendix en Uniface? De testen beschreven in de requirementsfase (het zetten van veel koffie kan in één keer. Veel is 10 liter) zijn in zo,n omgeving gemakkelijk te isoleren op model niveau. Bouwen van een applicatie met behulp van deze abstracte ontwikkelomgevingen bestaat uit het assembleren van model en sjabloon definities. Testen buiten de requirementfase om (feedback van de gebruiker) is daarmee naar mijn bescheiden mening overbodig geworden.