Leuk! Ik krijg tijd om tussen mijn opdrachten in wat technische skills bij te schaven en voor mij nieuwe test automatiseringstools uit te proberen. Maar dan de vraag, waar te beginnen? Want met blogs als deze, deze cursus portals, en deze podcasts slaat de keuzestress al snel toe. Mijn valkuil is ook nog eens dat ik alles leuk en interessant vind!

In deze blog geef ik je inzicht, hoe ik uiteindelijk het idee kreeg mijn tijd nuttig en leuk te besteden en hoe ik in korte tijd veel heb bijgeleerd. Hopelijk een inspiratiebron voor jou als lezer. Als bonus heb ik verderop nog een link geplaatst naar mijn GitHub project met een Demo Web UI, die je gratis kunt gebruiken om te experimenteren met de test tools, die jij jezelf eigen wilt maken.

Kies iets nieuws wat aansluit bij het voor jou bekende

Omdat ik mij de afgelopen jaren vooral in de wondere wereld van back-end services, databases en API’s heb mogen begeven, had ik mij bedacht om front-end zaken eens meer te belichten. Dus focus op test automatisering van gebruiker interfaces (UI’s) en vanuit daar maar verder kijken.

Vol enthousiasme ben ik begonnen met Robot Framework, eerst in combinatie met API’s – immers leer ik zaken sneller als er ook een bekende factor in zit – en dus later al snel ook met UI testen, met behulp van de Selenium Library voor Robot Framework.

Kijk een stapje verder dan de default tutorials

In mijn laatste project bij de klant had een collega mijn Postman/Newman regressie testen, die ik lang geleden in een Jenkins pipeline had gehangen, vanwege bedrijfsrichtlijnen recent gemigreerd naar AzureDevOps. Ik was dus al bekend met de AzureDevOps omgeving, maar gezien ik van mening ben dat het voor het succes van testautomatisering essentieel is om alles zo snel mogelijk in een pipeline te hangen, ben ik ook hier maar eens mee aan de slag gegaan. Dit bleek snel gepiept met hulp van deze blog.

Voordelen van Continuous Integration vanuit test perspectief

Voor leken, die minder ervaren zijn met test automatisering, draaien in een CI/CD pipeline: verdiep je snel in de materie! Want het heeft zoveel fijne voordelen om enerzijds je testen niet meer handmatig af te hoeven trappen (wat op de lange termijn toch echt een hoop tijd bespaart), maar anderzijds ook om er achter te komen hoe robuust je testen nou eigenlijk echt zijn. Zo draaien testen op zo’n virtuele/cloud machine vaak toch net iets anders, waardoor je feedback krijgt die je anders over het hoofd zou zien. Om een paar voorbeelden te noemen… Toen ik mijn eerste testen van onze Newspark website in AzureDevOps aftrapte kwam ik er achter dat wanneer de resolutie van mijn scherm anders is, de cookie melding nog wel eens in de weg kan zitten, maar ook dat onze website responsive is en dus bepaalde menu buttons niet direct zichtbaar en dus klikbaar zijn (bij een te smal scherm). Waaruit dus nieuwe test scenario’s ontstonden. Een derde reden om het snel te regelen, is direct hieraan gerelateerd. Het voorkomt dat, wanneer je al heel veel regressie testen hebt gemaakt en het dan pas in een geautomatiseerde pipeline gaat hangen, ineens verrast kan worden met een hele berg aan refactor werk. Zie daar dan nog maar eens prioriteit/tijd voor te krijgen van je product owner.

Volg je nieuwsgierigheid

Na Robot Framework en een AzureDevOps uitstapje, was ik toch wel benieuwd of ik mijn locators strategie kon verbeteren, en mijn verwachting werd overtroffen met de ‘Web Element Locator Strategies’ course van de Test Automation University. Door mijn gebrek aan gedegen basis kennis op dit vlak was ik vol enthousiasme begonnen met Xpaths, maar deze cursus wees mij toch wel op de keiharde feiten dat ID, name en class locators gevolgd door andere CSS-selectors toch veel leesbaarder en gemakkelijker onderhoudbaar zijn (in je test framework) dan de Xpaths die je dus eigenlijk pas beter kan gebruiken bij gebrek aan bovengenoemde mogelijkheden. Voor mij een waardevolle eye opener.

Wees niet te bang om je originele studie plan los te laten

Mijn volgende stap was Cypress (gebaseerd op mijn nieuwsgierigheid naar tooling die de Selenium basis omzeilen). Echter ben ik daar al snel van af gestapt. Want zo agile als we zijn, pas ook ik mijn leertraject aan op basis van nieuwe inzichten. Zo belandde ik per toeval op een super interessante Meetup van Agile Test Automation Meetup VIENNA groep over Playwright. Ik heb de indruk dat deze tool nog wel eens een groot succes kan worden. In mijn ogen een gedegen concurrent van tools als Selenium Webdriver en Cypress. De Meetup gaf inzicht in de vele eenvoudige mogelijkheden, maar bovenal ook de goede/efficiënte performance en stabiliteit ten opzichten van de gevestigde tools.  En dat is geen onbelangrijke factor voor het succes van test automatisering (zie ook de S van ‘Speedy’ in het TRIMS model, wat ik al aanhaalde in een van mijn eerdere blogs. Een hogere snelheid betekend namelijk sneller feedback, maar ook gewoon minder frustraties. Ook bij jou als tester als je je scripts wil proefdraaien na bepaalde wijzigingen, om te zien of alles werkt.

Bouw je kennis met logische stappen uit

Vanwege mijn interesse naar Cypress was ik dus al begonnen met een opfris cursus javascript, in mijn geval een opfrisser, gezien ik met Postman ook al vrij diep in de javascript zat. En gelukkig was het alternatief Playwright ook nog steeds gericht op javascript (hoewel het ook andere talen ondersteunt), dus kon ik deze cursus met de juiste motivatie eenvoudig afronden. Deze javascript cursus wakkerde mij weer aan om zelf een simpele interactieve web interface te bouwen die ik dan weer met mijn testtools kan bedienen (de statistieken van de Newspark website bezoekers werden inmiddels namelijk vervuild, zo lijken de VM’s van AzureDevOps als unieke bezoekers te worden herkend… oeps). Een mooie reden en gelegenheid om mijn geleerde javascript skills in de praktijk te oefenen. Voor mij werkt het namelijk het beste als ik na een cursus nog even iets langer met de materie oefen. En omdat mij opviel als je googled op ‘A website to test your automation tool’ of iets vergelijkbaars, dat hier eigenlijk weinig bruikbare resultaten op komen, stel ik bij deze de crappy website ter beschikking. Ik heb deze bewust vol met bugs gelaten, dus probeer ze allemaal te vinden.

Na wat eerste testjes te hebben neer gezet met Playwrigth, werd het weer tijd om mijn skills wat verder bij te schaven. Gegeven het feit dat Playwright mooie mogelijkheden biedt met javascript en Mocha, werd dit mijn volgende cursus. Hoewel ik na afloop en spelenderwijs uiteindelijk tot de conclusie ben gekomen dat ik niet zo’n grootte fan van Mocha ben. Want initieel wou ik meer weten over de before and beforeEach statements, maar uiteindelijk gebruik ik de vergelijkbare mogelijkheden van de ‘@cucumber/cucumber’ library, gecombineerd met de assertions van de BDD ‘Chai’ library. Maar dat komt wellicht omdat ik die Chai library al zo’n 2,5 jaar gebruikte binnen Postman. Dus dat is meer een persoonlijke voorkeur.

Het feit dat ik op deze ‘@cucumber/cucumber’ library uitkwam, had weer te maken met deze blog waar ik al snel op uit kwam omdat mijn eerste struikelblok met Playwright was dat ik viel over de maintainability en schaalbaarheid van de testen.

Google, Artikelen, Intakes en Meetups

Naast bovengenoemde zaken heb ik uiteraard ook vele uitstapjes gemaakt naar Google, en diverse artikelen gelezen, die stuk voor stuk weer voor nieuwe inspiratie zorgde. Zo was ik eerlijk gezegd nog niet heel erg bekend met het Page Object Model (hier uitgelegd aan de hand van Selenium), maar gezien ik dat op intakes ook voorbij hoorde komen heb ik daar inmiddels veel over gelezen. Inmiddels ben ik er inderdaad van overtuigd dat dit voor de onderhoud- en leesbaarheid van je code zeker ook een hoop meerwaarde gaat opleveren en dus ook toepasbaar is voor niet-Selenium toepassingen als Playwright.

Conclusie

Wat werkte er nou goed voor mij om in korte tijd veel bij te leren: Kies een sub focus (in mijn geval dus Web interface testing), Volg je interesse, enthousiasme en nieuwsgierigheid, maak verdiepingsslagen met het gene wat je al geleerd hebt, pas het toe, breid uit met kleine stapjes, maak verbeterslagen op basis van je huidige kennis en volg tutorials en/of google voor aanvullingen. En mocht je er dan nog niet uitkomen kan je natuurlijk altijd een beroep doen op onze Newspark Knowledge Squad!