woensdag 24 mei 2023
“Alweer blokkerende bevindingen net voor de release!”, “Waarom vinden we onze fouten toch altijd zo laat?”. Wie herkent de verzuchting van deze anonieme IT-manager niet?
Fouten vinden op een geïntegreerd production-like systeem zoals tijdens integratie- en acceptatietesten gaat meestal wel goed. En anders worden ze in productie wel gevonden door de gebruikers. Het laat vinden van fouten in het ontwikkelproces is onaantrekkelijk. Het vertraagt de planning en verstoort de voorspelbaarheid van de oplevering, om van productieproblemen maar niet te spreken. Gelukkig zijn er verschillende manieren om fouten vroeg in het ontwikkelproces te vinden.
Gebruik Model-Driven Design (MDD)
Het beste moment om fouten te vinden is in de specificatiefase, nog voordat er geprogrammeerd is. Veelal worden specificaties in natuurlijke taal in een Word document vastgelegd. Een tool als Word is eigenlijk niet geschikt, aangezien een dergelijk tool niet helpt bij het maken van eenduidige en complete specificaties. Deze aanpak leidt daardoor vaak tot incomplete en voor IT-ers onduidelijke specificaties, met verkeerde functionaliteit of testgevallen tot gevolg.
Een interessante aanpak is het gebruik van Model-Driven Design. Hierbij wordt de specificatie geschreven in een zogenaamd model, eventueel met tool-ondersteuning. Enerzijds dwingt dit de modeleur om precies en volledig te zijn, anderzijds maakt dit model het mogelijk dat de computer meehelpt in het ontwikkelproces. Bijvoorbeeld door automatische controle op tegenstrijdigheden en gebreken of door het automatisch genereren van testgevallen.
Genereer hyper-realistische testdata
Realistische data is belangrijk om alle mogelijkheden van het systeem te kunnen raken, in het bijzonder uitzonderingen en foutsituaties. Realistische data is echter vaak niet voorhanden tijdens de ontwikkeling. Productiedata kan niet zomaar gebruikt worden en heeft vaak niet de diversiteit aan gevallen die nodig zijn voor het testen. Voor het testen heb je ook exotische en onvoorziene testdata nodig, ook wel hyper-realistische data genoemd. Dergelijke testdata handmatig maken en onderhouden kost ontwikkelaars veel tijd, als het al gebeurt. De beste optie is dan ook om data te genereren met generatoren.
Gebruik simulatoren
Software engineers hebben tijdens het ontwikkelen vaak geen toegang tot aanpalende systemen. De communicatie met deze systemen kan daardoor pas goed getest worden tijden de integratietesten. Aanpalende systemen kunnen worden nagebootst met simulatoren, waarmee tijdens ontwikkeling realistische tests kunnen worden uitgevoerd. Hoe realistischer de simulator, hoe meer fouten kunnen worden gevonden.
Conclusie
Fouten laat in het ontwikkelproces vertragen en verstoren de voorspelbaarheid van de oplevering. Fouten vroegtijdig opsporen voorkomt dit en zorgt dat je met vertrouwen naar productie kan.
- Gebruik Model-Driven Design om fouten in specificaties te voorkomen.
- Gebruik datageneratoren om tijdens ontwikkeling al met (hyper-)realistische data te kunnen testen
- Gebruik realistische simulatoren om al ver voor de integratietesten de koppelingen met andere systemen te kunnen testen.
Je kunt hierbij kiezen voor open-source oplossingen, maar er zijn ook commerciële oplossingen op de markt. Het unieke Axini testplatform biedt de bovenstaande drie oplossingen en meer. Axini helpt organisaties oom complexe software-producten op tijd te leveren, zonder concessies op kwaliteit.
Wil je meer weten over fouten vroeg in het process voorkomen? Neem contact met ons op of volg ons op LinkedIn.