Quality Engineering · artikel
Van Test Automation naar Quality Engineering
Inhoudelijke verandering of alleen een nieuwe functietitel?
Quality Engineering begint niet wanneer een tester een nieuwe titel krijgt. Het begint wanneer kwaliteit eerder wordt ontworpen, feedback doelgerichter wordt ingericht en professionals werkelijk invloed krijgen op technische beslissingen.
De functietitel verandert. Gisteren stond er Test Automation Engineer in je profiel. Vandaag noemt de organisatie je Quality Engineer.
Je werkzaamheden? Je onderhoudt dezelfde regressiesuite. Je wordt laat in de sprint betrokken. De architectuur ligt vast. Testdata blijft moeilijk beschikbaar en wanneer de planning onder druk staat, worden kwaliteitsrisico’s buiten het team geaccepteerd.
Een nieuwe functietitel verandert nog geen systeem, geen verantwoordelijkheid en geen kwaliteitsbeslissing.
De verschuiving is pas echt wanneer kwaliteit niet hoofdzakelijk wordt gecontroleerd nadat software is gebouwd, maar bewust wordt ontworpen gedurende de volledige softwarelevenscyclus.
Welke kwaliteitsbeslissing kan vandaag aantoonbaar eerder, beter of betrouwbaarder worden genomen dan vóór de verandering?
De grens van automatisering
Waarom Test Automation alleen niet genoeg is
Test Automation maakt snelle, herhaalbare feedback en integratie met CI/CD mogelijk. Maar een test kan alleen iets zeggen over gedrag dat technisch bereikbaar, observeerbaar en van bruikbare data voorzien is.
Een slecht testbaar systeem wordt niet goed testbaar door er meer scripts omheen te bouwen.
Een onduidelijke requirement wordt niet scherper doordat AI er twintig testgevallen voor genereert.
Een instabiele omgeving wordt niet betrouwbaar door failures automatisch opnieuw uit te voeren.
Een architectonisch risico verdwijnt niet doordat de regressiesuite groen is.
Test Automation kan uitstekend uitvoeren wat een organisatie heeft besloten te controleren. Zij bepaalt niet vanzelf of de juiste risico’s zijn gekozen en of het systeem goed is ontworpen.
Kwaliteit over de lifecycle
Wat Quality Engineering werkelijk toevoegt
Quality Engineering behandelt softwarekwaliteit als een eigenschap van het volledige ontwikkel- en leveringssysteem. De juiste feedback moet beschikbaar zijn op het moment dat een team er nog effectief op kan handelen.
Ontwerp
Risico’s, kwaliteitseigenschappen, testbaarheid, data en observeerbaar gedrag bepalen.
Ontwikkeling
Gerichte controles, stabiele contracten, diagnose en snelle feedback organiseren.
Deployment
Quality gates, uitzonderingen, gecontroleerde rollouts en herstelmogelijkheden inrichten.
Productie
Werkelijk gebruikersgedrag, incidenten en telemetry terugbrengen naar eerdere feedbacklagen.
| Test Automation-focus | Quality Engineering-focus |
|---|---|
| Tests uitvoeren | Kwaliteitsrisico’s beheersen |
| Automatisering na implementatie | Testbaarheid vanaf ontwerp |
| Focus op de testsuite | Focus op de volledige feedbackketen |
| Pass/fail-resultaten | Informatie voor beslissingen |
| Testomgeving als primaire bron | Pre-productie én productiefeedback |
| Framework als technisch centrum | Platform, data, observability en governance |
Titelinflatie herkennen
Vier signalen dat Quality Engineering vooral rebranding is
Verantwoordelijkheid zonder mandaat
De Quality Engineer wordt verantwoordelijk gehouden, maar pas betrokken nadat belangrijke ontwerpbeslissingen zijn genomen.
Gedeeld maar niet georganiseerd
Iedere discipline doet iets aan kwaliteit, terwijl niemand de samenhang tussen risico’s en feedback bewaakt.
Nieuw platform, oude besluitvorming
Tooling verandert, maar risicoacceptatie, eigenaarschap, data en uitzonderingsprocessen blijven hetzelfde.
Aantallen blijven de norm
Succes wordt nog steeds gemeten in tests, automationpercentages en uitgevoerde controles.
De technische basis
De verschuiving begint bij testbaarheid
Testbaarheid is het vermogen om efficiënt te kunnen waarnemen, sturen en beoordelen wat een systeem doet. Dat wordt zichtbaar in concrete ontwerpkeuzes.
- Duidelijke componentgrenzen en stabiele interfaces.
- Voorspelbare statusovergangen en beheersbare afhankelijkheden.
- Bruikbare logging, metrics en distributed tracing.
- Controleerbare feature flags en rolloutmechanismen.
- Reproduceerbare, veilige en toegankelijke testdata.
- Fouten die voldoende diagnostische informatie opleveren.
Hoe automatiseren we dit systeem?
Hoe ontwerpen we het systeem zodat betrouwbaar gedrag snel kan worden beoordeeld?
Van suite naar systeem
De testsuite wordt onderdeel van een feedbackarchitectuur
In een Quality Engineering-model is de regressiesuite één van meerdere informatiebronnen. Andere bronnen zijn codeanalyse, component- en contracttests, securityscans, performancecontroles, deploymentvalidatie, telemetry, incidenten en gebruikerssignalen.
Gericht en vroeg, maar met beperkte systeemcontext.
Bewaken samenwerking tussen componenten en services.
Meer integratie, maar trager en moeilijker te diagnosticeren.
Toont echte omstandigheden, nadat software is uitgerold.
Observability vervangt tests niet. Het laat zien waar tests, modellen en verwachtingen onvolledig waren.
Een sociotechnisch systeem
Gedeeld eigenaarschap moet expliciet worden ontworpen
Kwaliteitsuitkomsten worden niet alleen door techniek beïnvloed. Teamgrenzen, incentives, tijdsdruk, bevoegdheden en toegang tot expertise bepalen welke risico’s zichtbaar worden en wie erop kan handelen.
Bezit de kwaliteit, levering en operationele signalen van de eigen dienst.
Versterkt risicoanalyse, testontwerp, automation, diagnostiek en feedback.
Bewaakt samenhang, standaarden, expertise en structurele belemmeringen.
Levert selfservice-capabilities voor pipelines, data, omgevingen en observability.
Bepaalt kaders, kwaliteitseigenschappen en samenhang over systemen heen.
Maakt risicotolerantie, investeringsprioriteiten en uitzonderingen expliciet.
Centraliseren zonder bottleneck
Een Quality Engineering-platform is pas waardevol wanneer teams er zelfstandiger van worden
Gedeelde frameworks, testdata-as-a-service, omgevingen en observability kunnen schaalvoordeel opleveren. Maar centralisatie vertraagt wanneer iedere wijziging via één team loopt of standaarden geen ruimte laten voor domeinverschillen.
Welke complexe kwaliteitsactiviteit kunnen productteams hierdoor veiliger, sneller en zelfstandiger uitvoeren?
Begin niet met een allesomvattend quality-platform. Begin met een bewezen gedeeld probleem, zoals veilige testdata, contracttesting, pipelinefeedback of toegankelijke performancecontroles.
Activiteit is geen uitkomst
Hoe meet je Quality Engineering?
Hoe snel ontstaat bruikbare feedback?
Doorlooptijd, wachttijd, tijd tot diagnose en tijd tot eerste betekenisvolle feedback.
Hoe betrouwbaar verloopt verandering?
Mislukte deployments, hersteltijd, flaky tests en onbetrouwbare gates.
Worden relevante risico’s zichtbaar?
Defect escapes, incidenten, herhaalde foutcategorieën en ontbrekende feedback.
Blijft het systeem beheersbaar?
Automationonderhoud, duplicatie, frameworkwijzigingen en ongebruikte tests.
Wat merkt de gebruiker?
Kritieke journeys, ervaren performance, klachten en operationele schade.
Snelheid zonder stabiliteit is geen volwassen levering. Stabiliteit zonder verandervermogen evenmin.
De impact op jouw loopbaan
Wat verandert dit voor jouw ervaringsniveau?
Verbreed je technische basis
Ontwikkel testontwerp, API’s, CI/CD, logging, diagnose, testdata en non-functionele kwaliteit.
Ontwerp de samenhang
Herken waar feedback te laat komt, tests verkeerd zijn geplaatst en architectuur testbaarheid belemmert.
Maak mandaat expliciet
Verbind teams, standaarden, metrics, centrale capabilities en structurele investeringen.
Ontwerp het kwaliteitslandschap
Verbind delivery, data, observability, security, performance, resilience, compliance en platformengineering.
De beslissende test
Is Quality Engineering bij jullie al een nieuwe werkelijkheid?
- Wanneer werden de kwaliteitsrisico’s besproken?
- Wie kon het ontwerp nog beïnvloeden?
- Welke feedback was als eerste beschikbaar?
- Welke onzekerheid bleef bestaan?
- Wie besloot dat die onzekerheid acceptabel was?
- Wat werd na productie geleerd?
- Welke structurele verbetering volgde daaruit?
Als het antwoord vooral verwijst naar de regressiesuite en de Quality Engineer die deze beheert, is de transformatie nog niet voltooid.
De opgebouwde lijn
Van marktontwikkeling naar een volwassen kwaliteitssysteem
De markt wordt selectiever en testproductie alleen is minder onderscheidend.
AI levert waarde wanneer professionals verantwoordelijk blijven voor beoordeling.
Agentic testing vraagt expliciete technische grenzen en bevoegdheden.
Quality Engineering verbindt feedback, eigenaarschap en beslissingen over de lifecycle.
Onderbouwing
Bronnen en onderzoeksafbakening
Quality Engineering kent geen universeel organisatiemodel of overal geaccepteerde functiedefinitie. Dit artikel beoordeelt QE daarom op waarneembare verantwoordelijkheden, capabilities en feedbackmechanismen.
- Capgemini, Sogeti en OpenText — World Quality Report 2025–2026
- DORA — Software delivery performance metrics
- DORA — Test automation capability
- DORA — Researchprogramma
- DORA — Impact of Generative AI in Software Development
- Martin Fowler — Software Testing Guide
- Martin Fowler — The Practical Test Pyramid
- Team Topologies — Key concepts