Tijdens de interessante deepdive sessie op vrijdag 4 februari stond architectuur in een testframework op het programma. Met een ruime opkomst van zowel externen als collega’s van Newspark behandelden we architectuurkeuzes in een testframework bij onze opdrachten. Omwille van de bedrijfsgevoeligheid van de verschillende frameworks, gaan we in deze blog niet in op details. Wel geven we je graag een aantal algemene tips die hoogstwaarschijnlijk ook jou kunnen helpen.

De opzet van een testframework

We lieten elkaar zien hoe de opzet van het testframework gedaan was. Bij de uitleg van die opzet triggerden we elkaar met doortastende vragen over de verschillende gemaakte keuzes. Gedurende de diverse interacties ontstond een discussie waar je nu de step definitions plaatst. Gebruik je per feature file een step definition file of juist per scherm of kies je voor 1 grote file waardoor alles steps makkelijk te vinden zijn?
Het antwoord bleek erg afhankelijk van het project en van wat de mensen fijn vinden om mee te werken.

Het aantal step definition files

Bij een erg groot project, waaraan veel testers werken, is het lastig en onoverzichtelijk om 1 grote step definition file te gebruiken. Het komt dan al snel voor dat het onduidelijk is welke step bij welke pagina hoort, waardoor duplicaten ontstaan. En als er wel hergebruik plaatsvindt, moet je heel goed opletten of een aanpassing aan een bestaande step definition niet een verkeerde invloed heeft op andere testen. Bovendien werkt in een groot project eenieder vaak maar aan een deel van het geheel. Het is dan logischer de step definitions op te delen in verschillende delen, bijv. de pagina’s waarop ze van toepassing zijn.
Is het daarentegen een klein project met max 2 of vooral maar 1 tester, dan heeft het gebruik van 1 step definition file ook voordelen. Dit voorkomt zoeken en zo is makkelijk veel hergebruik mogelijk.

Een kijkje in de keuken

Drie van onze collega’s gaven een kijkje in de keuken van hun testwerkzaamheden:

• Matthias toonde hoe hij de front-end bij de Rabobank met 1575 geautomatiseerde testen testte. 1 van de grote uitdagingen die hij ervaart, zijn de flaky testen. Door dit soort testen, die zo af en toe falen om moeilijk verklaarbare redenen, nog een 2^e en/of 3^e keer automatisch in de pipeline te laten draaien, krijgen ze toch dagelijks een goed beeld van de kwaliteit.
  Met deze grote aantallen testen, is het essentieel de rapportage goed op orde te hebben. Zonder een goede rapportage worden falende testen al snel genegeerd of zelfs uitgesloten.
• Tobias toonde hoe hij de Donna applicatie geautomatiseerd test. Middels Donna kan de NS alle treinen op de sporen plannen en daarmee dus ook “het spoorboekje” maken. Een zeer uitgebreide eigen ontwikkelde applicatie die voor hele andere testuitdagingen zorgt. Dit is niet een website die met selenium is te testen. Het is een applicatie die bestaat uit meerdere “blokken”, ook wel frames genaamd. In de testautomatisering moet je erg goed rekening houden met de selectie van het juiste frame alvorens je bijv. een veld selecteert om te vullen.
• André lichtte zijn test framework bij Roxit toe. Hij test een systeem waarmee de Gemeentes en handhavende/ondersteunende instanties vergunningaanvragen behandelen. Een van de uitdagingen is het hergebruik van steps en dus het voorkomen van duplicaten. Daarnaast heeft hij de uitdaging van een Engels georiënteerd test framework voor het testen van een Nederlandse applicatie. Conclusie: ben heel consequent in het gebruik van de taal van bijv. variabelen.

 

Essentiële keuzes

Verder bespraken we het page object model. Cucumber projecten beginnen vaak met alleen de feature files en de step definition files. Maar vaak wordt al snel duidelijk dat zogenaamde “helper files” met veelgebruikte functies, alsmede “page object files” voor alle acties op objecten op een page, essentieel zijn voor een goede implementatie. Zo breng je structuur aan en stimuleer je hergebruik.

Een andere overweging is het gebruik van meerdere repositories. In een microservices architectuur is het verstandig om per microservice een repository te gebruiken. Aangezien software development en het ontwikkelen van je testen hand in hand gaan, is het ook hier slim de software en de testen in eenzelfde repository op te slaan. Echter, met de systeemtesten, dus over meerdere microservices heen, kom je in de knoei, want in welke repository sla je die dan op. In dat geval is het beter een extra test repository te gebruiken voor deze systeem-overkoepelende testdocumenten.

Deze deepdive sessie wisselden we vooral de voors en tegens uit of gaven toelichting op de gemaakte keuzes. De uitkomst: per project en per situatie vooral goed overdenken wat de beste keuze is. Doorgaans is er niet 1 perfecte oplossing, one size does not fit all. Wij merkten dat iedereen tijdens deze deepdive zelf bepaalde welke tips in zijn situatie van toepassing waren en welke slimme keuzes in de toekomst nog te maken zijn.
Kortom: je had er bij moeten zijn.

De tips voor de opzet van een testframework nog even kort op een rij:

• Beslis wat een handige keuze is voor de verdeling van step definitions
• Overweeg op basis van de teamsamenstelling of het wel/niet handig is meerdere repo’s te gebruiken
• Gebruik het page object model
• Laat flaky testen automatisch opnieuw draaien in de pipeline
• Zorg voor een goede rapportage
• Wees consequent in het gebruik van Nederlands dan wel Engels voor bijv. variabelen

Op 4 maart is de volgende deepdive sessie en duiken we dieper in het performance testen als vervolg op een eerdere deepdive over performance testen. Deze keer gaan we ook zelf met de handen aan de knoppen.

Voor de deepdive sessies in april en mei staan nu 2 mogelijke onderwerpen:

1. Handvatten voor het goed opsplitsen van een userstory
2. Verwachtingsmanagement; hoe achterhaal je de verwachtingen van de manager en hoe pas je jouw gedrag of de verwachtingen aan indien nodig?

Welk onderwerp lijkt jou het meest interessant? Laat het weten via deepdive@newspark.nl en duik met ons mee in een van de volgende sessies!

Wellicht heb je ook interesse in een van onze vorige deepdive sessie over performance testen? Lees daarover hier meer.