Tijdens SeleniumConf 2019 in Londen was een van de Keynote speakers Richard Bradshaw. Hij staat bekend als “Mr. Selenium” en is een hoge pief binnen “The Ministry of Testing”. Zijn inzicht heeft mij als tester geïnspireerd om anders met testautomation om te gaan. In deze blog licht ik graag toe wat Richard tijdens zijn presentatie heeft gezegd en hoe dit in de praktijk gebruikt kan worden; sluit je Test Automation aan bij je opdracht en gebruik je het op de juiste manier? Zijn er andere manieren om Test Automation in te kunnen zetten? Lees verder voor de antwoorden!

Het gereedschapskistje
Als wij als test automatiseerders starten met een opdracht begint het meestal met het idee dat er een grote selectie testscripts reeds bestaan. Deze moeten dan met behulp van Selenium geautomatiseerd worden. “Succes”, wordt er nog gezegd, en de testautomatiseerder gaat keihard klikken en tikken om alle testcases te automatiseren. Sommigen falen, sommigen gaan goed, en dat is je werk voor het komende jaar.

Het gevaar is dat na verloop van tijd je geen idee meer hebt hoe het systeem werkt. Je hebt kennis van een klein stukje van het systeem wat geautomatiseerd is, maar waarschijnlijk niet meer van het geheel. Je test alles door de UI heen en elke stap die er genomen wordt naar de backend wordt impliciet mee getest. Om alleen al een simpele boeking te doen op een boekingssite, worden er talloze API’s aangesproken, databases geraadpleegd en nog veel meer. Een UI script raakt ook al die dingen, maar zodra het fout gaat ben je een lange tijd bezig om precies te zoeken waar en waarom het fout gaat. Dat het wel eens fout gaat is zeker!

Terwijl je aan het uitzoeken bent waar het probleem zich bevindt, ben je aan het leren. Je leert over het systeem, over de interacties en over informatieverplaatsing. Je herschrijft je code en draait alles opnieuw af, met de hoop dat dan alles op groen gaat. Het script weet maar één ding en dat is wat jij als tester hem vertelt wat hij moet doen. Als hij dat niet weet, gaat hij op rood, en kun je weer van voor af aan beginnen. Vaak werken we als testautomatiseerders graag met de tools waar we goed in zijn, maar we moeten niet blind gaan automatiseren, ook al is dat de opdracht.

Testability
Voortaan, als ik een opdracht begin, zal ik meer gaan kijken naar wat er is om mee te werken. Ik moet leren om te kijken naar het probleem, en niet naar mijn gereedschapskist met toffe tools. Testability komt dan al snel om te hoek kijken; de graad van mogelijkheid in software om getest te kunnen worden. Hoe hoger de testability van software, hoe eenvoudiger je verschillende tools erop kan loslaten. Er zou geen pre-definitie moeten zijn dat “driehoeken van testen” (let op: testpiramide bestaat niet, piramides zijn 3d) dé defacto standaard moeten zijn. Het leuke is: als het nodig is dat er meer in de UI getest moet worden is dat prima. Als de huidige testability van het bedrijf alleen dit toe laat, dan heb je genoeg om mee te werken om iets op te zetten. We moeten niet achter een model aan willen jagen waarvan iemand ooit online heeft gezegd wat een fantastisch idee het was. Het was misschien een fantastisch idee, maar voor zijn opdracht, in zijn industrie met de tools die voor hem voor het oprapen lagen. Zo blijkt: Alle modellen zijn fout, sommige zijn bruikbaar.

Checks zijn dan ook prima. Ze geven informatie, ze zorgen dat de aandacht van de tester naar een falend stuk software gaat. Ze zijn de uitnodiging om extra ergens in te duiken als ze falen.

Richard Bradshaw en zijn Londense opdracht
Richard Bradshaw begon een opdracht in Londen waar hij net binnen kwam tijdens een “Regressietest fase”. Blijkbaar was hier twee weken nodig om 89 scenario’s te testen op 14 verschillende mobile devices. Richard keek hier naar en ging aan de slag om de scenario’s met Appium af te trappen. Maar de Testability van de app was daar nog lang niet. Ergo, dat ging niet.

Na observatie bleek dat de al aanwezige tester 80% van de tijd bezig was met het aanmaken van testdata in MongoDB. Dit probeerde Richard dan ook te automatiseren. Hij begon met een clean installatie, maakte een entiteit aan en deze werd in 72 verschillende collecties binnen Mongo aangeroepen. Dit was ook te massief en was ook al niet te automatiseren.

Na nogmaals te kijken naar de tester, zag hij dat alle data met de hand ingevoerd werd aan de admin kant van de applicatie. Om dit proces sneller te laten gaan heeft hij Webdriver gebruikt. Voor één van de 89 scenario’s waren er zeven handmatige stappen die de tester moest doorlopen om testdata klaar te zetten. Na een paar uurtjes werk had Richard een Webdriver script geschreven die dat in twee minuten deed. Dat is een voorbeeld van Automation in Testing: het script van Richard was geen automatische test en geen automatische check, maar het versnelde de tijd aanzienlijk die er nog nodig was voor het aanmaken van de testdata. Namelijk met zo’n zeven dagen, daarnaast konden er nu al na drie dagen testen gereleased worden. Enkel door het automatisch aanmaken van data. Aan het einde van de dag was het eigenlijk een soort robot, die de testers hielp met het werk.

Zes redenen om te Automatiseren
Als je dat principe verder trekt, zijn er 6 onderdelen waar je automatisering kan inzetten om je testwerkzaamheden te verbeteren, te versnellen en te stabiliseren;

• Repetitie
  Als je het gevoel hebt dat je iets over en over en over moet doen, kijk dan naar automatie om dat voor je te laten doen. Maar vooral: waarom doe ik hetzelfde steeds opnieuw?
• Schaduwen van collega’s
  Als ze er zijn, kijk mee met exploratory manual testers. Bij hen vind je mogelijkheden die het gebruik van een tool toejuichen. Dit kan ook werken bij andere leden van het team! Deel je kennis en je maakt ook voor andere het werk een stuk aangenamer.
• Oh Jeez…
  Iedere tester kent het wel: dat ene scenario waar je tegenaan zit te hikken omdat het lastig is, of omdat het bijna gegarandeerd omvalt. Als je zo’n situatie tegenkomt: automatiseer het! Er is ongetwijfeld een tool die het werk van je kan overnemen zodat je nooit wéér die test hoeft uit te voeren.
• Tijd
  Als het onmogelijk is om een compleet proces te automatiseren kun je misschien kleinere onderdelen wel automatiseren? Elk stukje is dan meegenomen en alles opgeteld zal het nog steeds tijdswinst zijn voor de volgende keer.
• Stappen
  Als je zeven stappen moet doorlopen om te beginnen met exploratory testing, en stap één tot zes zijn steevast hetzelfde, automatiseer die dan! Zorg dat al die stappen alvast zijn doorlopen met een script, draai die 50 keer, en je hebt 50 openstaande browsers waarin je direct kan beginnen met exploratory handmatige testen. Dit is ook een vorm van automatisering in testen en het scheelt zeeën van tijd.
• Verveling
  Ben je dagen lang hetzelfde aan het doen en voel je dat je compleet met het vak wil stoppen? Waarschijnlijk ben je dan iets aan het doen wat je eigenlijk zou kunnen of moeten automatiseren. Als je niet aan het leren of aan het ontdekken bent, dan ben je waarschijnlijk iets herhalend aan het doen wat je niet hebt geautomatiseerd.

Automation in Testing (AiT), geen Testautomation
Testautomatisering wordt te vaak ingezet om een specifiek doel te behalen, maar het kan zoveel meer zijn dan dat. Automation in Testing (AiT) is een mentaliteit en naamruimte die mensgerichte automatisering in de context van testen bevordert. AiT richt zich op de strategie, het creëren, gebruiken en opleiden van waardevolle automatisering die onze testactiviteiten echt ondersteunt. Je kan nooit het menselijke component (proberen te) verwijderen uit je automatiseringsproject. Wij bouwen het, wij ondersteunen het, wij repareren het. Wij bepalen of het nodig is of niet en wij monitoren het; de mens blijft altijd belangrijk.

Bij deze mentaliteit horen de volgende basis principes:

• Waarneembaarheid boven Begrip
  We moeten, als iets live staat, dit kunnen observeren. We willen het weten op het moment dat het fout gaat, en waar. Voor een lange tijd hebben we een stuk software getest van binnen en van buiten op veilige omgevingen voor het naar productie kon. We hebben uren gespendeerd om het zo solide mogelijk te krijgen. Tegenwoordig zijn er tools die ons vertellen dat het verkeerd gaat, waar en wanneer. Gebruik deze.
• Ondersteunende tests boven Replicatietests
  Met replicerende tests worden gebruikerstests bedoeld: testautomatisering die het gedrag van een gebruiker repliceert. Daadwerkelijk 100% test gedrag repliceren is lastig. Als je als tester vaker je hersens aanzet ga je niet elke keer normaal door een flow heen, maar als je een potentieel pijnpunt in de flow ziet, druk je erop. Dan nog een keer, daarna op een andere manier. Dit zijn niet dingen die een normale gebruiker zou doen, en toch doen we het. Het geeft ons meer vertrouwen in het systeem, meer informatie over de kwaliteit. Een replicerende test is sneller, maar het kan niet nadoen wat een tester doet.
• Testbaarheid boven Automatiseringsmogelijkheden
  Als elk element op een website een ID heeft, en alles kun je met een script vinden, is het fantastisch. Echter, als daarna het complete proces eromheen vreselijk is, dan heb je er vrij weinig aan. Kijk niet alleen naar je code, maar naar het testproces. Anders, wat je overhoudt, is een glimmende diamant in een vies, giftig moeras.
• Testing Expertise boven Coding Expertise
  Gevoelig puntje; wanneer je een ’tester’ vraagt om iets te automatiseren, dan zal hij dit doen. Als hij Codeerkennis heeft zal hij allicht een prachtig stukje code opleveren die precies doet wat je vraagt. Vraag je een daadwerkelijke tester iets te automatiseren dan krijg je iets wat misschien in de code niet fantastisch aan elkaar geplakt zit, maar wel iets wat bewezen waarde heeft. Er wordt gekeken naar risico’s en er worden overwegingen gemaakt om de kwaliteit zo hoog mogelijk te houden. Echte testers tonen initiatief met wat er wel getest en geautomatiseerd moet worden en wat niet. Echte testers zullen nooit klakkeloos doen wat je ze opdraagt, maar verder gaan dan dat.
• Risico boven Dekking
  Ga niet automatiseren omdat het kan. Automatiseer omdat het moet en er een risico is op een bepaald stuk software. 100% Coverage klinkt leuk, maar de daadwerkelijke coverage is lastig tot niet te bepalen. Een relatief waardeloze statistiek terwijl een gedegen risico analyse veel meer waarde oplevert.
• Problemen vóór Tools
  Laat de problemen binnen je project leidend zijn over welke kennis je hebt. Vraag “Waarom” en vraag het vaak. Als je als tester binnenkomt met enkel Selenium kennis, is dat de tool die je vaak zult gebruiken om je problemen op te lossen. Als het probleem niet op te lossen is met Selenium, probeer dat dan ook niet. Analyseer het probleem, en pak daarna een tool die er geschikt voor is. Immers, als je super goed kan hameren, maar er moet een schroef in een plank gedraaid worden, ram je niet die schroef erin. Je pakt een schroevendraaier,als het goed is.

Heb je zelf ook dergelijke vraagstukken, of wil je eens sparren over Automation in Testing? Kom gerust eens langs bij ons in Nieuwegein en laten we met z’n allen naar je problemen kijken, en bepalen hoe Automation je Tests verder kunnen helpen!