Door: Ronald Kerkhoff
Dit is het tweede artikel in een serie van zeven, waarin de evolutie van software testen centraal staat en welke bijdrage Nederland in die periode had. Dit artikel beschrijft de periode 1980 tot en met 1989.
De Opkomst van Systematisch Testen (jaren ‘80)
In de jaren ‘80 begon softwareontwikkeling zich steeds meer te professionaliseren. Computers waren kleiner en krachtiger geworden, en steeds meer bedrijven en organisaties stapten over van mainframes naar minicomputers en Personal Computers (PC).
De opkomst van de PC maakte softwareontwikkeling toegankelijker. In plaats van grote mainframes verschenen er talloze kleinere systemen en applicaties die overal opdoken. Software werd steeds meer het hart van de bedrijfsvoering en de impact van fouten werd groter. Het was een tijd van snelle vooruitgang, maar ook van nieuwe uitdagingen. De klassieke methoden voor testen waren nog steeds in gebruik, maar het besef groeide dat er behoefte was aan een meer gestructureerde benadering. Waar in de jaren ‘70 het testen vaak ad-hoc en reactief was, werd in de jaren ‘80 het belang van een systematische aanpak steeds duidelijker. In deze periode ontstonden de eerste vormen van geautomatiseerd testen, toen nog toekomstmuziek, maar de eerste experimenten met testscripts werden opgestart om testactiviteiten sneller en efficiënter te maken. Het idee dat testtools de efficiëntie van softwareontwikkeling kon verbeteren, begon voorzichtig voet aan de grond te krijgen.
De Watervalmethodiek en de Kosten van Fouten
In deze periode won de watervalmethodiek aan populariteit als een gestandaardiseerde manier van softwareontwikkeling. Dit sequentiële model verdeelde het ontwikkelproces in vaste fasen: definitiestudy/analyse, ontwerp, bouw/implementatie, testen, integratie en beheer & onderhoud. Elke fase werd afgesloten voordat de volgende begon. Deze aanpak bracht structuur, maar had als nadeel dat het testen pas aan het einde plaatsvond.
Daardoor werden fouten vaak pas laat ontdekt, wat leidde tot vertragingen en hoge kosten. Barry Boehm liet dit in 1981 visueel zien met zijn bekende cost of change-curve, ook wel curve van Boehm genoemd, waaruit bleek dat defecten exponentieel duurder werden om te herstellen naarmate ze later in het proces werden gevonden.
Om testprocessen verder te structureren, werd in 1983 de eerste versie van de IEEE 829-standaard voor software test documentatie gepubliceerd. Deze standaard definieerde formele documenten voor acht fasen van softwaretesten, zoals testplannen, testontwerpen en testrapportages. Dit verbeterde traceerbaarheid en herhaalbaarheid van testactiviteiten aanzienlijk.
De eerste stappen in geautomatiseerd testen
In de jaren ‘80 werd voorzichtig geëxperimenteerd met testautomatisering, vooral in sectoren waar betrouwbaarheid cruciaal was. In mainframe-omgevingen, zoals IBM’s MVS (Multiple Virtual Storage), werden batchscripts gebruikt om repetitieve tests uit te voeren. Banken en financiële instellingen automatiseerden transactietests met CICS Test Drivers, terwijl in de luchtvaart en defensie Hardware-in-the-Loop (HIL) simulaties werden ingezet om embedded software te testen. In 1989 introduceerde Mercury Interactive de eerste versie van LoadRunner, een tool voor performancetesten die veel invloed zou krijgen in de decennia erna. Deze stap luidde een nieuwe fase in voor testautomatisering, die in de jaren ’90 en 2000 verder zou groeien.
De doorbraak van systematisch testen
In deze periode ontstonden belangrijke ideeën die de testwereld blijvend zouden beïnvloeden. James Bach en Cem Kaner begonnen hun werk in de testgemeenschap, wat later resulteerde in de methodologieën die we nu kennen als context-driven testing. Dit idee benadrukte het belang van teststrategieën die waren aangepast aan de specifieke context van een project, in plaats van een standaardbenadering toe te passen voor elke situatie. Kaner legde met zijn werk het fundament voor de bredere erkenning van teststrategieën die niet uniform waren, maar flexibel werden toegepast, afhankelijk van de omstandigheden en het project.
De methoden die in de jaren ‘80 ontstonden, richtten zich vooral op het verbeteren van de testaanpak voor software en systemen. Gerald Weinberg, een andere invloedrijke persoon in deze periode, benadrukte het belang van communicatie en samenwerking tussen ontwikkelaars en testers. Waar testen in de jaren ‘70 vaak als een afzonderlijke activiteit werd beschouwd, werd in de jaren ‘80 steeds meer erkend dat het een integraal onderdeel van het ontwikkelproces moest zijn. Dit werd nog versterkt door de opkomst van iteratieve ontwikkelingsmodellen zoals Rapid Application Development (RAD), waarin testen een doorlopend proces was in plaats van een stap aan het eind.
De Opkomst van Unittesten en Complexere Software
In de jaren ‘80 werden ook de eerste vormen van unittesten geïntroduceerd, waarbij softwareontwikkelaars kleine stukjes code testten om te verifiëren dat ze correct functioneerden. Deze benadering werd uiteindelijk een standaardpraktijk in softwareontwikkeling. Met de groei van software begon echter ook de complexiteit van testen toe te nemen. In plaats van kleine, gestroomlijnde programma’s moesten ontwikkelaars nu omgaan met grote applicaties die meerdere systemen en componenten integreerden. Het aantal interacties tussen softwaremodules nam toe, en de kans op fouten die het hele systeem konden verstoren werd groter.
Dat werd pijnlijk duidelijk in 1982 toen het systeem van de Therac-25, een bestralingstoestel voor de behandeling van kanker, op grote schaal ingezet in ziekenhuizen. Door een combinatie van softwarefouten en ontoereikend testen werden enkele patiënten blootgesteld aan straling die honderden malen groter waren dan de voorgeschreven dosis, met ernstig letsel of zelfs de dood tot gevolg.
Dit incident legde niet alleen de risico’s van softwarefouten bloot, maar ook de noodzaak om testen in een veel vroeger stadium van de ontwikkeling te integreren. Het was een duidelijke herinnering dat in de context van gezondheidszorg, luchtvaart of andere kritieke sectoren, fouten in de softwareontwikkeling daadwerkelijk levens konden kosten. Het uitvoeren van rigoureuze tests werd dan niet alleen een technische noodzaak, maar ook een ethische verplichting.
In de financiële wereld was software testen inmiddels een essentieel onderdeel van de operationele processen. Het mislukken van systemen, zoals betalingsverkeer of beurshandelssystemen, kon leiden tot enorme financiële verliezen. De risicobeheersing van softwarefouten werd dan ook steeds meer een prioriteit. Tegelijkertijd namen de eisen voor betrouwbare, consistente software toe. Financiële instellingen begonnen testteams te vormen die zich specifiek richtten op het grondig testen van software die werd gebruikt voor transactieprocessen en dataverwerking.
De rol van Nederland in software testen
In Nederland werd in deze periode de basis gelegd voor een meer gestructureerde testaanpak. Bij de Belastingdienst in Nederland werd halverwege de jaren ‘80 pijnlijk duidelijk hoe kwetsbaar grootschalige IT-systemen waren geworden. De loonbelastinggegevens bleken onbetrouwbaar, de cruciale dagrun duurde soms meer dan 27 uur, en het douanesysteem, essentieel voor de doorvoer via Schiphol en de Rotterdamse haven, kende structurele tekortkomingen. Een onderzoek door de Algemene Rekenkamer leidde tot een duidelijke opdracht. Er moest een professioneel testproces komen om deze risico’s te beheersen.
Begin 1985 werd een werkgroep opgericht, onder leiding van Martin Pol, die de brug vormde tussen development en operations (twee werelden die toen nog sterk gescheiden functioneerden). De werkgroep begon aan een nagenoeg onontgonnen terrein. Er bestond in Nederland nauwelijks literatuur of methodiek op het gebied van testen. Slechts enkele summiere richtlijnen in de SDM-methodologie en een incidentele cursus boden houvast. De groep keek daarom ook naar internationale bronnen zoals Boris Beizer, David Parnas en Bill Hetzel, die in de VS al verder waren met testtheorieën.
De situatie werd als zo urgent ervaren dat de Tweede Kamer de aanbevelingen van de werkgroep steunde en opdracht gaf om vóór 1 juli 1987 een handboek op te leveren met concrete richtlijnen voor testprocedures. In 1986 werd het eerste rapport met contouren van een gestructureerde testaanpak positief ontvangen. Deze aanpak legde de nadruk op procesmatig werken, risicoanalyse en volledige traceerbaarheid van specificatie tot testresultaat. Principes die later gangbaar zouden worden, maar destijds revolutionair waren.
Om de kennis verder te verdiepen werd Martin Pol zelfs naar de Verenigde Staten gestuurd om een cursus te volgen bij Bill Hetzel. Met die kennis werd het Handboek Testen opgesteld, waarin duidelijk werd uitgelegd wie wat testte, wanneer, waarom en met welke middelen. Deze aanpak werd begin 1988 verplicht toegepast binnen de Belastingdienst en vormde de eerste systematische benadering van softwaretesten in Nederland.
De lessen uit de jaren ’80 vormden de springplank voor verdere professionalisering in het daaropvolgende decennium.
Vooruitblik naar de Jaren ’90
Nu de basis was gelegd was het in de jaren ’90 dat softwaretesten écht volwassen werd, met methodologische verankering, meer tooling, en de erkenning van testen als professioneel vakgebied.
persoonlijke bron: Martin Pol, waarvoor mijn dank
Het volgende artikel in deze reeks: De Formele Structurering van Testen (jaren ‘90)
Artikel 1 van deze reeks: De Pioniers van Softwaretesten (jaren ’70)
Artikel 2 van deze reeks: De Opkomst Van Systematisch Testen (jaren ’80) (dit artikel)
Artikel 3 van deze reeks: De Formele Structurering van Testen (jaren ‘90).
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)