De laatste tijd hoor je in de markt steeds meer geluiden over de veranderingen die gaande zijn in het testvak. Zo kunnen testers in agile teams ‘niet zonder programmeerkennis’, is de tester van de toekomst een ‘ontwikkelaar die testcode schrijft’ en zijn testers die alleen functioneel testen ‘op korte termijn op zoek naar een andere baan’.
Veel van bovenstaande meningen hangen sterk samen met de groei van de populariteit van geautomatiseerd testen. Niet gek, want met de opkomst van agile werkvormen is de business case voor geautomatiseerd testen een stuk sneller positief. Waar we ‘vroeger’ pas nadachten over geautomatiseerd testen als de eerste release (bijna) in productie stond, staat het nu vanaf dag 1 op de agenda en dat is maar goed ook. Testwerk wordt er leuker van, herhalende controles kunnen veelal geautomatiseerd worden afgehandeld en door na elke wijziging te kunnen regressietesten groeit het vertrouwen in de kwaliteit van het product.
In deze blog 4 redenen waarom geautomatiseerd testen niet leidt tot minder werk voor testers.
1- Testen is keuzes maken
Testautomatisering zetten we voornamelijk in bij testuitvoering. Planning, voorbereiding en specificatie blijven voorlopig echt nog testactiviteiten waarvoor testexpertise benodigd is. Testtools kiezen niet welke functionaliteit je waar of op welk moment aantoont en maken geen keuzes met betrekking tot dekking en diepgang. Alles testen is, ook met behulp van een tool voor geautomatiseerd testen, nog steeds niet mogelijk.
2- Onbekende onbekenden
Een groot deel van testen draait om het vinden van niet voorspelde – of voorspelbare – gedragingen in de applicatie die je test. Waar mensen kunnen reageren op onverwachte gedragingen, variaties in testdata of externe factoren kan een tool voor geautomatiseerd testen alleen die acties en controles uitvoeren die vooraf zijn gespecificeerd. Juist in de gedragingen die niet of moeilijk voorspelbaar zijn doen we als testers de meeste bevindingen.
3- Code schrijven om code te testen?
Klinkt gek hè? We starten als testers als het gaat om het automatiseren van (functionele) testen heel vaak een software-ontwikkeltraject binnen ons software-ontwikkeltraject. Alleen laten we dat dan uitvoeren door testers in plaats van programmeurs en gaan we er klakkeloos vanuit dat de testers hun eigen code wel goed zullen testen. In deze aanpak zit een probleem; softwaretesters zijn niet de beste programmeurs. De oplossing lijkt simpel: laat programmeurs de testoplossing maken. Helaas zijn programmeurs meestal niet de beste testers, waardoor deze aanpak grofweg 3 uitkomsten kan hebben:
- Een goed passende oplossing die onvoorspelbare resultaten geeft en niet te onderhouden is vanwege slechte code;
- Een codetechnisch mooie oplossing die niet goed inpasbaar is in het testproces, omdat testers hun testen moeten vastleggen in code, of omdat de requirements door de ontwikkelaar anders zijn geïnterpreteerd dan de tester ze bedoeld had;
- Een goed passende oplossing die ook technisch goed is uitgewerkt, maar twee keer zo duur is, omdat zowel testers als programmeurs er veel tijd aan hebben moeten besteden.
Alle drie niet optimaal. Beter is het om gebruik te maken van een testtool die het programmeerwerk overbodig maakt door het toepassen van een generieke abstractielaag. Deze tools zijn met een relatief vlakke leercurve bruikbaar voor testers en dwingen vaak ook een aanpak af waarmee testen, testdata en omgevingsinformatie gescheiden kunnen worden. De tester wordt daarmee ook niet in de verleiding gebracht om door middel van condities in testgevallen meerdere testen in één testcase te combineren. De uitdaging hier ligt niet zozeer in het leren van de applicatie, maar in het toepassen van een gestructureerd proces om testen onderhoudbaar, robuust en effectief te kunnen automatiseren. En laat dat nu net iets zijn dat veel testers goed beheersen.
4- Slecht automatiseerbare testsoorten
Hoe automatiseer je gebruikersacceptatietesten? Hoe stel je geautomatiseerd vast dat de usability van je applicatie is wat je gebruiker ervan verwacht? Niet elke test leent zich voor automatisering. Een stuk tekst in een Excel sheet kan heel anders overkomen in de context van je applicatie. Een requirement kan, hoewel juist geïmplementeerd, leiden tot een voor de gebruiker ongewenste workflow. Wie herinnert zich zijn eerste kennismaking met Windows Vista en het daarbij behorende ‘User Access Control’? Vier keer op ‘OK’ of ‘Ja’ klikken om een bestand te verwijderen is voor een testtool geen probleem. Requirements vervuld, test geslaagd. Toch?
Testautomatisering brengt wel degelijk veranderingen met zich mee.
En net als elke verandering zal ook deze soms stuiten op weerstand bij betrokkenen. Die weerstand zou echter niet moeten voortkomen uit angst voor het verdwijnen van het vak dat wij testers allemaal met veel passie beoefenen. Het wordt er – mits automatisering goed wordt ingezet – alleen maar leuker van. Je bent immers minder tijd kwijt aan repeterend werk en saaie checks op eenvoudige requirements. Er is meer ruimte om op ontdekkingsreis te gaan in de applicatie die je test en het vertrouwen in je werk zal door inzet van testautomatisering groeien. Blijf wel altijd, maar dat is testers op het lijf geschreven, kritisch kijken naar nut, noodzaak en efficiëntie van de ingezette oplossingen. Blijf ook nieuwe dingen leren! En ook al zullen testers en programmeurs altijd hun eigen expertise behouden, het is nooit verkeerd om als tester meer te leren over de wereld van programmeren. Al was het maar om binnen je team of afdeling gemakkelijker te kunnen communiceren.
