Hoe word je een goede testautomatiseerder?

Geschreven door Eibert Dijkgraaf

Gepubliceerd op 01 oktober 2014

Op 20 juni werd voor de derde keer de Test Automation Day georganiseerd. De experts zetten ons aan het denken over het thema ‘The Future of Test Automation’. Praegus was erbij als supporter (zie www.testautomationday.com). Ondanks alle expertverhalen bleef ik, ingegeven door eigen praktijkervaringen, worstelen met de vraag: Maar hoe word je nou een goede testautomatiseerder?

Mijn eerste kennismaking met testautomatisering stamt uit 1997.

Als trainee software tester mocht ik op intake voor mijn eerste klus en daar werd me verteld dat ze gebruik maakten van WinRunner v4.01. In het team waren enkele programmeurs die veel extra’s erbij hadden gebouwd, waardoor je o.a. je scripts data-driven kon gaan uitvoeren (inderdaad… de tools uit die tijd waren nog niet zo geavanceerd).
Na afloop van de intake bracht ik verslag uit bij mijn coach op het hoofdkantoor. Ik vertelde hem dat ze werkten met “een testtool”; een woord dat in de hele opleiding niet was gevallen. Zijn reactie was ook vergelijkbaar: “Een testtool? WinRunner? Nooit van gehoord.”
Gaandeweg de jaren heb ik met vallen en opstaan de nodige ervaring opgedaan, met dank aan vele collega’s. De ene keer intensiever dan de andere keer, maar de geleerde lessen blijken tot op heden nuttig.
Luisterend bij de Test Automation Day in 2013 bekruipt me dan wel eens het gevoel dat we met z’n allen maar langzaam vooruit gaan in het volwassen worden op het gebied van testautomatisering.
Veel lessen en tips die langs kwamen klonken bekend en konden we ook 10 jaar geleden al lezen. Soms krijg ik de indruk dat we met z’n allen telkens in dezelfde valkuilen lopen. Wel verandert de techniek, zowel aan de toolzijde als bij het te testen object. Maar veel van de uitdagingen blijven hetzelfde.
Ook in de praktijk kom ik dat tegen. Een ‘newbie’ met een testtool die met verbazing constateert: “Soms doet’ ie het wel en soms doet’ ie het niet…”. Ik denk dan al gauw aan een synchronisatieprobleem en in 9 van de 10 gevallen blijkt dat terecht. Dat is de eerste constatering. Maar vervolgens beland je in de situatie hoe je daar het best mee om kunt gaan. Vervolgens zie je de ‘newbie’ beginnen met een keihard ‘wait’-statement en middels trial-and-error doorgroeien naar meer inventieve oplossingen die je gaan garanderen dat je daadwerkelijk ‘unattended’ kunt gaan uitvoeren.
Op dit soort momenten gaan mijn handen jeuken en wil ik zo iemand graag overstelpen met alle kennis en ervaring die er te vinden is, om direct tot een goede oplossing te komen. Maar is dat de juiste manier?
Tijdens het genoemde event nam één van de sprekers ons mee in de problematiek van de objectherkenning. Ook hier zijn al veel voorzieningen die de testautomatiseerder in staat stellen om snel meters te maken. Maar in het verhaal horen we hoe stapsgewijs, telkens opnieuw de neus wordt gestoten, waarna er een nog betere en stabielere oplossing wordt gevonden en toegepast.
Ik blijf achter met de vragen: Wat is de beste manier om met een testtool te leren werken? Heb je altijd ervaren krachten nodig? Hoe haak je anderen aan, die nog niet die ervaring hebben?
Daarnaast moet in het specifieke geval van testautomatisering ook nog de afweging langs komen over het wel of niet automatiseren. Welke onderdelen en welke testgevallen komen hier het beste voor in aanmerking? Zijn deze keuzes te maken zonder goed op de hoogte te zijn van de (on)mogelijkheden van testautomatisering?
De standaard cursussen voor het werken met testtools voorzien voornamelijk in knoppenkennis, maar niet in testautomatiseringskennis. De features worden mooi opgepoetst; maar er wordt nauwelijks stilgestaan bij het inpassen van de tooling in het testproces om de inzet optimaal te benutten. Als je niet oppast, wordt het een technisch feestje, waarbij de kwaliteit van het eindproduct of de inbedding in de te volgen teststrategie volledig uit het zicht verdwijnt.
Soms wil ik goed bedachte oplossingen al op voorhand delen. Maar dan blijkt later dat men het nut van dergelijke ‘ingewikkelde’ oplossingen niet ziet. Men laat het los en valt alsnog in de valkuil waar men eerst (onbewust) over heen was gestapt. Dit gebeurt bijvoorbeeld bij het onderhoud van geautomatiseerde scripts. De eerste opzet kan heel doordacht zijn; maar als anderen het later gaan onderhouden worden de aanpassingen niet meer vanuit dezelfde visie doorgebouwd. In de praktijk heb ik zo mooie keyword-driven architecturen zien afbrokkelen naar Record&Playback niveau.
Ook ik moet soms loslaten. Laat iemand maar bewust zijn neus stoten, want eigen lessen beklijven toch het best.
Hoe kunnen we dan toch volwassen worden? Door het combineren van een juiste mix van ervaring, advies en al doende leren.
Zonder al teveel theorie bij u op het bureau te willen neerleggen, ben ik van mening dat we moeten leren van onze ervaringen om zo iedere keer beter te worden. Ook testautomatiseringstrajecten moeten efficiënt worden uitgevoerd. De kennis en best-practices op het gebied van testautomatisering wil Praegus graag met u delen. Daarom bieden we u de Praegus Smart Indicator Testautomatisering (PSI) aan. U kunt middels het invullen van een online QuickScan via www.testscan.nl snel een realistisch beeld krijgen van de mogelijkheden van testautomatisering binnen uw context.

Schrijf een reactie

Gerelateerde artikelen