In ons leven worden we steeds meer afhankelijk van miljarden regels programmacode. Code die ervoor zorgt dat we kunnen mailen, online shoppen, autorijden en altijd, overal bereikbaar zijn via social media. Daarnaast is bijvoorbeeld de administratie van bedrijven (hopelijk) volledig digitaal. Het maakt ons leven een stuk makkelijker. Tenminste, als het naar behoren werkt… De kwaliteit van al deze software is van enorm belang, soms zelfs van levensbelang! Zeker wanneer je bedenkt dat er gemiddeld één softwarefout optreedt per 1.000 regels programmacode. In deze blogpost lees je alles over het belang van testen.

Softwarekwaliteit is van levensbelang

Hoewel de kwaliteit van software steeds belangrijker wordt, zijn bedrijven niet verplicht hun software te testen. Voor het bouwen van een huis of een bedrijvencomplex bestaan er veel regels. Voor het bouwen van software zijn deze er niet, terwijl dit soms veel complexer is.

Een onderzoek uit 2013 heeft aangetoond dat 1 op de 4 fouten in de operatiekamer te wijten is aan softwareproblemen. Recent veroorzaakte het scannen van antivirussoftware ervoor dat een hartmonitor ermee stopte tijdens een operatie. Hierdoor moest de operatie worden onderbroken. Het nalopen van de instellingen of de werking van de software kan fatale fouten voorkomen.

Bedrijven die software produceren waar veiligheid in het geding is testen over het algemeen zo’n 80% van hun software. Zoals software voor vliegtuigen, ziekenhuizen en auto’s. Meestal, want er zijn genoeg voorbeelden waarbij dit niet gebeurt.

[sidebar name=”In-post advertisement “]

Financiële schade door softwarefouten

Een bug in administratieve software zal niet direct voor levensgevaarlijke situaties zorgen maar misschien wel voor veel hoofdpijn! In totaal zorgen softwarefouten in Nederland voor een jaarlijkse kostenpost van 1,6 miljard euro. Een flink bedrag, dat met gedegen testen voorkomen kan worden. Daarnaast kan het ook imagoschade en cybercriminaliteit ondervangen.

“In totaal zorgen softwarefouten in Nederland voor een jaarlijkse kostenpost van 1,6 miljard euro. Een flink bedrag, dat met gedegen testen voorkomen kan worden.”

Wanneer er bij een webshop bijvoorbeeld een storing optreedt bij het bestel- of betalingsproces dan kun je inkomsten mislopen doordat de klant niet of een te laag bedrag betaalt. Of je raakt de klant kwijt aan een andere webshop waar het proces wél snel en zonder foutmeldingen verloopt.

Eerder testen levert winst op

Al in 1979 is een onderzoek gedaan naar de herstelkosten van software. Dit onderzoek werd uitgevoerd door Barry Boehm. De uitkomst was dat de herstelkosten oplopen naarmate ze later in het ontwikkelproces zijn gemaakt. Hij stelt zelfs dat een fout ontdekt in de ontwerpfase, vroeg in het ontwikkelproces, 16x goedkoper is om te herstellen dan wanneer dezelfde fout pas wordt ontdekt in de testfase! Kortom; met het testen van software in de ontwerpfase kun je aanzienlijk besparen op de herstelkosten. Het resultaat van het onderzoek is samen te vatten in de Boehm’s Curve.

 

“Het herstellen van een fout ontdekt in de ontwerpfase is wel 16x goedkoper dan dezelfde fout ontdekt in de testfase.”

Bij Ambrero vinden we het belangrijk om zo vroeg mogelijk softwarefouten te detecteren. Daarom maken we gebruik van Test Driven Development (TDD). Bij TDD wordt eerst een test gemaakt, dan wordt de code ontwikkeld, totdat de test slaagt.

Wat is nou kwaliteit?

Nu hoor ik in de praktijk regelmatig de stelling ‘ontwikkelaars moeten toch gewoon goede software opleveren!’ Klopt, van ontwikkelaars mag je zeker kwaliteit verwachten. Maar wat is kwaliteit? En hoe meet je het?

Volgens ISO 8402 luidt de definitie van kwaliteit als volgt: Het geheel van eigenschappen en kenmerken van een product of dienst dat van belang is voor het voldoen aan vastgelegde of vanzelfsprekende behoeften.

De eigenschappen en kenmerken noemen we kwaliteitsattributen, welke zijn gedefinieerd in ISO 25010. Hier onder de 8 hoofdpunten:

Functionele geschiktheid

Doet de applicatie wat het doen moet?

Prestatie-efficiëntie

Is de applicatie snel genoeg?

Uitwisselbaarheid

In hoeverre kunnen twee applicaties elkaar beïnvloeden?

Bruikbaarheid

In hoeverre dient de applicatie het gebruiksgemak?

Betrouwbaarheid

Wat gebeurt er wanneer er een fout optreedt? Valt het systeem dan om? En hoelang duurt het voordat alles weer draait?

Beveiligbaarheid

Wordt de data goed beschermd tegen bijv. ongeautoriseerde toegang?

Onderhoudbaarheid

Kan de applicatie goed beheerd worden?

Overdraagbaarheid

Kan de applicatie eenvoudig geïnstalleerd, aangepast of vervangen worden?

Testen is een proces dat inzicht geeft in de kwaliteit door analyse van de risico’s. Een risico is het product van faalkans en schade. Is de faalkans heel groot, maar de schade nihil? Dan levert dat probleem weinig risico op. Omgekeerd geldt hetzelfde: is de faalkans vrijwel verwaarloosbaar, maar de schade groot? Dan levert het probleem een beperkt risico op. Pas op het moment dat die faalkans groter wordt neemt het risico toe. Heel sec zou je kunnen zeggen dat als er geen risico is je ook niet hoeft te testen.

“Een risico is het product van faalkans en schade.”

Risico’s maken onderdeel uit van de acceptatiecriteria, welke in overleg met de opdrachtgever worden opgesteld. De acceptatiecriteria vormen de leidraad voor het ontwikkeltraject en ook het testtraject en zijn verbonden met één of meerdere kwaliteitsattributen. Aan welke kwaliteitsattributen aandacht wordt besteed hangt dus af van de acceptatiecriteria en de soort applicatie waar we mee te maken hebben. Bij een standalone boekhoudsysteem zal de juistheid van gegevens belangrijk geacht worden. Bij een urenregistratiesysteem zal eveneens aandacht besteed worden aan de functionaliteit en aan de gebruiksvriendelijkheid. Bij bancaire systemen en andere privacygevoelige systemen zal naast juistheid ook beveiliging een belangrijk risico zijn. Het is dus van belang om datgene te testen waar de meeste risico’s liggen.

[alert type=”info” title=”Leestip: IT& Business Process Mangement”] Lees het artikel

Testen is een vak apart

Kan testen door iedereen worden gedaan? De vraag is eerder of je dit als bedrijf moet willen. Applicaties kunnen uit tienduizenden regels programmacode kunnen bestaan en requirements zijn niet altijd even helder. Testen is daarom een proces dat zeer nauwkeurig en gestructureerd moet worden uitgevoerd. Een tester moet vanaf de start van de ontwikkeling worden betrokken en moet de risico’s doorzien. Zo kun je flink besparen op herstelkosten.

Ik vergelijk testen altijd met het uitvoeren van een bouwtechnische keuring van een huis. Het is onverstandig om een huis te kopen zonder daar eerst kritisch naar te laten kijken. Het is belangrijk zelf kritisch te zijn, maar als koper/eindgebruiker ben je altijd (emotioneel) betrokken bij het huis. Een expert kijkt objectief naar de kwaliteit van het huis.

Bron: Ambrero

Mogelijk ook interessant

In het verlengde van de inhoud van de artikelen op onze website, biedt Utrecht Business de mogelijkheid op het onderwerp/vakgebied een opleiding te volgen. Hiertoe worden verschillende varianten aangeboden.