icon-arrow icon-check icon-mail icon-phone icon-facebook icon-linkedin icon-youtube icon-twitter icon-cheveron icon-download icon-instagram play close close icon-arrow-uturn icon-calendar icon-clock icon-search icon-chevron-process icon-skills icon-knowledge icon-kite icon-education icon-languages icon-tools icon-experience icon-coffee-cup
Werken bij IT Test Talents
Nieuws 25/11/2021

Software testen: 3 redenen waarom je het beter niet kunt vergeten

QoppoConsult

Testers kunnen soms zijn als het irritante neefje dat het feestje komt verstoren met zijn wijsneuzerige opmerkingen. Maar aan het eind heeft iedereen in de gaten dat hij steeds gelijk had. Nee, het is niet gemakkelijk om de luis in de pels te zijn, de advocaat van de duivel. Maar hoe nodig dat is, bewijzen deze 3 redenen waarom het testen van software* heel, heel noodzakelijk is.

1. Geld!

Het testen van software kost geld, maar voorkomt uiteindelijk dat je nog veel meer geld kwijt kunt zijn. Want software zonder bugs bestaat niet. Ja, misschien de tweeregelige code voor ‘Hello World’ in -vul hier jouw favoriete programmeertaal in-. En bugs die niet gevonden worden, kunnen veel geld gaan kosten. Niet alleen om ze later te vinden en alsnog te verwijderen, maar ook als ze helemaal niet (op tijd) gevonden worden.

De geschiedenisboeken staan vol met enorme fails als gevolg van de kleinste fout in de code. De eerste testvlucht van de Ariane 5 in 1996 duurde precies 37 seconden. De oorzaak was een fout in de besturingssoftware. En het ging daarbij om een fout die een eerstejaars student (m/v/x) Informatica had kunnen voorkomen. Voor de technici onder ons: een 64-bit floating point waarde moest worden omgezet naar een 16-bit integer, maar bleek te groot om met een 16-bit getal te worden weergegeven. De processor concludeerde ‘koekkoek’ en daar ging de raket. En wat was het geval: de software van de Ariane 5 was zonder wijzigingen overgenomen van de voorganger Ariane 4.

We zouden deze hele blog vol kunnen schrijven met enorme facepalms die met een béétje software testen voorkomen hadden kunnen worden, en waarbij veel geld bespaard had kunnen worden. Dat doen we misschien nog wel een keer, maar voor nu snel door naar

2. Veiligheid

Computerhacks, achterdeuren, ransomware, datadiefstal. Letterlijk elke dag staan de nieuwssites ermee vol. En vaak blijkt dat de software van routers, firewalls, besturingssystemen, processoren (!) en databases niet bepaald waterdicht is.

En websites. Een hack die nogal wat stof deed opwaaien (wat heet), is die op de bitcoinbeurs Mt. Gox in 2011. De eigenaar, Fransman Mark Karpelès, had de site net overgenomen van oprichter Jed McCaleb, en op 13 juni van datzelfde jaar al werd de beurs gehackt. In de dagen erna verdwenen voor miljoenen dollars aan bitcoins. De munt stond in die tijd op een waarde van ongeveer 10 dollar. Vandaag schommelt de koers rond de 50 duizend dollar, dus reken maar uit wat die bitcoins nu waard zijn. “Er zaten zwakke plekken in ons systeem”, boog Karpelès het hoofd. Dat kun je wel zeggen, ja.

3. Kwaliteit

Ieder bedrijf dat software aflevert, of dat nu voor applicaties is of voor hardware – in de vorm van firmware – wil de kwaliteit kunnen garanderen. Maar aangezien bugs bij het ontwikkelproces horen als motten bij een kaars, is testen onlosmakelijk verbonden met het maken van software. Zelfs zo onlosmakelijk, dat al jaren de tester met een elastiek aan de ontwikkelaar vastzit. “Ah, stukje software geschreven? Geef maar eens hier.” Om dit vervolgens helemaal binnenstebuiten te keren. Bug gevonden? Terug naar de ontwikkelaar. Rinse, repeat.

Natuurlijk is het wel iets gecompliceerder dan dat. In de huidige ontwikkelsystemen als agile/scrum en CI/CD maakt de tester soort van onderdeel uit van het ontwikkelteam. Omdat software ook steeds gecompliceerder wordt, is geautomatiseerd testen steeds belangrijker aan het worden. Alles om te zorgen voor kwaliteit.

Had Intel destijds maar beter opgelet. De Pentium-processor uit 1994 was het paradepaardje van het bedrijf, maar bleek een bug te bevatten in de floating point unit waardoor de uitkomst van sommige berekeningen fout waren. De ontdekker ervan, professor Thomas Nicely – what’s in a name – doopte het de Pentium FDIV bug. Intel kreeg te maken met een kostbare operatie om de processors te vervangen (kosten 475 miljoen dollar). Maar de imagoschade was veel groter, vooral omdat Intel de bug bagatelliseerde en eigenlijk helemaal niet wilde vervangen**. Gebruikers hadden dit niet verwacht van het doorgaans zo betrouwbare Intel, met een marktaandeel in computerschips van over de 90 procent in die tijd.

Je kunt het dus maar beter niet zover laten komen. Om met minister Hugo de Jonge te spreken: “Testen, testen, testen.”

*in de ruimste zin van het woord: software, firmware, wetware…
** Wat ergens best te begrijpen was, want de bug kwam alleen in gespecialiseerde berekeningen naar boven en was bovendien voorspelbaar.

Overzicht nieuws

IT Test Talents: slimme schakel tussen business en IT. Ontdek de kracht van onze experts!