Door: Ronald Kerkhoff
In 1999, toen ik nog bij de Postbank op de afdeling Hypotheken werkte, werd ik gevraagd om het Hypos-systeem te testen voor de Gebruikers Acceptatie Test(GAT). Destijds had ik niet kunnen vermoeden dat dit het begin zou zijn van een lange en boeiende carrière in softwaretesten. Nu, 26 jaar later, heb ik in diverse rollen gewerkt, voornamelijk als testmanager en tegenwoordig als testtool consultant. Wat ooit begon als een kennismaking met testen, groeide uit tot een passie voor kwaliteit en betrouwbaarheid in softwareontwikkeling.
Om een beter beeld te krijgen van de (toekomstige) ontwikkelingen binnen het testvak, leek het mij interessant om te beschrijven hoe het testen zich vanaf de jaren zeventig heeft ontwikkeld en welke rol het vandaag de dag speelt binnen softwareontwikkeling. Maar nog belangrijker: welke rol zal softwaretesten in de nabije toekomst spelen? Wordt testen dan nog uitgevoerd door mensen, of nemen AI en machine learning deze taken over? Welke vaardigheden zullen testers moeten ontwikkelen om relevant te blijven in een wereld waarin AI en kwantumcomputers software steeds autonomer maken?
Door de jaren heen is softwaretesten altijd volgend geweest op de ontwikkelmethoden die zijn bedacht, zoals de watervalmethodiek, iteratieve modellen en Agile. Maar met de toekomstige technologische sprongen rijst een nieuwe vraag: kan testen niet langer volgend zijn, maar juist richtinggevend? Kunnen nieuwe testmethoden bijdragen aan het ontwikkelen van software op een manier die testbaarheid en betrouwbaarheid vanaf het begin integreert?
De belangrijkste vraag blijft echter:
Wat is de perceptie van softwaretesten?
Softwaretesten wordt op verschillende manieren gewaardeerd. Sommigen zien het als een onmisbare stap in het ontwikkelproces, terwijl anderen het beschouwen als een kostenpost die pas nut heeft als er daadwerkelijk fouten worden gevonden. Dit komt deels doordat testen niet direct bijdraagt aan de ontwikkeling van nieuwe functionaliteit.
Wat veel mensen niet weten, is dat testen primair een detectieve maatregel is. Dit betekent dat testen risico’s zichtbaar maakt en verborgen defecten opspoort voordat ze schade kunnen aanrichten. Het doel hiervan is vertrouwen opbouwen en continuïteit garanderen. Net zoals een beveiligingsscanner op een vliegveld bepaalt welke goederen zijn toegestaan, controleert testen of software aan de eisen voldoet en spoort het mogelijke fouten op. Hoe eerder een probleem wordt ontdekt, hoe kleiner de impact.
Door de jaren heen is de perceptie van testen sterk veranderd. Waar het vroeger nog weleens als een kostenpost werd gezien, is het inmiddels uitgegroeid tot een volwaardig en onmisbaar onderdeel van softwareontwikkeling. De groeiende complexiteit van software, strengere regelgeving en de noodzaak om snel en betrouwbaar te leveren, hebben ertoe geleid dat testen een stevige positie heeft verworven binnen ontwikkeltrajecten. Testprofessionals spelen hierin een cruciale rol: niet alleen door fouten te identificeren, maar ook door bij te dragen aan kwaliteit, risicobeheersing en strategische besluitvorming.
Wat kun je verwachten in deze blogreeks?
In deze zevendelige blog neem ik je mee op een reis door de evolutie van softwaretesten: van de pioniers uit de jaren ’70, die de eerste teststrategieën introduceerden, tot aan de autonome en AI-gestuurde testomgevingen van de toekomst. Hoe zijn testmethoden veranderd? Welke innovaties hebben de kwaliteit van software verbeterd? En wat betekent dit voor de rol van testers in de komende decennia?
Laten we beginnen bij het prille begin.
Deel 1 – De Pioniers van Softwaretesten (jaren ’70)
In de jaren zeventig kwam softwareontwikkeling echt van de grond, maar het werken met computers was nog een fysiek proces. Het was een tijd waarin computers gigantische machines waren, verborgen in de datacenters van overheden en grote bedrijven.
De wereld van softwareontwikkeling in de jaren zeventig
Stel je een kamer voor die zo groot is als een gymzaal, gevuld met kastgrote computers die brommen en flikkeren. In de hoek staat een stapel ponskaarten. Fragiele stukjes karton met minuscule gaatjes die de sleutels tot een programma vormen.
Programmeurs schreven hun code niet op een toetsenbord zoals nu, maar met de hand op papier. Vervolgens prikten ponsers de instructies zorgvuldig op kaarten: Eén kaart per regel code. Een fout betekende niet simpelweg een backspace en opnieuw typen, maar een volledig nieuwe kaart ponsen. Daarna werd de stapel kaarten ingelezen door een mainframecomputer, die de code verwerkte. De uitvoer werd meestal opgeslagen op magneetbanden, waarna de programmeur uren, soms zelfs een dag, moest wachten op de resultaten. Als er ergens een klein foutje in zat, kon het hele programma crashen en begon de wachttijd opnieuw.
Dit maakte het bijzonder lastig om fouten tijdig te ontdekken. Testen was in die tijd vooral een reactief proces: pas als de schade was aangericht, ontdekte men wat er mis was gegaan. En soms had dat grote gevolgen.
Een wake-up call: de storing bij AT&T (1976)
In 1976 kreeg AT&T, het bedrijf dat een groot deel van de Amerikaanse telefooninfrastructuur beheerde, te maken met een enorme storing in hun elektronische schakelsysteem (Electronic Switching System, ESS). Honderdduizenden telefoongesprekken werden verkeerd doorgeschakeld of kwamen helemaal niet tot stand.
De oorzaak? Een softwarefout die te laat werd ontdekt. Dit incident maakte pijnlijk duidelijk hoe kwetsbaar computersystemen waren en hoe belangrijk het was om fouten vóór ingebruikname te vinden.
De eerste stappen naar gestructureerd testen
Toch was softwaretesten nog geen volwaardige discipline. Programmeurs vertrouwden op hun ervaring en intuïtie om fouten te vinden, maar systematisch testen zat nog niet in het DNA van softwareontwikkeling. Dat begon pas te veranderen toen pioniers zoals Glenford Myers in de jaren zeventig nieuwe inzichten introduceerden. Myers stelde dat testen niet alleen bedoeld was om te bewijzen dat software werkte, maar vooral om fouten te vinden voordat ze schade aanrichtten. Een revolutionair idee!
Ook Boris Beizer ontwikkelde methoden zoals black-box testing en white-box testing. Technieken waarmee testers systematisch software konden doorlichten zonder afhankelijk te zijn van de grillen van individuele programmeurs.
Daarnaast droeg William C. Hetzelbij aan het systematisch structureren van testmethoden. Hij introduceerde in de jaren ‘70 en ‘80 methoden die tot op de dag van vandaag worden gebruikt.
Ondertussen werd in wetenschappelijke kringen nagedacht over de formele aspecten van testen. Böhm en Jacopini bewezen in 1966 dat alle algoritmen konden worden opgebouwd uit slechts drie controleconstructies: sequentie, selectie en iteratie:
Hun werk legde indirect de basis voor gestructureerd programmeren die zich richtten op de interne logica van software. Wat tot gevolg had dat dit de basis heeft gelegd voor methodische en gestructureerde benaderingen van softwaretesten, wat uiteindelijk leidde tot de ontwikkeling van formele testtechnieken en -strategieën.
Testen als noodzaak: mislukkingen als leerervaring
Toch bleef testen lange tijd een ondergeschoven kindje. In veel bedrijven werd het gezien als een noodzakelijk kwaad dat pas aan het einde van het ontwikkelproces aan bod kwam. Dit leidde soms tot dramatische mislukkingen. Een beroemd voorbeeld, hoewel de lancering al in 1962 plaatsvond, was NASA’s Mariner 1-raket. Een klein ontbrekend streepje in een formule (R in plaats van R̅) zorgde ervoor dat de raket na enkele minuten uit koers raakte en vernietigd moest worden. Zulke incidenten dienden als waarschuwing voor de software-industrie: fouten in code konden verstrekkende gevolgen hebben, niet alleen voor computers, maar voor de echte wereld.
Eerlijkheidshalve moet worden gezegd dat met de kennis en werkwijze van die periode de kans klein was dat deze fout vóór de lancering was ontdekt.
De opkomst van testen in kritieke sectoren
Ook in de financiële sector begonnen bedrijven in te zien hoe riskant softwarefouten waren. Banken en handelsplatformen vertrouwden steeds meer op computersystemen, maar een bug in een algoritme kon zomaar miljoenen kosten. Langzaam maar zeker groeide het besef dat testen niet een sluitstuk moest zijn, maar een essentieel onderdeel van softwareontwikkeling.
Softwaretesten in Nederland
De bijdrage van Nederland aan softwaretesten in de jaren zeventig was meer indirect en vond voornamelijk plaats via wetenschappelijk onderzoek en vroege toepassingen van softwarekwaliteit.
De erfenis van de pioniers
De pioniers van softwaretesten legden in deze periode de basis voor een systematische aanpak, maar er was nog een lange weg te gaan voordat testen een volwaardige discipline werd binnen softwareontwikkeling. In de praktijk werd er vaak ad-hoc getest door programmeurs zelf, waarbij fouten werden gedetecteerd via trial-and-error.
Het duurde nog enkele decennia voordat softwaretesten zich van een geïsoleerde eindstap ontwikkelde tot een geïntegreerd en onmisbaar onderdeel van de hele levenscyclus.
Het volgende artikel in deze reeks:
De Opkomst van Systematisch Testen (jaren ’80)