Testen van Mendix: hoe behoud je de snelheid?

In deze blog neem ik jullie mee in onze ervaring in het opzetten en doorvoeren van een teststrategie van een Mendix portaal. Een belangrijk portaal voor de self-servicing van hypotheken voor honderdduizenden consumenten.

MINIMAL VIABLE PRODUCT ONTWIKKELD

De eerste fase van het project was het ontwikkelen van een Minimal Viable Product (MVP). Doel van deze fase is kijken of de techniek geschikt is voor het bouwen van een compleet portaal. We hebben hierbij ook een ‘pilot’ gedaan van de teststrategie: is het mogelijk om met een Java Selenium platform alle functionele testen te automatiseren?

Op basis van het MVP viel het besluit om door te gaan met de ontwikkeling in Mendix. Wij testers waren echter nog niet zo enthousiast. Technisch gezien was het automatiseren van tests via Selenium niet zo’n probleem. De doorlooptijd voor het handmatig testen en automatiseren van de testen was wel een probleem. En dus lag er voor de testers een uitdaging: een manier vinden om de functionaliteit te testen die aansluit bij de ontwikkelsnelheid in Mendix, zonder in te leveren op kwaliteit.

TESTAUTOMATISERING PIRAMIDE ALS LEIDRAAD

De route die we daarvoor hebben gekozen is de testautomatisering piramide. Hiermee bepaal je de verhouding van onder andere je geautomatiseerde unit-testen, API-testen, integratietesten, GUI-testen en handmatige testen.

Het uitganspunt van de piramide is om de bulk van de testen automatisch en zo vroeg mogelijk uit te voeren. Dit zorgt voor korte feedback loops voor ontwikkelaars en minder onderhoud aan complexe frond-end testen. Maar niet alle testen kun je of moet je automatiseren. Er blijft altijd noodzaak om handmatige testen uit te voeren!

TESTERS EN ONTWIKKELAARS WERKEN SAMEN

Je vraagt je misschien af: hoe meten jullie de klanttevredenheid en medewerkertevredenheid als je geen gestandaardiseerde vragenlijsten meer gebruikt? Je hebt dan immers geen objectief vergelijkingsmateriaal. Je kunt niet meer roepen dat de klanttevredenheid is gestegen van een 8 naar een 8,5.

In ons project was het essentieel om een manier te vinden om de Mendix code te kunnen unit testen. Hiervoor was de standaard unit test module in Mendix de oplossing. Met behulp van deze module kunnen Mendix-ontwikkelaars zelf testen maken voor al hun gemaakte (sub)microflows en integraties . Per story worden de functionele testen zoveel mogelijk opgenomen in de unit testen. Dit betekent dat ontwikkelaars en testers moeten samenwerken om ervoor te zorgen dat de juiste scenario’s in de unit test terugkomen. Hierbij hebben we een verschil gemaakt tussen unit testen die een hele kleine unit code testen (bijvoorbeeld één veldvalidatie) en de unit testen die een hele flow testen (het inloggen). Deze testen representeren de eerste twee lagen uit de piramide

Na een geslaagde unit test kan de tester zich richten op het zoeken naar de potentiële problemen in de gehele keten en het testen van de functionaliteit via de front-end. Dit is bij ons de functionele handmatige test ofwel het bovenste wolkje in de piramide. Hierbij kan de tester ook bepalen of de applicatie visueel goed werkt.

Als laatste stap in ons testproces maakt de tester (of ontwikkelaar) automatische regressietesten voor de story. Dit doen we in een Java en Selenium Webdriver framework. Doel van de regressie is het testen van de gehele flow van een story en het testen van onderdelen die de unit test niet afdekt (zoals het tonen van de juiste waardes op het scherm). Wanneer automatiseren te tijdrovend of complex is, voegen we de testen toe aan een handmatig regressiescript.

Voor elke user story voeren we bovenstaande stappen uit. Daarbij bepalen per story wat de risico’s zijn en welke testen noodzakelijk zijn. Uiteindelijk is het doel om ervoor te zorgen dat we door middel van een combinatie van unit en automatische regressietesten een volledige testdekking hebben.

HET RESULTAAT: BETERE BALANS TUSSEN ONTWIKKELEN EN TESTEN

Tijdens de ontwikkeling van de pilot was testen een bottleneck. Daarnaast bleek dat ontwikkelaars van Mendix een dusdanige focus op snelheid en leveren hebben, dat ze niet bezig zijn met testen en kwaliteit. Door het verplaatsen van de bulk van het testwerk naar unit testen en deze door ontwikkelaars en testers samen te laten uitvoeren, hebben we een veel betere balans gecreëerd. De ontwikkelaars zijn meer betrokken en verantwoordelijk voor kwaliteit en leveren daardoor betere software. Voor de testers is er minder handmatig testwerk. Daardoor hebben ze meer tijd voor het testen van de grootste risico’s en het maken van automatische regressietesten. Om de focus en complexiteit verder te verlagen, hebben we specifieke testwerkzaamheden, zoals de performance en security, extern belegd.

Naast de betere balans en focus is er nu een constante controle op alle functionaliteit. Op basis van de piramide is een continuous delivery omgeving ingericht. Na elke build voeren we honderden automatische unit testen en functionele testen uit. Inclusief de handmatige regressie is de doorlooptijd beperkt tot uren in plaats van dagen.

Met deze strategie hebben we naar volle tevredenheid van de teams en de klant een proces neergezet dat garandeert dat de snelheid van ontwikkelen met Mendix niet verloren gaat. Daarnaast hebben we aangetoond dat ook in de wereld van snel, sneller, snelst het nog steeds goed mogelijk is om de kwaliteit te waarborgen en garanderen. Dit vergt echter wel de nodige aanpassingen in werkwijze en denkwijze. Niet alleen van testers, maar ook van ontwikkelaars, product owners en organisaties.