Steeds meer organisaties overwegen hun kernprocessen met low-code-software te ondersteunen. De kwaliteit en robuustheid van deze applicaties moeten hierdoor op een hoger plan komen te liggen. In deze blogserie ga ik in op diverse kwaliteitsaspecten die low-code nodig heeft in dit soort toepassingen. Allereerst, testen. Ik bespreek vier niveaus van kwaliteitscontrole en hoe deze worden toegepast in low-code- en prescriptive low-code-platformen.
1. Unittesten van bouwstenen
2. Modelverificatie
Dit eerste niveau in de kwaliteitscontrole is in veel platformen uitgebreid met zogenaamd ‘Ai assisted development’ (ai: artificiële intelligentie). De bouwer van een applicatie krijgt voortdurend informatie waar zich precies fouten bevinden in een model en hoe deze te verhelpen. Deze feedback is gebaseerd op een technische modelverificatie. Er vinden geautomatiseerd checks plaats variërend van validatieregels tot ‘mogelijke fouten’ op basis van een wiskundig model. Na deze controle kan de bouwer ervan uitgaan dat er geen technische problemen te verwachten zijn in de manier waarop hij of zij de gevalideerde bouwstenen heeft toegepast.
De context van een goed gevalideerd model biedt ook de tester veel meer validatiemogelijkheden dan bij het schrijven van regels softwarecode. Dit tweede niveau van kwaliteitscontrole, waarbij vastgesteld wordt of alle eigenschappen van de bouwsteen technisch correct zijn gebruikt, voorkomt fouten met invoervelden of ongeoorloofde toegang tot systeemgeheugen. Het hogere abstractieniveau van low-code legt hiermee ogenschijnlijk een prima basis waarop een veel grotere groep low-code-developers applicaties kan bouwen. Maar de kwaliteitscontrole heeft meer diepgang nodig als het om applicaties gaat die kernprocessen moeten ondersteunen.
3. Functioneel testen
Naast verificatie van het model moet bij het bouwen en aanpassen van een applicatie ook de functionaliteit gevalideerd worden. In dit derde niveau van de kwaliteitscontrole vindt een check plaats of de wijziging de verwachte uitkomst heeft. Dit functioneel testen gebeurt nu vaak met de hand of door een testscript te maken dat zoveel mogelijk handelingen bij het functioneel testen automatiseert. Bij elke aanpassing aan de applicatie dient het testscript ook aangepast te worden. In veel traditionele low-code- platformen is deze validatie van de functionaliteit tijdrovend.
4. Integratie en regressietest
Een aanpassing van de software kan een onverwachte uitwerking hebben op andere delen van de applicatie. In een integratie of regressietest vindt de controle plaats of alle onderdelen van een systeem nog correct functioneren na het doorvoeren van een wijziging. In dit vierde niveau van kwaliteitscontrole wordt een verzameling van eerder gemaakte regressietesten op de gehele applicatie uitgevoerd.
Ook de nieuwe of gewijzigde onderdelen van de applicatie worden getest. Bij de oplevering wordt dit testonderdeel toegevoegd aan de bestaande verzameling regressietesten. Er is een voorkeur om een regressietest tot in hoge mate te automatiseren, omdat het testen onder tijdsdruk staat en automatisering mogelijke fouten bij het testen minimaliseert. Het aanpassen van het script om ook de uitbreiding in de regressietest mee te krijgen blijft handwerk.
Veel handwerk
De meeste low-code-platformen hebben weinig tot geen voorzieningen om dit derde en vierde niveau van kwaliteitscontrole adequaat te faciliteren. Als in een testscenario een groot aantal aaneengeschakelde processen functioneel getest moeten worden, dan wordt het steeds lastiger om het risico op onbedoelde fouten bij updates te minimaliseren.
Dit is ook wat Forrester constateert in het rapport ‘We must address testing in low-code-development’. In het rapport stelt het onderzoeksbureau vast dat het functioneel testen van low-code-applicaties momenteel nog grotendeels handwerk is.
Automatiseren ketentesten
Het handmatig aanbrengen van wijzigingen in het testscript gaat nog bij een kleinere toepassing, maar wordt ondoenlijk als het om een omvangrijke applicatie gaat. Deze aanpak is te bewerkelijk en foutgevoelig als er grote stukken functionaliteit in de steigers hebben gestaan en brengt teveel risico’s met zich mee voor de ondersteuning van primaire processen.
In een zogenaamd prescriptive low-code-platform is deze functionele validatie veel grondiger uit te voeren en te automatiseren, omdat modellen worden hergebruikt en onderhouden, en deze modellen worden voorzien van de bijbehorende testinstructies en use-cases. Daarmee bevat het model zelf informatie over een correcte functionele werking. Functies in het model krijgen expliciet informatie mee over hoe deze functionaliteit gebruikt dient te worden (use case) en welke processtappen bij het uitvoeren van de functie betrokken zijn om een goede werking te waarborgen.
Testinstructies in het model
Doordat een applicatie wordt samengesteld uit deze modellen, worden de testinstructies en use cases samengevoegd, waardoor ook de testcases herbruikbaar worden. Deze extra dimensie in het model zorgt ervoor dat deze nieuwe generatie, prescriptive low-code-platformen adequate handvaten bieden om het functioneel testen op een hoger plan te brengen.
Doordat het applicatiemodel informatie bevat over een correcte functionele werking van de software kan bij aanpassingen een testscenario voor een integratie- of regressietest automatisch afgeleid en gegenereerd worden. Dat is van onmisbare waarde als in een testscenario een groot aantal aaneengeschakelde processen functioneel getest moeten worden onder tijdsdruk. In zo’n testscenario is op basis van logbestanden extra aandacht te besteden aan veel gebruikte klikpaden in de applicatie om risico’s van aanpassingen verder te verkleinen.
Deze representatieve aanpak verkleint het risico op defecten verder door veel gebruikte onderdelen in de applicatie bovengemiddeld te controleren. En hier biedt ook modern testgereedschap dat in veel devops-omgevingen opgenomen is, uitkomst. Door bij het testen Selenium in te zetten zijn commando’s naar de browser te sturen waarmee gebruikersinteracties als muisklikken of toetsaanslagen te simuleren zijn. Met dit soort gereedschap is ook bedrijfslogica voor zeer complexe scenario’s door te testen mits het model voorzien is van de juiste use cases en processtappen. Deze testaanpak zorgt ervoor dat de risico’s van kleine functionele aanpassingen aan omvangrijke bedrijfskritische applicaties binnen de perken blijven.
Beheersen flexibiliteit
Testen krijgt nog een belangrijker rol en moet nog fundamenteler aangepakt worden als er naast de standaard bouwstenen ook custom-code aan de low-code-applicatie wordt toegevoegd. Bijna alle low-code-platformen hebben de mogelijkheid om containers met custom code toe te voegen aan een applicatie. Het toevoegen van custom-code maakt low-code-platformen op het eerste gezicht flexibel. Deze ogenschijnlijke souplesse, zorgt ervoor dat tijdens de gehele levenscyclus van de applicatie deze functionaliteit geunit-test moet worden.
Deze keerzijde aan de flexibiliteit van low-code-platformen zien heel wat gebruikers over het hoofd zo waarschuwt Forrester in het eerdergenoemde rapport over het testen van low-code applicaties. Veel fouten ontstaan in een complexe situatie als ontwikkelaars niet meer weten welke bouwstenen wel en welke niet gevalideerd zijn. Met low-code-tooling gegenereerde applicaties zijn hier bepaald geen uitzondering op.
Custom-code regisseren
Dit is een belangrijke reden om het gebruik van custom-code in low-code-applicaties beter te regisseren. Als de standaard bouwstenen niet toereikend zijn, leidt gelaagde ontwikkeling op basis van een consequent afgedwongen applicatie architectuur in een prescriptive low-code-platform tot een meer solide aanpak. De leverancier van zo’n platform kan pro-code-ontwikkelaars via een integratie in een traditionele IDE-omgeving als Microsoft Visual Studio een plug-in laten ontwikkelen.
Hiermee wordt de inzet van een bouwsteen met nieuwe functionaliteit mogelijk en beschikbaar gesteld voor ‘citizen developers’ in het platform. In zo’n gelaagde aanpak zijn nieuwe bouwstenen op een gestandaardiseerde manier toe te voegen aan het platform. Nieuwe bouwstenen gaan vervolgens mee in het gestandaardiseerde verificatie- en validatieproces.
Geautomatiseerd testen is haalbaar
Niet alle low-code-platformen pakken het testen grondig genoeg aan, terwijl ook bij low-code- softwareontwikkeling het testen een essentiële kwaliteitscontrole is die op meerdere niveaus plaats moet vinden. Naarmate de projecten groter en belangrijker worden, wordt het testen essentieel maar ook ingewikkelder en daarmee tijdrovender. Het testen kan alleen systematisch uitgevoerd worden als het platform hiervoor de juiste voorzieningen heeft.
Prescriptive low-code-platformen gaan hierbij verder dan reguliere low-code-platformen, omdat procesinformatie onderdeel is van het model. Dit maakt het mogelijk om het testproces tot in hoge mate te automatiseren, zodat naast verificatie van bouwstenen en validatie van use cases ook bij integratie van wijzigingen regressietesten en complexe scenariotesten een haalbare kaart zijn en blijven.
