Door: Ronald Kerkhoff
Dit is het vierde artikel in een serie van zeven, waarin we de fascinerende evolutie van softwaretesten verkennen en stilstaan bij de belangrijke rol die Nederland daarin speelde. Deze keer neem ik je mee naar een tijdperk waarin testen niet langer op de achtergrond stond. Sterker nog: in de jaren 2000 tot en met 2009 was testen hot.
Een nieuwe beroepsgroep ontstaat
In die periode bestond er nog nauwelijks een formele opleiding tot softwaretester. Meer dan 90% van de testers kwam destijds min of meer toevallig in het vak terecht. Vaak uit de exacte wetenschappen (wiskunde, natuurkunde), maar ook uit bedrijfskunde en technische opleidingen (elektrotechniek, werktuigbouwkunde) kregen ze een eenmalige testopdracht of een tijdelijke rol in een project, of een overstap vanuit functioneel beheer, support of zelfs de businesskant. In ieder geval was niemand specifiek opgeleid als tester.
Omdat formele opleidingen tot tester vrijwel niet bestonden, was instroom meestal het resultaat van toevallige kansen of interne verschuivingen. Wat we gemeen hadden? Nieuwsgierigheid, analytisch vermogen en een gezonde dosis kritische blik. Het testvak bood de mogelijkheid om techniek te combineren met inzicht, communicatie en samenwerking en juist dát sprak deze diverse groep aan. Het was een periode waarin het vak booming was en veel hoogopgeleide professionals zich er vol overgave in stortten. Niet vanwege een studie die hen had voorbereid, maar omdat het werk inhoud, uitdaging en groeimogelijkheden bood. Daarmee ontstond langzaam maar zeker een nieuwe beroepsgroep: de testprofessional.
Een nieuw tijdperk voor testers
Waar softwaretesten in het verleden werd gezien als een noodzakelijk kwaad, werd het vakgebied in de jaren ’00 eindelijk serieus genomen. Testers werden niet langer beschouwd als secundaire spelers, maar als volwaardige professionals die essentieel waren voor het succes van softwareprojecten. Bedrijven beseften dat investeren in goed testen uiteindelijk tijd en geld zou besparen, wat leidde tot een bloeiende markt voor testprofessionals. De toenemende vraag zorgde voor een explosie aan bedrijven die zich specialiseerden in het leveren van testers aan andere organisaties. Grote namen als Sogeti, LogicaCMG, Polteq, Improve Quality Services, Ordina, Capgemini, Bartosz, Valori en QualityHouse (nu Centric) werden prominente spelers binnen de Nederlandse testwereld. Zij boden niet alleen detachering, maar investeerden ook actief in opleidingen, kennisdeling en innovatie.
Evenementen zoals de TMap-dagen, de Polteq Expert Meetups en TestNet-bijeenkomsten versterkten de onderlinge verbondenheid van de testgemeenschap. Testen was niet langer iets dat je er ‘even bij deed’, maar een vak met een eigen cultuur, normen en waarden.
In die periode begon ook mijn reis als testprofessional. Als tester bij de Postbank werkte ik aan het CRM-systeem (Siebel) voor internetbankieren. Een terrein waarop de Postbank destijds één van de voorlopers in Nederland was. Met een gezonde mix van nieuwsgierigheid en verantwoordelijkheidsgevoel stortte ik me op de kwaliteit van dit systeem dat duizenden klanten dagelijks zouden gaan gebruiken.
Naast mijn werk volgde ik in de avonduren een informaticaopleiding aan de Hogeschool van Amsterdam. Theorie en praktijk kwamen perfect samen, en niet lang daarna groeide ik door naar testcoördinator. In die rol begeleidde ik onder andere testtrajecten voor een hypotheekadvies applicatie, waarbij ik meerdere versies van begin tot eind heb meegemaakt.
Testbewustzijn in het onderwijs: een gemiste kans
Tijdens mijn studie aan de Hogeschool van Amsterdam werd mij al snel iets duidelijk: testen en kwaliteitszorg kwamen nauwelijks aan bod in het curriculum. Er werd stilzwijgend van uitgegaan dat beginnende ontwikkelaars vanzelf zouden begrijpen wat Quality Assurance en Quality Control inhielden. Maar expliciet onderwijs over deze cruciale onderwerpen ontbrak vrijwel volledig.
Een treffend voorbeeld hiervan speelde zich af in het tweede jaar van mijn studie, tijdens een project waarin we werkten volgens de DSDM-methode. Om de week kregen we begeleiding van externe docenten om samen de requirements scherp te krijgen.
Toen ik vroeg: “Welke eisen worden er gesteld aan het testen?”, kreeg ik als antwoord:
“Ga maar in de mediatheek kijken, daar vind je vast wel een boek over testen.”
Dat antwoord bevestigde mijn vermoeden: testen stond niet op het netvlies, noch bij de docenten, noch in het lesmateriaal.
Gelukkig wist ik vanuit mijn eigen testervaring wél hoe belangrijk kwaliteitszorg is — en dat heb ik tijdens dat project ook laten zien. We moesten een systeem bouwen gebaseerd op ITIL, met modules voor incident management en problem management. Binnen ons projectteam nam ik de rol van tester op me. Eén van mijn voorstellen was om een defectregistratiemodule in te bouwen, zodat teamleden ook op afstand incidenten konden loggen en volgen. Niet onbelangrijk, want het was 2002: internet werd net mainstream, maar samenwerken op afstand was nog verre van vanzelfsprekend.
Ik hield de testresultaten bij in een net rapport en tijdens de einddemonstratie presenteerden we het incidentmanagementsysteem. Helaas was de module voor problem management nog niet af. Na afloop kwam de docent naar me toe en zei:
“Ronald, leg me nou eens uit: hoe kan een product kwalitatief goed zijn, maar tóch ongeschikt zijn om in productie te nemen?”
Mijn antwoord was simpel maar fundamenteel:
“Wat er gebouwd is, werkt zoals bedoeld. Alle ernstige defecten zijn opgespoord en verholpen. De incidentmanagementfunctionaliteit voldoet aan de requirements. Maar omdat de module voor problem management ontbreekt, voldoet het systeem als geheel niet aan de afgesproken scope, en is het dus nog niet klaar voor productie.”
Die redenering maakte indruk. Onze groep kreeg een 8, terwijl andere groepen lager scoorden. Niet omdat ons product technisch superieur was, maar omdat we konden aantonen wat er werkte, wat niet, en waarom dat ertoe doet. Deze ervaring benadrukte voor mij nog maar eens: testkennis is niet optioneel, het is essentieel. En het verdient een stevigere plaats in elke IT-opleiding.
De opkomst van offshoring en globalisering van testen
Kostenbesparing en schaarste aan IT-talent leidden tot een nieuwe trend: offshoring. IT- en testwerkzaamheden werden steeds vaker uitbesteed aan landen als India. De term werd al snel gevolgd door afgeleiden als nearshoring (bijvoorbeeld naar Oost-Europa) en onshoring (uitbesteding binnen Nederland).
ABN AMRO was een van de eerste Nederlandse banken die haar volledige IT-organisatie naar India verplaatste. Andere financiële instellingen volgden snel. Binnen de ING Groep werd ook geherstructureerd, wat ik zelf heb mogen meemaken. Alle testafdelingen werden samengebracht tot één centrale organisatie: Test Services. Daar kreeg ik, na mijn afstuderen, de kans om als testmanager mee te bouwen aan de toekomst van het testvak en de afdeling.
In deze periode zette ik een opleidingsplan op voor een groep ontwikkelaars die boventallig dreigden te worden. We zagen in hen potentie voor het testvak, en met de juiste begeleiding konden zij een nieuw carrièrepad inslaan. De training die ik samen met andere collega’s ontwikkelde bleek zo succesvol dat Sogeti het model overnam en verder uitrolde.
Toen Test Services niet veel later in de etalage kwam te staan, besloot ik mezelf ook ‘te outsourcen’ en maakte ik de overstap naar CSC, een Amerikaans IT-bedrijf. In vijftien intensieve maanden werkte ik aan uiteenlopende opdrachten: bij Essent, bij de Rabobank, en aan een politiek gevoelig project binnen CSC zelf: als testmanager voor de Zorg Informatie Makelaar (ZIM).
De ZIM fungeerde als het digitale postkantoor van de zorg en was een cruciaal onderdeel van de nationale infrastructuur voor het elektronisch patiëntendossier (EPD), genaamd AORTA. De maatschappelijke druk, technische complexiteit en bestuurlijke gevoeligheid maakten het tot een van de meest veeleisende projecten in het begin van mijn loopbaan als test manager.
Kwaliteit vanaf het begin: de opkomst van testautomatisering
De roep om snellere levering én hogere kwaliteit leidde tot de doorbraak van testautomatisering.
De nadruk kwam te liggen op shift-left testing: testen vanaf het eerste moment in plaats van pas achteraf. Developers gingen zelf aan de slag met unittesten, ondersteund door tools als JUnit (Java), NUnit (.NET) en xUnit.
In deze periode ontstond ook Test Driven Development (TDD), waarbij je eerst de test schrijft, en daarna pas de functionele code. Dit idee, vooral bekend uit Extreme Programming (XP), zette de traditionele testvolgorde volledig op z’n kop en bracht testen dichter naar het ontwerp- en ontwikkelproces.
TDD legde op zijn beurt de basis voor Behavior Driven Development (BDD), waarin testscenario’s worden geschreven in begrijpelijke taal, de Gherkin syntax: “Given – When – Then”, zodat zowel ontwikkelaars als business stakeholders begrijpen wat er verwacht wordt. Tools als Cucumber en SpecFlow maakten deze samenwerking mogelijk.
Daarnaast werden de eerste serieuze stappen gezet in functionele testautomatisering:
- QuickTest Professional (QTP) – vanaf 2001 dé tool voor GUI-testen, met VBScript.
- Selenium(2004) – open-source en browser gebaseerd, snel een favoriet onder ontwikkelaars.
- FitNesse(2002–2005) – gericht op samenwerking tussen business en IT via begrijpelijke testdocumentatie.
Deze tools legden de basis voor geautomatiseerde regressietests en continue kwaliteitscontrole. De combinatie van testen aan de bron én automatisering aan het einde vormde een stevig fundament voor moderne testprocessen. Maar automatisering bleek ook complexer dan gedacht: testscripts waren onderhoudsgevoelig, tooling vereiste technische vaardigheden, en integratie met CI/CD stond nog in de kinderschoenen.
Metrieken en dashboards: testen wordt meetbaar
Met de groei van professionalisering kwam ook de behoefte aan stuurinformatie. Organisaties wilden inzicht in de effectiviteit van hun testinspanningen: hoeveel is er getest, hoeveel is er gevonden, wat is de testdekking? Testen moest niet alleen goed worden uitgevoerd, maar ook traceerbaar, reproduceerbaar en onderbouwd zijn.
Hiervoor verschenen steeds vaker dashboards en rapportages als vast onderdeel van testtrajecten. KPI’s zoals:
- Defect density
- Test coverage
- Aantal bevindingen open/gesloten
- TPI-niveau of volwassenheidsniveau
werden besproken in stuurgroepen en opgenomen in projectrapportages. Een belangrijke inspiratiebron voor veel testmanagers en projectleiders in die tijd was het boek “Goal, Question, Metric” van Rini van Solingen.
Deze methode hielp teams om meetbaar testen te koppelen aan concrete doelstellingen: welk doel wil je bereiken, welke vragen moet je stellen om daar zicht op te krijgen, en welke meetwaarden geven daar antwoord op? Het voorkwam dat er willekeurig gemeten werd, en bracht structuur in het gebruik van meetgegevens als sturingsinstrument.
Een belangrijke rol werd hierbij gespeeld door tools als TestDirector (van Mercury Interactive), dat later werd omgedoopt tot HP Quality Center. Deze tool groeide uit tot dé standaard voor testmanagement binnen grote organisaties. Het stelde teams in staat om testplannen, testscripts, defecten en rapportages centraal te beheren.
Het grote verschil met andere tools was de focus op inzicht en kwaliteit. Je kon per release of iteratie zien hoe het stond met de voortgang, en welke onderdelen al dan niet goed getest waren. Voor veel organisaties betekende dit een enorme stap in het structureel en transparant aansturen van testprocessen.
Van losse testen naar ketens en processen
Naast automatisering werden testers in toenemende mate geconfronteerd met de groeiende complexiteit van IT-landschappen.
Systemen raakten steeds meer met elkaar verweven. Fouten beperkten zich niet langer tot één applicatie, maar konden doorwerken in complete bedrijfsprocessen. Hierdoor ontstond de noodzaak voor ketentesten en end-to-end testen. Tegelijkertijd begon het service-oriented architecture (SOA) aan populariteit te winnen: systemen communiceerden via gestandaardiseerde services en API’s, vaak in XML of SOAP.
Voor testers betekende dit dat integratietesten ingewikkelder werden. Er was niet altijd een GUI beschikbaar waarmee kon worden getest; tools zoals SoapUI en custom scripts werden ingezet om de onderliggende services te valideren. Testers moesten technisch onderlegd zijn, abstract kunnen denken én samenwerken met ontwikkelaars op een dieper niveau. Dit was voor velen een grote omslag.
In mijn werk kwam dit telkens terug. Testen betekende niet meer alleen ‘iets aan de voorkant controleren’, maar ook begrijpen hoe gegevensstromen door CRM-systemen, backoffice, middleware en rapportageketens liepen. Testers moesten breed denken, integraal samenwerken en gevoel krijgen voor bedrijfslogica. In 2009 speelde Sogeti hier handig op in door het boek Testen van ketens met TMap NEXT uit te geven.
Nieuwe omgevingen, nieuwe culturen
Mijn overstap naar de KLM, dat inmiddels onderdeel was van Air France, bracht me voor het eerst in een internationale context. In mijn eerste project werkte ik samen met collega’s van Air France. Hoewel we geografisch en cultureel soms wat van elkaar verschilden, leerden we gezamenlijk hoe belangrijk duidelijke communicatie en gedeeld kwaliteitsbesef zijn, zeker binnen grote, internationaal aangestuurde IT-trajecten.
Mijn eerste zakenreis naar Parijs klonk spannend, maar bestond uit vroeg opstaan, vliegen, vergaderen in een raamloze ruimte, en dezelfde avond weer terug. Geen croissant bij de Eiffeltoren dus, maar wél een waardevolle les in internationale samenwerking.
Ontwikkelmethodieken en technologische innovaties: testen in een stroomversnelling
Het was niet alleen het testvak dat zich ontwikkelde — de hele IT-sector zat midden in een transformatie. Nieuwe ontwikkelmethodieken en technologische innovaties hadden directe impact op hoe, wat en wanneer er getest moest worden. Voor testers betekende dit: continu aanpassen, bijleren en soms zelfs vooroplopen.
De doorbraak van Agile
Een van de grootste veranderingen was de introductie van het Agile Manifesto in 2001. Waar eerder werd gewerkt in lineaire watervalmodellen, brachten Scrum, XP en later Kanban een nieuwe manier van denken. Software werd in korte iteraties ontwikkeld, klantfeedback werd leidend, en multidisciplinaire teams kwamen centraal te staan. Voor testers betekende dit een fundamentele rolwijziging:
- Van een afgebakende testfase naar een voortdurende testactiviteit in elke sprint.
- Van documentgedreven naar samenwerkend en interactief.
- Van controleur aan het eind naar meedenker aan het begin.
Nieuwe technologieën, nieuwe testuitdagingen
Naast methodieken en architectuur veranderde ook de technologie zelf snel. Webapplicaties werden complexer dankzij technieken zoals AJAX, waardoor content dynamisch werd geladen zonder de pagina te verversen. Dit maakte GUI-testen lastiger: timing, DOM–validatie en asynchroniciteit werden nieuwe aandachtspunten.
Rond 2007 maakte ook het mobiele testen zijn intrede, met de lancering van de eerste iPhone en de opkomst van Android. Hoewel mobiel nog geen dominante markt was, begonnen testers zich voor te bereiden op platformfragmentatie, resolutieverschillen en touch-interactie. Er ontstonden de eerste rudimentaire frameworks om mobiele apps te testen, maar veel gebeurde nog handmatig op fysieke toestellen.
Daarnaast maakten tools als VMware het mogelijk om eenvoudig testomgevingen te virtualiseren. Dit had een directe impact op het testvak: testers konden nu eigen omgevingen beheren, snapshots maken en reproduceerbare tests draaien, zonder afhankelijk te zijn van IT-beheer.
Non Functionele Requirements krijgen een prominente plek Ongeveer 2005 verschoof de aandacht binnen het testvak steeds nadrukkelijker van puur functioneel testen naar het borgen van non-functionele kwaliteitseisen, oftewel: Non Functional Requirements (NFR).
Deze eisen bepaalden niet wat een systeem moest doen, maar hoe goed het dat moest doen: veilig, betrouwbaar, schaalbaar, beschikbaar en controleerbaar.
De toegenomen druk op compliance, mede veroorzaakt door de dotcomcrisis, financiële schandalen en nieuwe wet- en regelgeving zoals de Sarbanes-Oxley Act (SOX) vanaf 2002, maakte duidelijk dat softwarekwaliteit méér betekende dan alleen het goed uitvoeren van functionaliteiten.
Testers kregen steeds vaker te maken met non-functionele vraagstukken zoals:
- Auditability – Zijn processen, resultaten en beslissingen aantoonbaar en herleidbaar?
- Security testing – Zijn gegevens goed beschermd tegen aanvallen zoals SQL-injectie of cross-site scripting (XSS)?
- Authorisatie- en toegangscontrole – Krijgen alleen bevoegde gebruikers toegang tot gevoelige informatie?
- Load & Performance – Hoe reageert het systeem onder piekbelasting?
Waar deze onderwerpen voorheen vooral de zorg waren van architecten of security-afdelingen, werden ze nu ook expliciet onderdeel van testtrajecten. Hoewel er nog weinig gespecialiseerde NFR-testers waren, begonnen steeds meer testteams met het ontwikkelen van expertise op dit vlak.
Deze verbreding van het testvak betekende ook dat testers nauwer moesten samenwerken met disciplines als infrastructuur, informatiebeveiliging en business compliance. Het testen van non-functionele eisen groeide uit tot een volwaardig aandachtsgebied, en werd een onmisbare schakel in het aantonen van de totale softwarekwaliteit.
Nieuwe methodieken en boeken: TMap Next, Testbeleid, TPI, TMMi en RRBT
De testpraktijk professionaliseerde, en daarmee groeide ook de behoefte aan methodieken die aansloten bij moderne organisaties. In 2006 verscheen het boek TMap Next, een vernieuwde versie van de oorspronkelijke TMap-aanpak. Ook het boek Testgrip, uitgebracht door LogicaCMG, introduceerde een praktisch model waarin testbeleid niet op zichzelf staat, maar direct voortkomt uit de bedrijfsstrategie. Het bood organisaties structuur om testaanpak, -organisatie en tooling gecoördineerd in te richten. TestGrip benoemde drie soorten testorganisaties: project-, staf- en lijnorganisaties, met ruimte voor hybride vormen. Hiermee groeide testbeleid uit tot een strategisch instrument, niet alleen op projectniveau, maar organisatiebreed.
In 1998 verscheen al het boek Test Process Improvement (TPI), geschreven door Martin Pol en Tim Koomen. Dit model bood een gestructureerde aanpak om de volwassenheid van testprocessen te meten en verbeteren, vergelijkbaar met CMMI. In 2009 werd een herziene uitgave uitgebracht TPI NEXT – Business Dirven Test Process Improvement
Bij Test Services van ING, waar ik in die jaren actief was, had het testvak een relatief hoge volwassenheid. Dit kwam onder andere doordat testadviseurs structureel TPI-metingen uitvoerden bij projecten waar testmanagers bij betrokken waren. Het resultaat van deze metingen was dat als de volwassenheid kleiner was dan drie, de test managers opdracht kregen minimaal level drie te gaan halen. Eens per zes weken werden nieuwe assessments uitgevoerd en via dashboards werd bijgehouden waar projecten stonden in hun verbetertraject.
Een waardevolle aanpak, al zat er ook een keerzijde aan: de verbeteracties werden opgenomen in je jaarlijkse targets. En dan kon het wel eens knellen, zeker als die verbeteringen buiten je directe invloed lagen. Toch heeft deze aanpak het testvak binnen ING naar een hoger niveau getild. Niet alleen op papier, maar vooral in de praktijk.
In 2007 werd daarnaast het internationale TMMi-model (Test Maturity Model integration) officieel gelanceerd door de TMMi Foundation. TMMi bouwde voort op de filosofie van CMMI, maar was volledig gericht op testprocessen. Het model introduceerde vijf volwassenheidsniveaus en bood een raamwerk waarmee organisaties hun testprocessen konden auditen, benchmarken en verbeteren. Waar TPI vooral populair bleef in Nederland en West-Europa, groeide TMMi uit tot een internationale standaard — met adoptie in onder andere Azië, de VS en het Midden-Oosten.
Voor organisaties die behoefte hadden aan meer flexibiliteit en toepasbaarheid binnen complexe omgevingen, ontwikkelde Valori de methodiek SmarTest. Deze aanpak legde de nadruk op contextafhankelijk testen, met praktische kaders en wendbaarheid voor teams. SmarTest bood een alternatief voor meer traditionele modellen en werd met succes ingezet binnen uiteenlopende sectoren.
Ook binnen het hoger onderwijs groeide de behoefte aan toegankelijke en praktijkgerichte testmethoden. Als antwoord daarop verscheen het boek TestGoal van Derk-Jan de Grood. Dit boek was speciaal geschreven voor studenten in het HBO en bood een toegankelijke introductie in het testvak, met praktijkvoorbeelden, oefeningen en heldere uitleg. Het sloeg een brug tussen theorie en praktijk en werd op diverse opleidingen breed omarmd.
Tot slot verscheen in deze periode ook het boek Successful Test Management van Iris Pinkster en Bob van de Burgt. Hierin werd de methodiek Risk & Requirement Based Testing (RRBT) gepresenteerd, een aanpak waarbij testinspanning wordt afgestemd op zowel risico’s als de prioriteit van requirements. RRBT bracht een duidelijke structuur in hoe je teststrategieën kunt baseren op bedrijfsbelang en risicobeheersing. Het sloot daarmee perfect aan op de bredere beweging in het testvak richting contextgedreven en risicogestuurd testen.
Samen boden TMap Next, TestGrip, TPI, TMMi, RRBT, SmarTest en TestGoal een rijk en veelzijdig palet van methodieken, van strategisch tot operationeel, van klassikaal tot agile, en van bedrijfsbreed tot onderwijskundig. Hiermee werd een stevige basis gelegd voor verdere professionalisering van het testvak, in organisaties én het onderwijs.
Certificering als bewijs van vakbekwaamheid
Professionalisering vroeg om aantoonbare competenties. In 2002 werd het ISTQB opgericht, gevolgd in 2004 door het regionale BNTQB. Daarmee ontstond een wereldwijd erkende certificeringsstructuur met modules voor test engineers, test managers en specialisten.
Ook TMap ontwikkelde certificeringen: eerst de TMap Professional, later omgevormd tot TMap Next Advanced. Deze certificaten boden testers een leerpad én een kwaliteitslabel, en werden in Nederland breed gedragen.
Zelf behaalde ik in deze periode het TMap Professional Advanced-certificaat, gevolgd door het ISTQB Foundation-certificaat. Die certificeringen boden niet alleen inhoudelijke verdieping, maar gaven ook een duidelijk signaal af: testen was geen bijzaak meer, maar een vakgebied waarin je je professioneel kon ontwikkelen.
Alternatieve benaderingen: context gedreven en exploratory testing
Tegenover de procesmatige benaderingen zoals TMap, TPI en ISTQB, ontstond er begin jaren 2000 ook een alternatieve teststroming: context-driven testing. Grote namen als James Bach en Cem Kaner pleitten voor een flexibelere testaanpak, waarbij je je keuzes als tester laat afhangen van de context, het risicoprofiel en het team.
Een belangrijk onderdeel van deze benadering was exploratory testing: een interactieve, spontane vorm van testen waarin je leert terwijl je test. In plaats van vooraf gescripte testcases te volgen, gebruik je je ervaring, creativiteit en onderzoekend vermogen om fouten te vinden.
In agile omgevingen, waar requirements veranderlijk waren en feedback snel moest, sloot deze aanpak goed aan. Hoewel het minder breed werd geïmplementeerd in grote organisaties, vormde het een waardevolle aanvulling op traditionele methodes.
Veranderende verwachtingen van testers
Al deze ontwikkelingen (globalisering, agile, automatisering, ketentesten en certificering) leidden ertoe dat van testers steeds meer werd gevraagd. Waar ze vroeger vooral werden ingezet om fouten op te sporen, werd nu van hen verwacht dat ze diepgaande kennis hadden van processen, tooling, samenwerking en kwaliteitsborging.
Testers kregen een bredere verantwoordelijkheid: ze moesten actief bijdragen aan elke fase van softwareontwikkeling, van planning tot oplevering. Hun rol verschoof van uitvoerder naar adviseur, van controleur naar kwaliteitsregisseur.
Dit betekende dat testers hun vaardigheden voortdurend moesten bijschaven en trainen. Het volgen van opleidingen en behalen van certificaten (zoals ISTQB en TMap Next) werd steeds belangrijker, wat de markt voor testtrainingen en -certificeringen een flinke boost gaf.
De impact van Nederland op testen
Nederland bleef vooroplopen. De testcommunity in ons land was levendig, professioneel en goed georganiseerd. De combinatie van sterke methodologische kennis, brede opleidingsmogelijkheden en een bloeiend netwerk van testprofessionals zorgde ervoor dat Nederland internationaal werd erkend als een kennisland op het gebied van softwaretesten.
Een decennium van groei en verandering
De jaren 2000 tot 2009 waren cruciaal voor het vakgebied softwaretesten. Het vak groeide uit tot een volwassen discipline met een eigen infrastructuur, methodologieën, certificeringen en gemeenschappen. En hoewel er veel veranderde, bleef één ding hetzelfde: zonder goed testen geen betrouwbare software.
In het volgende artikel gaan we verder met hoe deze ontwikkelingen zich in het daaropvolgende decennium voortzetten, en hoe Nederland ook daarin een cruciale rol bleef spelen.
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).
Artikel 4 van deze reeks: De opkomst van de Testprofessional (jaren 2000/2009) (dit artikel)
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)