Blog:

De eerste weken als ‘Testable’ bij Fourtress

Published on okt 10, 2019
By Patrick / Software Developer

“Testen is essentieel voor hoge kwaliteit!”, “Testen is leuk en uitdagend!”, “Test automation is eigenlijk net als programmeren!”. Allemaal uitspraken die je als developer vast al eens hebt gehoord om je te overtuigen dat testen leuk en belangrijk is. Hoewel ik het persoonlijk helemaal eens ben met deze uitspraken (duh, ik ben software tester) heb ik gemerkt dat deze uitspraken de boodschap niet altijd overbrengen. In deze blog ga ik dat dan ook op een andere manier proberen; namelijk door wat te vertellen over mijn activiteiten als ‘Testable’.

Nou vraag je je misschien direct af; wat is een testable? ‘The Testables’ is een team binnen de Test Guild van Fourtress dat zich bezighoudt met het ondersteunen van interne projecten op het gebied van testing en kwaliteitsbewaking. Daarmee wordt een standaard gecreëerd die voor meerdere projecten gebruikt wordt. Zo werken de testables momenteel samen met een development team aan onder andere statische code analyse met SonarQube, Jenkins en dashboarding om zo kwaliteit inzichtelijk te maken. Met mijn achtergrond in software testing was ik natuurlijk een perfecte kandidaat voor dit team.

Op mijn eerste officiële werkdag werd ik al snel op de hoogte gebracht van de zogenoemde Testables poster. Deze poster, gebaseerd op een poster van The Expandables, weerspiegelt de rol van het team op een grappige manier: een groep huurlingen die ondersteunen waar nodig.

Test Automation Learning Path  

Fourtress heeft learning paths voor diverse onderwerpen en technieken opgesteld. Deze learning paths dienen als gestructureerd training programma. Hoewel er reeds een learning path voor software testing was, ontbrak er nog een specifiek path voor test automation. Tijdens de eerste weken heb ik me dan ook beziggehouden met het opzetten en volgen van dit learning path. Dit learning path focust zich op onderwerpen zoals UI-testing, behaviour-driven development en static code analysis met SonarQube, maar ook op DevOps gerelateerde onderwerpen zoals Docker en Jenkins.

Integration testing 

Na het learning path heb ik me gestort op het automatiseren van integratietesten voor een intern Fourtress project. Hierbij ben ik aan de slag gegaan met de door manuele testers opgestelde testscenario’s. Deze scenario’s zijn opgesteld volgens de Gherkin syntax en volgen een given-when-then structuur. (Meer info over Gherkin) Het voordeel van de Gherkin syntax is dat de scenario’s erg leesbaar zijn voor zowel business als development. Een voorbeeld van zo’n testscenario:

Grofweg bestaat het automatiseren van een dergelijk scenario uit drie onderdelen: het klaarmaken van de testomgeving (Given), het uitvoeren van een actie (When) en het controleren van het gedrag van de applicatie tijdens/na het uitvoeren van de actie (Then). De uitdaging zit hem daarbij voornamelijk in het klaarmaken van de testomgeving. Het aanmaken van de benodigde testobjecten, het ‘wegmocken’ van afhankelijkheden en het opstellen van custom configuratie die gebruikt wordt binnen de testomgeving. Mocht je niet weten wat mocken inhoudt, hier een korte uitleg.

Om een voorbeeld van het huidige project aan te halen: hieronder een deel van het (versimpelde) architectuur diagram. Het doel is om de API van de Administration Microservice te testen. De Administration Microservice is verantwoordelijk voor het beheren van werknemers. Deze service heeft een afhankelijkheid op de UAA Service. De data van een werknemer wordt namelijk deels opgeslagen in de UAA Service. De afweging moet dus worden gemaakt om ofwel de UAA Service te laten draaien tijdens het uitvoeren van de tests, ofwel de UAA Service te mocken. Beide opties hebben zijn voor- en nadelen.

Continuous Integration 

Bij het automatiseren hoort, naast het ontwikkelen van de testscripten, ook een stukje continuous integration. Om maximaal profijt te hebben van de integratietesten en zo de kwaliteit van de software goed in de gaten te kunnen houden heb ik gezorgd dat de testen bij elke bouwpoging worden uitgevoerd op de Jenkins bouwserver. Als een integratietest faalt zit er dus een bug in de code en is de bouwpoging mislukt. Het is dan aan de developers om deze bug te vinden en te herstellen. Zodra alle bugs hersteld zijn en de alle testen slagen kan er vervolgens met meer vertrouwen een nieuwe versie van de software worden uitgebracht.

Na deze eerste weken kan ik met zekerheid zeggen dat ik de goede keuze heb gemaakt om als Test Engineer aan de slag te gaan. Het is de combinatie van onderzoek, programmeren en DevOps werkzaamheden die test automation voor mij zo leuk en interessant maken. Daarnaast voel ik me een onmisbare schakel in het proces van kwaliteitsbewaking.

Ik hoop jullie door middel van deze blog een beeld te hebben gegeven van mijn werkzaamheden. Heb ik hiermee nou ook jouw interesse gewekt? Praten over test automation doe ik graag, dus aarzel dan ook niet om me te benaderen.