Auteur: Maurice Siteur ● msiteur@casema.nl
Redactie: Kimberly Snoyl & Paul Beving
Inmiddels ben ik 37 jaar actief in de IT. Van programmeur tot van alles met de nadruk op testen. Ik ben een tester in hart en nieren en al sinds het begin lid van TestNet. Daarnaast heb ik diverse boeken over testautomatisering geschreven – boeken die het hele spectrum van testautomatisering dekken. Samen met mijn collega Paul Hofstee heb ik een white paper over testen binnen een low code omgeving geschreven. In ons geval is de ervaring afkomstig met Mendix applicaties. Hierbij geef ik een samenvatting waar ik een persoonlijke noot aan heb toegevoegd.
Om te beginnen een definitie van low code
Low code is een ontwikkelplatform waarbij gebruik wordt gemaakt van visuele componenten om de applicatie te bouwen en veel minder van code. Hierdoor kunnen applicaties veel sneller ontwikkeld worden.
Mendix, Outsystems, Betty Blocks, Usoft zijn low code ontwikkelomgevingen.
SAP en Salesforce zijn geen lowcode platforms maar configureerbare standaardapplicaties.
Wat is er specifiek aan het testen van low code applicaties?
Mijn zwart-wit antwoord is dat er geen verschillen zijn, maar er is wel degelijk een aantal punten waar je als tester rekening mee moet houden.
Visual programming is de kern van low code. Er wordt gebruikgemaakt van flows (denk aan action diagrams en flow charts). Die flows maken pair programming eenvoudig te doen voor testers.
Binnen Mendix heten dit ‘Microflows’ en binnen Outsystems ‘UI en Proces flows’. Deze flows worden aan een unit/componenttest onderworpen en hiervoor is soms ook aparte tooling beschikbaar.
Het traditionele unittesten wordt vervangen door het testen van componenten/flows. Unittesten is al niet populair bij programmeurs, bij modelleurs is dat nog minder populair, zou ik zeggen.
Alleen de flows lenen zich wel goed om die apart te testen; dus probeer als tester de modelleurs wel zover te krijgen.
De data liggen vast in een domeinmodel – dit is een laag boven op de database.
Autorisatie is bij Mendix op meerdere niveaus geïmplementeerd en vergt daarom meer testinspanning.
Het framework in de cloud dekt een aantal bekende securityproblemen al af. Deze hoeven dus niet meer uitgebreid getest te worden door een ethical hacker.
Uiteindelijk gaat het om het maken van werkbare software voor de eindgebruiker. Dat is voor elke omgeving gelijk.
Dus als het complex wordt, dan is er ook meer testwerk. Je kunt je hier zelfs afvragen of Mendix hier wel geschikt voor is. Experts die weten wat de low code omgeving kan, zijn nodig als het complexer wordt. Hier zie je een onderscheid ontstaan tussen de modelleur die de low code omgeving kan bedienen en de programmeur die snapt hoe de omgeving werkt. En helaas zijn de modelleurs aan de overhand.
Data blijven de kern van je systeem. Ik zie dat de kennis van de database beperkt is bij iedereen, terwijl die kennis bij echte verwerkingen keihard nodig is. Het domeinmodel zegt niet alles en zeker niet bij Mendix, waar een flexibele manier van werken ervoor gezorgd heeft dat er altijd tussentabellen zijn in de database – ga maar vast je innerjoin kennis oppoetsen.
Een veelgehoorde marketing slogan is dat low code snel applicaties oplevert. Mijn ervaring is dat low code geen garantie biedt voor snellere en onderhoudbare systeemontwikkeling. Mijn overtuiging is het dat je met elke taal snel kunt zijn – de kwaliteit van de programmeur/modelleur is hierbij van cruciaal belang.
Testautomatisering bij low code
Testautomatisering is niet meer weg te denken uit onze Agile manier van werken – daily builds en dergelijke. Daarom volgt hieronder een overzicht van een aantal mogelijke tools.
- Op Selenium gebaseerde tools, zoals
- ATS voor GUI (Mendix specifieke tool)
- Leapwork (low code testtool)
- Robot framework
- Web-testen middels Selenium of Playwright
- Webservices (SOAP en/of REST)
- Integraties (verscheidene library mogelijkheden)
- Menditect – Mendix tool om met microflows scenario’s te maken en de UI te omzeilen
- ReadyAPI/SoapUI, RestAssured voor het testen van webservices.
- APM performance tool (Mendix)
- AQM code kwaliteit tool (Mendix)
- Testar webcrawler om robuustheid te testen, soort monkeytest.
PS: Tools worden ook op andere manieren ingezet – bij API en unittests bijvoorbeeld. Hier hanteren we de kernfunctionaliteit van de tools.
Mijn eigen voorkeur zijn de low code tools, want ik houd niet van de eclipse-achtige manier van werken. Vanuit mijn ervaring met tal van andere projecten weet ik dat de omgeving het type tool bepaalt en niet ik.
Concluderend kun je zeggen dat low code testen anders is, maar een beetje tester past zich hier probleemloos aan.