The proof of the pudding is in the…testing

mei 14, 2024

Onze pilot met reverse designing is inmiddels vergevorderd. Na weken bouwen breekt de stabilisatiefase aan. Eerlijk is eerlijk: het is nooit onze favoriete fase. De ontwikkelfase biedt ruimte voor creativiteit, ontdekken en uitproberen van nieuwe technologie, de voldoening van het maken. Hoewel we – zoals we ook al in onze vorige blog deelden – tegen het einde van de bouw-fase meer druk hebben ervaren dan in een traditioneel ontwikkelproces, geeft de bouwfase altijd ook heel veel energie. De stabilisatiefase is minder sprankelend en verloopt bij Rulecube eigenlijk altijd volgens een vast stappenplan.

Schaalbaarheid en snelheid

Onze eerste stap in de stabilisatiefase is controleren of onze applicatie nog steeds presteert zoals het moet. Dat wil zeggen: ook bij grote belasting en bij het verwerken van grote volumes data. De load benchmark test is dan ook in een vroeg stadium afgerond. Want als onze code niet snel genoeg is, ook bij grote volumes, maken we onze kernbelofte niet waar en moeten we aanpassingen doen. Gelukkig is de nieuwe release voor deze test al in een vroeg stadium met glans geslaagd.

Kwaliteitscode

De tweede stap is het testen van de code quality. We gebruiken daarvoor onder andere Sonar Cloud. Deze service checkt al onze source code op leesbaarheid, consistentie, kwaliteit en veiligheid, en helpt mee om onze kwaliteitsstandaard te borgen. De kwaliteit van code is vergelijkbaar met de kwaliteit van elke tekst. Een tekst kan te lezen zijn, maar de interpunctie kan ontbreken. Haakjes worden bijvoorbeeld wel geopend, maar nooit gesloten. Of de zinnen zijn wat lang, waardoor ze door een ander moeilijker te lezen zijn. Schone code bevat geen overbodige informatie en is netjes geordend. Daar blijft de software snel van en goed te onderhouden.

Daarnaast testen we de beveiliging en kwetsbaarheden van zowel ons platform als van de pakketjes waarin we onze spullen beschikbaar stellen voor klanten. Softwarecomponenten van derden die we daarvoor gebruiken horen daar ook bij.

Regressietests

Ten slotte testen we de applicatie zelf. Ook dat doen we vrijwel volledig automatisch. Met systemen zoals Cypress  testen we of het gebruik van de applicatie bij invoer van de testcases gelijk is gebleven aan eerdere versies, zogenaamde regressietests. Bij compleet nieuw functionaliteit gaat de meeste aandacht toe naar het ontwikkelen van test-cases voor die functionaliteit. Daar zien we dit keer wel een groot verschil door ons reverse designing proces: onze testcases liggen namelijk al klaar. Onze actieve klantcases vormen de ideale cases voor de testrun. Je raakt daarmee alle scenario’s die je ook in de praktijk tegen gaat komen. Daar kan geen zelfverzonnen casus tegenop. Het vraagt nog wat inspanning om de tests te schrijven, maar de inhoud ligt al vast.

Handmatig testen doen we minimaal. Zo’n 90% van onze regressietest is geautomatiseerd. Door direct de klantcases te verwerken in onze geautomatiseerde tests houden we dat percentage hoog.

Gelukkig komen we weinig verrassingen tegen. Met zo’n grote hoeveelheid nieuwe functionaliteit kan de stabilisatie veel en vooral saai werk opleveren, maar dat blijft ons gelukkig bespaard.

Read more