Door: Ronald Kerkhoff
Dit is het derde artikel in een serie van zeven, waarin de evolutie van softwaretesten centraal staat en welke bijdrage Nederland in die periode had. Dit artikel zoomt in op het decennium waarin testen uitgroeide van ambacht tot professioneel vakgebied: de jaren 1990 tot en met 1999.
De Formele Structurering van Testen (Jaren ‘90)
De jaren ’90 waren een periode van transformatie voor softwaretesten. Terwijl de technologie zich verder ontwikkelde, werd de behoefte aan een gestandaardiseerde aanpak voor softwaretesten steeds duidelijker. Dit leidde tot de opkomst van methodologieën en tools die het testen van software formeler, efficiënter en herhaalbaarder maakten. Tegelijkertijd zagen bedrijven zich geconfronteerd met de complexiteit van softwareontwikkeling, wat nieuwe uitdagingen met zich meebracht voor testteams.
Testen integreren met het ontwikkelproces
In de vroege jaren ’90 groeide de erkenning dat softwaretesten geïntegreerd moest worden in het ontwikkelproces. Voorheen was testen vaak ad-hocen begon het pas ná de bouw van de software, waardoor fouten vaak pas in een laat stadium aan het licht kwamen. Om dit te verbeteren, begon men met het toepassen van ontwikkelmodellen waarin testen eerder in de levenscyclus werd geïntegreerd.
Het V-model, dat begin jaren ’90 opkwam als alternatief voor de watervalmethodiek, plaatste testactiviteiten parallel aan de ontwikkelfasen. In tegenstelling tot de waterval, waarbij de testfase vaak pas na de ontwikkeling van de software begon, had elke ontwikkelfase in het V-model een corresponderende testfase. Dit zorgde voor gestructureerdere en beter gedefinieerde testactiviteiten, van unittesten tot systeem- en acceptatietesten.
Nieuwe inzichten in kwaliteit
In 1991 werd ISO 9126 gepubliceerd, een internationale standaard voor softwarekwaliteit. De zes kwaliteitsattributen, waaronder functionaliteit, betrouwbaarheid en onderhoudbaarheid, kregen steeds vaker een plaats in teststrategieën, wat de link tussen testen en kwaliteitsdoelstellingen versterkte.
Professionalisering en de eerste certificeringen
Met de groei van het testvak ontstond behoefte aan formele kwalificaties. In het Verenigd Koninkrijk begon de British Computer Society (BCS)via het Information Systems Examination Board (ISEB) met certificeringen voor softwaretesten. De ISEB Foundation Certificate in Software Testing werd internationaal erkend en bood testers voor het eerst een uniforme standaard voor kennis en vaardigheden.
Terwijl internationaal steeds meer werd ingezet op certificering en kennisborging, ontstonden er in Nederland op eigen bodem krachtige initiatieven die het testvak verder vorm gaven.
De rol van Nederland in software testen
In Nederland speelde de Belastingdienst een belangrijke rol in de professionalisering van software testen. Het intern ontwikkelde Handboek Testen dat in 1988 uitkwam, werd begin jaren ‘90 beschikbaar gesteld als public domain en verspreidde zich snel buiten de organisatie, ondanks het feit dat de Belastingdienst geen commerciële partij was. Zo vonden 500 exemplaren hun weg buiten de Belastingdienst.
In de eerste helft van de jaren ’90 stapte Martin Pol, de auteur van Handboek Testen, over naar Software Control (dat later opging in Sogeti). Daar werkte hij samen met Erik van Veenendaal en Ruud Teunissen aan de ontwikkeling van TMap (Test Management Approach). Deze nieuwe aanpak moest de beperkingen van het Handboek Testen aanpakken en was generieker toepasbaar. In 1995 werd het boek Testen Volgens TMap officieel gepresenteerd. Het bood een volledige testmethodologie, inclusief organisatorische, procesmatige én technische aspecten van softwaretesten. TMap vond internationaal weerklank en vormde een belangrijke Nederlandse bijdrage aan de professionalisering van het testvak.
Niet alleen TMap werd in die tijd geïntroduceerd, ook TestFrame, ontwikkeld door CMG (het huidige CGI), verscheen in 1995 als boek en methodiek. TestFrame richtte zich op het ontwerpen en structureren van geautomatiseerde en handmatige tests op basis van businessprocessen. Het bood concrete richtlijnen voor testontwerp, regressietests en herbruikbaarheid van testsets, en werd met name populair binnen organisaties die een sterk procesgerichte aanpak zochten. Samen zorgden TMap en TestFrame voor twee toonaangevende Nederlandse bijdragen aan de internationale testgemeenschap.
Naast TMap ontstonden er in Nederland tegen het einde van de jaren ’90 ook nieuwe denkrichtingen waarin risico’s en requirements een centrale rol speelden in de testaanpak. Binnen organisaties als LogicaCMG werd geëxperimenteerd met methoden waarbij testinspanning werd afgestemd op risico’s en bedrijfsdoelstellingen. Deze aanpakken legden de basis voor meer risico- en requirementgedreven teststrategieën die in de jaren daarna verder zouden worden uitgewerkt.
Het belang van goede documentatie
In mijn vorige artikel beschreef ik de totstandkoming van de IEEE 829-standaard voor testdocumentatie. Waar deze in de jaren ’80 werd geïntroduceerd, vond de standaard pas in de jaren ’90 echt brede toepassing in de praktijk. Steeds meer organisaties begonnen testplannen, testspecificaties en testrapportages systematisch op te stellen volgens deze richtlijn. Testdocumentatie werd daarmee niet langer gezien als een administratief bijproduct, maar groeide uit tot een strategisch instrument voor kwaliteitsborging, traceerbaarheid en reproduceerbaarheid. Binnen methodieken zoals TMap werd het gebruik van IEEE 829 opgenomen als best practice, wat bijdroeg aan de verdere professionalisering van het testvak.
De Nederlandse testgemeenschap krijgt vorm
Terwijl methodieken als TMap en TestFrame hun opmars maakten, ontstond in 1996 ook een platform om testers onderling te verbinden: TestNet, officieel geregistreerd als de Nederlandse Vereniging voor Testers. Deze vereniging groeide uit tot een van de oudste en meest actieve testverenigingen in Europa.
Vanaf het begin organiseerde TestNet kennissessies, congressen en gaf het publicaties uit, allemaal met als doel het vakgebied testen op de kaart te zetten en verder te ontwikkelen. TestNet werd hét netwerk waar testers kennis deelden, nieuwe werkwijzen bespraken en de professionele positie van het testvak versterkten.
Nederlandse testers kregen in deze periode ook internationaal steeds meer voet aan de grond. Zo werd in 1993 EuroSTAR opgericht (European Software Testing Analysis & Review), een jaarlijks Europees testcongres waar professionals uit heel Europa samenkwamen om kennis en ideeën te delen. Ook hier was de Nederlandse inbreng opvallend: sprekers als Martin Pol, Erik van Veenendaal en Ruud Teunissen droegen met keynotes en sessies actief bij aan de ontwikkeling van het testvak op internationaal niveau.
De oprichting van TestNet markeerde daarmee een belangrijke stap in de professionalisering van softwaretesten in Nederland. Het vak kreeg een gezicht, een stem en een hechte gemeenschap, zowel nationaal als internationaal.
Nieuwe generatie testtools
Het gebruik van testautomatisering in softwaretesten nam grote stappen in 1995, met de introductie van Mercury TestDirector (later bekend als Quality Center), de eerste geautomatiseerde testmanagementtool. TestDirector stelde teams in staat om testcases te maken en te beheren, vastleggen van defecten en gedetailleerde rapportages te genereren, waarmee het voor testers veel gemakkelijker werd om het testproces te organiseren en te volgen. Dit verbeterde aanzienlijk de samenwerking tussen testers, ontwikkelaars en managers.
Tegelijkertijd ontstond de behoefte aan testautomatisering in reactie op de groeiende complexiteit van software en de noodzaak tot regressietesten. Steeds meer bedrijven investeerden in automatiseringstools om herhaalbare testen sneller uit te voeren. Toch stond geautomatiseerd testen nog in de kinderschoenen en bleef het vaak beperkt tot eenvoudige testgevallen.
Begin van het testen van computernetwerkomgevingen
Software werd in toenemende mate gebruikt in computernetwerkomgevingen, wat nieuwe testuitdagingen met zich meebracht. Software was niet langer alleen een stand-alone applicatie, maar moest vaak communiceren met andere systemen over computernetwerken of zelfs via het internet. Testen moest niet alleen de functionaliteit van de software controleren, maar ook de prestaties bij netwerkvertragingen, uitval of interoperabiliteit met andere systemen.
Het belang van kwaliteitsborging
Een van de meest beruchte softwarefouten uit dit decennium was de crash van de Ariane 5-raket op 4 juni 1996. Slechts 37 seconden na de lancering explodeerde de raket vanwege een softwarefout in het navigatiesysteem. De fout, een niet-afgevangen conversie van een 64-bits naar 16-bits getal, leidde tot een foutieve koerscorrectie en de zelfvernietiging van de raket.
De ramp illustreerde de kritieke noodzaak van strikte kwaliteitsborging en validatie van kritieke software. Vooral de afwezigheid van afdoende testautomatisering en formele richtlijnen werd als oorzaak genoemd. De schade bedroeg honderden miljoenen euro’s en het incident geldt als een klassiek voorbeeld van het belang van degelijk testen.
Toenemende complexiteit van software testen
Met de komst van multi-platform software, verschillende besturingssystemen en hardwareconfiguraties werd testen steeds complexer. Testers moesten nieuwe vaardigheden ontwikkelen om met variaties in infrastructuur, distributie en interactie om te gaan. Handmatig testen voldeed niet meer, en veel organisaties begonnen met het structureren en opschalen van hun testaanpak.
De impact van de millennium bug (Y2K)
Een unieke uitdaging voor testers in de jaren ’90 was de beruchte millennium bug (Y2K). Veel oudere software registreerde jaartallen slechts met twee cijfers, waardoor het jaar 2000 kon worden geïnterpreteerd als 1900. Dit had mogelijk desastreuze gevolgen voor dataverwerking, planningen, financiële systemen en infrastructuur zoals energie en transport.
Overheden en bedrijven startten massale herstel- en testprojecten. Testen kreeg plotseling topprioriteit en kwam zelfs op de politieke agenda te staan. Wereldwijd werden grote budgetten vrijgemaakt voor testcapaciteit, inventarisatie, code-analyse en validatie.
Bij sommige organisaties werd achteraf getwijfeld of de omvang van het testtraject proportioneel was. In de praktijk bleken veel systemen robuuster dan gedacht of had de fout weinig impact. Maar dat wil niet zeggen dat de inzet voor niets was: het was juist door deze rigoureuze voorbereiding dat de schade beperkt bleef. Het toonde aan dat het uitblijven van een ramp niet duidde op overdreven maatregelen, maar juist op succesvolle voorbereiding.
Mijn eerste ervaring met testen als gebruiker
In 1999 zette ik mijn eerste stappen als softwaretester. Als ervaren gebruiker van het Hypotheken Offerte Systeem (HYPOS), het hypothekensysteem van de toenmalige Postbank, waar ik werd gevraagd mee te helpen bij het testen van een nieuwe versie van het systeem. Mijn taken bestonden uit het reviewen van de requirements en het uitvoeren van testcases bij de oplevering van de applicatie.
Dankzij mijn gedegen kennis van HYPOS kon ik de requirements goed beoordelen en waardevolle feedback geven. Tijdens het testen ontdekte ik een kritisch defect dat grote impact had op het project. Wat was er aan de hand? In het oude HYPOS-systeem moesten allerlei berekeningen, waaronder het maximale hypotheekbedrag, handmatig worden uitgevoerd. In de nieuwe versie zou dit proces geautomatiseerd worden. Maar tijdens het testen kreeg ik een onverwachte uitkomst: Er werd geen bedrag getoond, het veld bleef leeg. Ik rapporteerde dit als een bevinding, en wat bleek? De volledige berekeningslogica was men simpelweg vergeten te implementeren. Dit resulteerde in een hersteltraject van maar liefst twee maanden.
De Millenniumsprong van Softwaretesten Bij het afsluiten van de twintigste eeuw werden nieuwe uitdagingen zichtbaar voor het begin van de eenentwintigste. Software werd steeds omvangrijker en complexer, met systemen die intensiever met elkaar communiceerden via netwerken en het opkomende internet. Tegelijkertijd groeide het besef dat testen niet alleen een noodzakelijke stap was, maar ook een vakgebied dat geoptimaliseerd moest worden. De fundamenten waren gelegd, de volgende stap was het verfijnen, verbeteren en professionaliseren van het testproces. In het volgende artikel gaan we in op hoe deze optimalisatie in de jaren 2000 tot 2009 vorm kreeg, en welke rol testprofessionals daarin speelden.
Het volgende artikel in deze reeks:
De opkomst van de testprofessional jaren 00/09
Artikel 1 van deze reeks: De Pioniers van Softwaretesten (jaren ’70)
Artikel 2 van deze reeks: De Opkomst Van Systematisch Testen (jaren ’80)
Artikel 3 van deze reeks: De Formele Structurering van Testen (jaren ‘90). (dit artikel)
Artikel 4 van deze reeks: De opkomst van de Testprofessional (jaren 2000/2009)
Artikel 5 van deze reeks: De Digitalisering en Cloudtransitie van Softwaretesten (jaren ’10)
Artikel 6 van deze reeks: De revolutie van softwaretesten (jaren ’20)
Artikel 7 van deze reeks: De toekomst van testen (jaren ’30)