Low-Code hoef je niet te testen. Toch?

No-code? Low-code? Citizen developers?

Maar laten we bij het begin beginnen. Bij nieuwe technologie krijg je altijd nieuwe terminologie cadeau. De belangrijkste termen leggen we hier kort uit.

• • • No-code is de term die we gebruiken voor het bouwen van applicaties in een grafische interface. Dus met ‘drag and drop’ en helemaal zonder code te hoeven schrijven.
    • Met low-code doelen we op een manier van software bouwen die ook grotendeels grafisch is, maar die de ruimte geeft om complexe logica vorm te geven in makkelijk te begrijpen scripts.
    • Citizen developers zijn mensen die aan de businesskant werken en dus ‘officieel’ geen developer zijn, maar die dankzij no-code en low-code zonder diepgaande technische kennis toch software kunnen bouwen. De klassieke high-code developer wordt, om het onderscheid te maken, vaak aangeduid met ‘full-stack developer’.
    • Power Platform is de low-code omgeving van Microsoft. Power Platform integreert naadloos met de andere onderdelen van de Microsoft cloud, zoals Teams, Office en Azure.

Toepassingen van low-code

De usecases voor low-code zijn zeer divers. En we ontdekken iedere dag nieuwe. Dit zijn een paar van de belangrijkste.

Apps voor mobiel en web

Een klantportaal of een mobiele communicatie-app voor frontline workers? Vaak zijn die veel sneller klaar als je ze niet in code bouwt.

Samenwerken

Stoppen met mailen en bellen, beginnen met echt samenwerken. Dat is de essentie van veel low-code apps. Gebruik de kracht van Power Platform om te zorgen dat documenten in de juiste mappen staan, dat deadline-reminders automatisch verstuurd worden en dat iedereen altijd de juiste informatie heeft.

Processen automatiseren

HR-processen zoals het invoeren en goedkeuren van vakantie-aanvragen of onkostendeclaraties, het verwerken van servicetickets of het versturen van maandelijkse rapportages: de meeste bedrijfsprocessen zijn met Power Platform niet alleen te bouwen, maar ook te verbeteren.

Data-integraties

Een grote kracht van Power Platform is het toegankelijk en bruikbaar maken van data. Door te werken met de standaard aangeboden connectoren, of met connectoren die speciaal voor jou gemaakt zijn, kunnen citizen developers heel snel aan het werk met je bestaande data.

Ruis op de lijn

Vaak leeft rondom low-code het idee dat testen niet nodig is. Je klikt een app bij elkaar en hop, het kan naar productie. Dat is, code, low-code of no-code, geen schaalbare, veilige en beheersbare manier van software ontwikkelen. Heb je een team van 20 testers nodig voor je low-code apps? Waarschijnlijk niet. Maar je moet wel serieus en bedrijfsbreed kijken naar wat er moet worden afgevinkt en afgevangen, voordat een Power Platform-toepassing je organisatie in mag. Je wilt tenslotte kwaliteit afleveren.

“Maar waarom bouw je het dan niet in één keer goed?” Het is een vraag die best vaak gesteld wordt. Logisch, want wij zijn softwaremakers en we vertellen graag dat we daar goed in zijn. Waarom moet ons werk dan getest worden? Met low-code geldt dat dubbel. Die software is in feite al half af voordat we beginnen, toch? Hoezo heb je dan testers nodig?

Het antwoord zit hem in communicatie. Een gebruiker moet een bouwer uitleggen wat een app moet doen. En op die lijn zit altijd ruis. Ook technische communicatie is communicatie tussen mensen. En mensen begrijpen elkaar soms verkeerd. Daarom maken we altijd goede afspraken om, als de bouw is, nog een keer met een frisse blik naar een app te kijken. Ook bij low-code.

Het Yin en Yang van software testen

Testers worden er vaak van beschuldigd dat ze alleen maar problemen zien, maar dat is eigenlijk niet hoe het werkt. Een softwaretester is vooral iemand die zich bij ieder stukje businesslogica afvraagt: “Wat betekent dat eigenlijk?” Het volledig doordenken van de functionaliteit van je app en uitwerken wat er nodig is om al je logica onder alle omstandigheden te laten werken, is een vak apart. Dus ja, een tester vindt dingen die mis zouden kunnen gaan. Dat is de negatieve kant. Aan de positieve kant: een tester zorgt voor kwaliteit. Jij maakt dingen. Een tester helpt je om het echt goed te maken. Dat schept vertrouwen in het product en zorgt voor een probleemloze uitrol en productief gebruik. Als het goed is, zijn deze twee dingen in balans. Een beetje als Yin en Yang.

Drie testfasen

Testen doen we op drie niveaus:

1. Requirements testen

Voor je aan het werk gaat, heb je een plan nodig. Ook bij low-code zijn goede requirements erg belangrijk. Wij laten in deze fase meteen een tester meekijken, want die is er goed in om gaten in requirements te zien die later voor problemen kunnen zorgen.

2. Integratie- en functionele testen

Het meest gedetailleerde, technische testniveau (de ‘unit test’) kunnen we bij low-code meestal overslaan. Maar het testen van functionaliteit van de app en integraties met andere systemen is natuurlijk wel belangrijk. Praten de modules met elkaar? Komt de data aan? Aannames doen op dit gebied is gevaarlijk en kan je in de volgende testronde, of in productie, serieuze problemen en vertragingen opleveren. Bij een functionele test gedraagt een tester zich als gebruiker en voert alle handelingen uit zoals ze in de requirements zijn uitgewerkt. Zo weten we of de app ook doet wat de gebruiker gevraagd heeft.

3. Gebruikerstest

In de laatste testronde mag de gebruiker dat zelf ook bekijken. Sla deze fase nooit over! Een gebruiker kijkt met een hele andere blik naar software dan wij IT’ers. Ze zullen dus zeker nog opmerkingen hebben.

Hoe meer gebruikers, hoe meer eisen

Een misvatting die we vaak horen is dat gebruikerstesten voor low-code genoeg zijn. Maar gebruikers testen software vanuit hun eigen perspectief en meestal niet erg systematisch. Dat betekent dat je gevaarlijke aannames uit het ontwikkelproces niet altijd boven water krijgt. Een gebruiker neemt bewust of onbewust aan dat een developer aan alles gedacht heeft. Maar ‘alles’ is, ook voor een ervaren developer, best veel en die aanname hoeft dus niet te kloppen. Low-code voedt dit soort aannames, omdat het ontwikkelproces minder technisch is en het dus makkelijk is om te veronderstellen dat ‘alles automatisch’ gaat.

Hoeveel testrondes je nodig hebt, hangt natuurlijk wel af van de complexiteit van de app en het aantal gebruikers. Heb je een appje voor jezelf gemaakt? Dan kun je inderdaad eens kritisch door je app heen klikken en constateren dat het aardig doet wat je wilt. Maar gaan meer gebruikers met de app werken, dan is er meer nodig. Zelfs een app die door 5 mensen gebruikt wordt, kan al verrassingen opleveren.

Hoe groter de app en hoe meer gebruikers, hoe groter de kans op onbedoelde effecten wordt. En hoe strenger je kwaliteitseisen dus moeten zijn. Daarnaast heb je ook andere zaken nodig, die je ongetwijfeld herkent uit full-stack ontwikkelprocessen: documentatie, handleidingen en governance-afspraken over naamgeving, rechten, toegang en het opruimen van data. Ook deployment- en updateprocessen moet je vastleggen als je een low-code app breed wilt gaan uitrollen.

Specifieke tests voor low-code

Het mooie van Power Platform is dat heel veel dingen al klaar zijn. Microsoft zorgt dat je app altijd start en dat de infrastructuur op orde is. Daar hoef je je niet druk over te maken. Standaardintegraties en connecties die je in je app hebt gebruikt zullen het ook gewoon doen.

Maar voor de toegankelijkheid van de data zijn de gebruikers zelf verantwoordelijk. Dat kan misgaan. Maar wat als je een team gebruikt in je app en dat team wordt verwijderd? Of als bepaalde mappen niet toegankelijk zijn? Dat zijn uitzonderingen die je moet testen. Ook verwerking en presentatie van de data moeten getest worden.

Bij low-code heb je meestal geen 100% beeld welke functionaliteit ondersteund wordt. Platformen veranderen nou eenmaal iedere dag en je kunt niet alles weten. Je kunt bijvoorbeeld wel bedenken dat je bij slecht weer een regen-emoji in de titel van je app wilt hebben, maar test dan wel of dat op alle devices ook werkt en of er geen onverwachte effecten optreden. Het zou zonde zijn als mails daardoor niet aankomen.

Houd er ook rekening mee dat het gebruik van een app kan groeien. Drie gebruikers die al hun bestanden opslaan in één map, dat gaat misschien nog wel goed. Met 3000 gebruikers is dat echt een ander verhaal.