De belofte van low-code is dat je in hoog tempo nieuwe applicaties kunt ontwikkelen en opleveren. Met de groei naar volwassen enterprisewaardige platformen wordt dit zeker waargemaakt. In die snelheid van ontwikkelen schuilt echter ook een gevaar: het hoge ontwikkelingstempo kan ertoe leiden dat de buitenkant van de applicatie er weliswaar goed uitziet, maar dat er te weinig aandacht is besteed aan het testen van de applicatie: de binnenkant.
Vergelijk het met een mes: een mes van een euro kan er aan de buitenkant hetzelfde uitzien als een mes van honderd euro, maar van binnen er is wel degelijk een kwaliteitsverschil. Hoe zorgt u ervoor dat de kwaliteit van de applicaties gewaarborgd blijft?
Testen tot je erbij neervalt
Onterecht wordt er vaak gedacht dat bij low-code development alles al is getest. Het misverstand schuilt in het feit dat de individuele componenten inderdaad allemaal al getest zijn, maar dat wil niet zeggen dat op het moment dat u verschillende bouwstenen combineert dit ook nog goed werkt. Met low-code schuift softwareontwikkeling op naar de citizen developer, die geen achtergrond heeft in programmeren en denkt dat er niets fout kan gaan. Alle kwaliteitsaspecten worden toch afgevangen door het ontwikkelplatform. Maar u hebt nog steeds die ‘smid’ nodig om het mes in elkaar te zetten en ervoor te zorgen dat het een kwalitatief goed product wordt. Met andere woorden: ook met low-code platformen moet u testen tot u erbij neervalt.
Kwaliteit van software kan op vele manieren worden gedefinieerd, dit is onder meer afhankelijk van de rol die u bekleedt ten opzichte van de software. Als eindgebruiker wilt u dat de software datgene doet wat u vraagt, binnen een redelijke termijn. Dit is voornamelijk de functionele kwaliteit van buiten bezien. Hoe komt u tot deze kwaliteit als ontwikkelaar? Dit onderdeel start met een juist toegepast ontwikkelproces, waarvan een feedbackloop een standaard onderdeel is. Low-code platforms lenen zich bij uitstek om iteratief te ontwikkelen middels een agile proces. Daarin wordt gedefinieerd wat de wens is, aan welke eisen moet worden voldaan en wanneer het gereed is. Dit zijn voornamelijk de functionele wensen, waar zijn de kwaliteitsaspecten? Ook die horen thuis in een agile werkwijze, maar worden vaak achterwege gelaten ofwel door toepassing van een low-code ontwikkelplatform impliciet verwacht. Dit is echter een veel gemaakte denkfout en de ontwikkelaar zal te allen tijde de nadruk moeten leggen op de non-functionele kwaliteitsaspecten en deze expliciet benoemen.
Dagelijks integraal onderdeel
Door gebruik te maken van een low-code platform wordt het tonen van een resultaat van de noeste ontwikkelwerkzaamheden sterk versneld en kan snel een (stuk) applicatie worden getoond. Hierop kan feedback worden ontvangen en meegenomen worden in het vervolg van de ontwikkelingen. Deze feedback wordt vaak pas aan het einde van een iteratie opgevraagd, wanneer tevens de testen worden gestart.
In een agile werkwijze, ongeacht het platform, dient het testen integraal onderdeel te zijn van elke dag en niet als een mini-watervalmethode aan het einde van een iteratie te worden uitgevoerd. Een low-code platform maakt inspelen op de testen die worden uitgevoerd als integraal onderdeel van het ontwikkelproces eenvoudiger en door de directe manier van feedback zijn de kosten ook lager. Door het testen onderdeel te maken van het dagelijkse proces, voor zowel de ontwikkelaars als de gebruikers, zal de kwaliteit verhoogd worden. Echter, dit vergt ook iets speciaals van het ontwikkelteam. Er dient code geschreven te worden die testbaar is op korte termijn. Dit is wezenlijk anders dan code die pas aan het einde van een iteratie te testen is.
Het grote voordeel is dat de code meer onafhankelijk wordt van andere code, met een meer gedefinieerde input en output. Daarnaast zorgt het nadenken over deze manier van ontwikkelen ervoor dat de kwaliteit automatisch wordt verhoogd. De ultieme versie van deze manier van ontwikkelen is test driven development (TDD), een methode waarbij in de ontwikkeling eerst gewerkt wordt aan de testen alvorens er code wordt geschreven. Hiermee denkt de ontwikkelaar na over de requirements van een functie, werkt direct aan een vorm van documentatie en maakt hiermee testen integraal onderdeel van de ontwikkelwerkwijze. Binnen de low code platformen is dit een aandachtspunt, maar dit wordt nog niet of onvoldoende gefaciliteerd.
Wanneer TDD geen optie is dan denkt u als klant snel aan geautomatiseerd testen als een oplossing voor het verhogen van de kwaliteit. Dit is een werkwijze die hier zeker aan kan bijdragen en het helpt ook bij het herhalen van testen op eerder gebouwde functionaliteit (regressie testen). Daarnaast helpt het bij het definiëren van requirements, die heeft u immers nodig voor het schrijven van de geautomatiseerde tests. Wat hierbij wel een aandachtspunt is, is dat het geautomatiseerd testen geen ‘magic wand’ is. Met andere woorden: er zitten potentieel hoge kosten verbonden aan deze manier van testen, zeker binnen een low-code ontwikkeling waarbij de requirements deels worden ontdekt tijdens het proces
Deze hoge mate van flexibiliteit in de requirements zorgt voor extra noodzakelijke effort in het aanpassen van de testen. Dit komt omdat de testen uiteindelijk vaak zelf ook weer stukken code zijn en deze moeten worden aangepast op basis van de veranderde functionaliteit. Een alternatief voor dit volledig geautomatiseerde testen is het laten testen van applicaties middels een platform voor het schrijven, uitvoeren en verzamelen van testen, waarbij het voor de ontwikkelaars een geautomatiseerd proces lijkt en in realiteit mensenhanden zijn die het werk uitvoeren. Deze manier van testen heeft een aantal voordelen:
1) De testen kunnen worden geschreven in menselijk begrijpelijke taal (snelheid)
2) De testen worden uitgevoerd door mensen waarbij de resultaten van een hoger niveau zijn
3) Toepassingsmogelijkheden van kunstmatige intelligentie/machine learning
4) Kosten lijken hoog, maar zijn stukken lager dan voor volledig geautomatiseerd testen
Een onderdeel dat zeker niet mag ontbreken voor het verhogen van kwaliteit is het testen van de performance van een applicatie en hoe een applicatie zich gedraagt onder load. Bij de testen uitgevoerd door de ontwikkelaar, de tester en eventueel de eindgebruiker wordt de applicatie veelal door een zeer beperkt aantal gebruikers en een beperkte dataset getest. Het is belangrijk te bedenken hoe deze situatie zich verhoudt tot de applicatie in productie.
Uit bovenstaande blijkt dat low-code net als andere ontwikkeltalen je niet ontslaat van het uitvoeren van testen. Door samen te werken aan het resultaat, helpen deze platformen in het reduceren van kosten door snel in te kunnen spelen op testresultaten en veranderende requirements. Zorg voor een feedbackloop die kort is, waardoor het ontwikkelen van software meer wordt als een wieleretappe met kasseienstroken. In de route zitten moeilijke stukken en energie moet worden geconserveerd door continue inspectie en plannen voor de volgende sectie van de route. Kijk vaak achterom en plan vooruit, alleen dan komt u als winnaar over de streep.
“ook met low-code platformen moet u testen tot u erbij neervalt. ”
Automatisch testen is duur “omdat de testen uiteindelijk vaak zelf ook weer stukken code zijn en deze moeten worden aangepast op basis van de veranderde functionaliteit.”
Test daarom zodat het “voor de ontwikkelaars een geautomatiseerd proces lijkt en in realiteit mensenhanden zijn die het werk uitvoeren”.
low-code : Op je V-frame het fietswiel maar weer eens uitvinden en diegene die het creatiefst met verboden middelen omgaat blijft zijn concurrenten voor.