AI voor shift-left testing: betere specificaties, minder fouten achteraf

Bram Nijhoff
03-03-2026
09:31

Veel teams willen snel functionaliteit opleveren, maar starten met onvolledige of onduidelijke requirements (eisen). Dat leidt vroeg of laat tot herwerk, vertraging en onnodige risico’s. De norm ISO/IEC/IEEE 29148 beschrijft dat goede requirements ondubbelzinnig, verifieerbaar, traceerbaar en testbaar moeten zijn: er mag dus maar één interpretatie mogelijk zijn, je moet kunnen aantonen dat eraan voldaan is, je moet ze kunnen herleiden en je moet ze kunnen testen.

Met shift-left testing brengen we deze kwaliteit veel eerder in beeld: we maken eisen concreet, controleerbaar en uitvoerbaar nog vóór er code is geschreven. Continuous integration en continuous delivery (CI/CD) verlagen soms de kosten van late fixes, maar het basisprincipe blijft overeind: hoe later je een fout vindt, hoe groter meestal de impact op planning, kosten en risico, al is dit geen natuurwet en blijft het contextafhankelijk.

Dit artikel laat zien hoe je AI inzet om al vóór de bouwfase ambiguïteit uit requirements te halen, risico’s expliciet te maken en bewijs (evidence) op te bouwen. We combineren AI‑ondersteunde requirements‑review, risicogestuurde testopdrachten, uitvoerbare specificaties en “agentic AI” (AI‑agents die zelfstandig taken uitvoeren, maar altijd onder menselijk toezicht). Het resultaat is aantoonbaar bewijs in de vorm van testruns, rapporten en een audittrail die herleidbaar is naar requirements en releases, wat zowel de kwaliteit als de governance ondersteunt.

Een concreet voorbeeld: autorisatie en datatoegang

Neem een API die bestellingen en betaalgegevens ontsluit. Je wilt voorkomen dat gevoelige data per ongeluk uitlekt via foutmeldingen. Daarom leg je in je API‑contract heel expliciet vast welk foutgedrag is toegestaan.

Beleid voor foutcodes in dit domein:

403 Forbidden (wel bestaande resource, maar onvoldoende rechten): de response‑body bevat alleen een foutobject met een code en een boodschap, en dus geen velden van de resource zelf.
404 Not Found (resource bestaat niet): ook hier alleen een foutobject, nooit resourcevelden.

Als je dit beleid eenmaal hebt vastgesteld, hanteer je het consequent in je scenario’s. In Gherkin (een leesbare vorm van testspecificatie met Given/When/Then) kun je dat als volgt uitwerken:

				
					Functionaliteit: Checkout-autorisatie en datatoegang

  Achtergrond:
    Given een ingelogde gebruiker met rol "Koper" genaamd "Alice"
    Given een andere ingelogde gebruiker met rol "Koper" genaamd "Bob"
    Given een ingelogde gebruiker met rol "Beheerder" genaamd "Admin"

  Scenario: Alleen de eigenaar ziet eigen order- en betaalGivens
    Given "Alice" plaatst een order met order_id "O-123" en betaal_id "P-123"

    When "Alice" order "O-123" ophaalt
    Then is de statuscode 200
    Then bevat de body het volledige bedrag en de betaalstatus

    When "Bob" order "O-123" ophaalt
    Then is de statuscode 403
    Then bevat de body geen resourcevelden (alleen foutobject met code en boodschap)

  Scenario: Beheerder ziet gemaskeerde weergave bij orderinzage
    Given "Alice" plaatst een order met order_id "O-124" en betaal_id "P-124"
    When "Admin" order "O-124" ophaalt
    Then is de statuscode 200
    Then is het kaartnummer gemaskeerd als "****1234"
    Then is de IBAN gemaskeerd als "NL** **** **** **** 1234"
    Then zijn de adresregels gemaskeerd als "********" (geen leesbare tekens)

  Scenario: Volledige betaalGivens alleen via audit-endpoint
    Given een geautoriseerde beheerder met rol "Beheerder" en het recht "AuditLezen"
    When de beheerder betaalGivens voor "P-124" ophaalt via het audit-endpoint
    Then is de statuscode 200
    Then bevat de body de volledige betaalGivens

  Scenario: Auditlogging en least privilege op audit-endpoint
    Given een gebruiker zonder het recht "AuditLezen"
    When deze gebruiker het audit-endpoint aanroept voor "P-124"
    Then is de statuscode 403
    Then wordt er een auditrecord weggeschreven met aanvrager_id en reden "Onvoldoende rechten"
    Then kan uitsluitend een rol met minimaal benodigde rechten het audit-endpoint succesvol gebruiken

Dit voorbeeld laat zien hoe je functionele eisen (wie mag wat zien) en beveiligingseisen (minimale rechten, auditlogging, datamasking) concreet en testbaar maakt. De tekst is begrijpelijk voor business en ontwikkelaars, en is tegelijk direct uitvoerbaar als testspecificatie.

Van “vroegtijdig testen” naar “aantoonbaar vooraf”

Bij veel organisaties betekent shift-left vooral “zo vroeg mogelijk testen”. In deze aanpak gaan we een stap verder en richten we ons op “aantoonbaar vooraf”: je levert al vóór de bouwfase bewijs dat je eisen helder, toetsbaar en uitvoerbaar zijn.

Dat betekent onder andere:

Niet alleen testactiviteiten naar voren halen, maar ook de kwaliteit van requirements aantoonbaar maken vóór code.
Bewust evidence verzamelen (bijvoorbeeld scenario’s, testruns in een prototype, reviews) en dat koppelen aan governance: wie heeft wat beoordeeld en waarom.

Deze werkwijze bouwt voort op bekende praktijken zoals requirements‑engineering, risk‑based testing (testen op basis van risico) en continue verificatie (doorlopende controle dat je systeem nog steeds voldoet aan eisen). Binnen shift-left testing vormen deze elementen samen een stevige basis.

De kern bestaat uit vier bouwstenen:

AI‑ondersteunde requirements‑review
Risicogestuurde testopdrachten (test charters)
Uitvoerbare specificaties (zoals BDD, property‑based testing en contracttests)
Agentic AI met duidelijke vangrails voor menselijk toezicht, compliance en traceerbaarheid

Alles is tool‑onafhankelijk en gericht op auditbaarheid. Evidence leg je vast via stabiele requirement‑ID’s, gelinkte tests, testruns, releasetags en expliciete approvals, zodat een auditor end‑to‑end kan volgen wat besloten is en op basis waarvan.

AI voor betere eisen: ambiguïteit, consistentie en NFR’s

Grote taalmodellen (LLM’s) kunnen structureel helpen bij het verbeteren van de kwaliteit van je requirements. Zo kunnen ze vaag taalgebruik markeren (“snel”, “gebruiksvriendelijk”, “indien nodig”), ontbrekende acceptatiecriteria signaleren en inconsistenties in terminologie blootleggen (bijvoorbeeld “gebruiker” in het ene document en “klant” in het andere). Dit noemen we AI ambiguity detection: AI‑gestuurde ambiguïteitsdetectie.

Belangrijk is dat AI de review versnelt, maar niet vervangt: jij blijft verantwoordelijk voor de inhoudelijke juistheid in jouw domein en neemt de beslissingen. Daarom blijft human‑in‑the‑loop standaard: AI geeft suggesties, de mens keurt goed. Links of beslissingen die AI voorstelt, worden nooit geaccepteerd zonder onderliggende bron‑evidence.

Niet‑functionele requirements (NFR’s) zijn kwaliteitseisen die niet over functionaliteit gaan, maar over aspecten als prestatie, beveiliging, privacy, betrouwbaarheid, onderhoudbaarheid en toegankelijkheid. Deze NFR’s verdienen dezelfde aandacht als functionele eisen: maak ze meetbaar en testbaar.

Compacte checklist voor requirements‑review (ISO/IEC/IEEE 29148)

Ondubbelzinnig: één interpretatie, ondersteund door duidelijke definities en een consistente termenlijst.
Verifieerbaar en testbaar: concreet geformuleerde acceptatiecriteria in Given/When/Then‑vorm, of meetbare NFR’s.
Traceerbaar: elk requirement heeft een eigen ID, versie, rationale (onderbouwing) en een eigenaar.
NFR’s expliciet: prestatie, beveiliging, privacy, betrouwbaarheid, onderhoudbaarheid en toegankelijkheid zijn benoemd én meetbaar gemaakt.
Toegankelijkheid: borg WCAG‑criteria al vroeg, inclusief toetsenbordnavigatie, focusvolgorde, ARIA‑labels en een hoog‑contrast thema; AI kan hier checks versnellen, maar eindvalidatie gebeurt met echte hulpmiddelen zoals screenreaders.
Compliance en audit: denk aan bronverwijzing, dataclassificatie, bewaartermijnen (retentie) en auditvelden.

Een voorbeeld van “voor” en “na” AI‑feedback:

Voor: “Het dashboard laadt snel en is gebruiksvriendelijk.”
Na: “Het dashboard rendert binnen 2 seconden bij 95% van de aanvragen (P95) bij 200 requests per seconde op een dataset die lijkt op productie, gemeten in pre‑productie. De pagina ondersteunt volledige toetsenbordnavigatie en een correcte focusvolgorde volgens WCAG. Een hoog‑contrast thema is selecteerbaar en volledig ondersteund.”

In de verbeterde versie is helder wat “snel” en “gebruiksvriendelijk” betekenen, en kun je het koppelen aan een requirement‑ID (bijvoorbeeld REQ‑201) en bijbehorende scenario’s. Leg deze uitkomst vast in je eigen requirements‑reviewchecklist, zodat de herleidbaarheid behouden blijft.

Traceerbaarheid en valkuilen met AI

Traceerbaarheid betekent dat je van requirement naar tests en releases kunt lopen, en andersom. In de basis gaat het om:

Stabiele ID’s (zoals REQ‑123) met versies.
Links naar scenario’s, testruns en releases.
Evidence, rationale, approvals en wijzigingshistorie gekoppeld aan tickets en releasenotes.

AI kan helpen door automatisch suggesties te doen voor trace‑links, bijvoorbeeld tussen requirements, tests en documentatie. Menselijke reviewers beoordelen en keuren deze links, en controleren op “hallucinaties”: AI kan immers soms een link verzinnen die niet klopt. Accepteer daarom geen link zonder controle van bron en bewijs, zoals een testrapport of CI‑run waaruit de relatie duidelijk blijkt.

Belangrijke valkuilen en bijbehorende mitigaties:

Hallucinaties, bias en overmatig zelfvertrouwen van AI: verplicht een menselijke sign‑off en registreer wijzigingen.
Beveiligingsvalidatie: toets tegen een standaard zoals OWASP Application Security Verification Standard (ASVS) en intern beveiligingsbeleid.
Testinflatie (“vibe testing”): genereer niet massaal generieke tests zonder koppeling aan risico’s of requirements; veel tests zonder focus leveren weinig extra waarde op en kosten vooral tijd.

Door deze valkuilen expliciet te adresseren, voorkom je dat AI‑ondersteuning onbedoeld leidt tot schijnzekerheid.

Prestatie en toegankelijkheid als uitvoerbare eisen

Ook niet‑functionele eisen kun je als uitvoerbare specificatie beschrijven. Onderstaand Gherkin‑scenario maakt de prestatie‑eis (P95 laadtijd) én toegankelijkheidseisen concreet:

				
					Functionaliteit: Dashboard-prestatie en toegankelijkheid
  # Requirement REQ-201
  Scenario: P95 laadtijd onder 2 s bij 200 RPS, toetsenbordtoegankelijkheid en hoog-contrast
    Given een synthetische workload van 200 RPS op "/dashboard" met production-like data
    When de test 10 minuten draait met warme cache
    Then is de P95 responstijd ≤ 2 s volgens APM-traces
    Then ondersteunt de pagina volledige toetsenbordnavigatie conform WCAG
    Then is een hoog-contrast thema selecteerbaar en volledig ondersteund

Hiermee is precies vastgelegd welke prestatie je verwacht, onder welke omstandigheden, en hoe je dat meet (via APM‑traces). Tegelijk baken je de toegankelijkheidsvereisten af, zodat de test niet alleen over snelheid gaat, maar ook over bruikbaarheid voor iedereen.

Risicogestuurd testen met AI: van risico naar testopdracht

Risk‑based testing (risicogestuurd testen) komt neer op: je prioriteert je testen op basis van impact maal waarschijnlijkheid. Je richt je dekkingskeuzes vooral op nieuwe of complexe functionaliteit, koppelingen met derden, gevoelige data, autorisatiepaden en verwachte piekbelasting.

AI kan je hierbij ondersteunen door vroegtijdig kandidaat‑testopdrachten (test charters) en dekkingssuggesties te genereren, inclusief beveiligingsaspecten (bijvoorbeeld OWASP Top 10 en OWASP ASVS) en toegankelijkheid. Zo ontstaat een concreet startpunt voor testers en ontwikkelaars.

Voorbeelden van mapping van risico naar testopdracht:

Gevoelige data → focus op toegangscontrole en audittrail.
Nieuwe query‑engine → property‑based tests voor prestaties en correctheid (je test eigenschappen, niet alleen losse voorbeelden).
Externe betaalprovider → contracttests en veerkrachttests (resilience), bijvoorbeeld gedrag bij time‑outs.
Inputvelden → injectie‑ en validatietests, bijvoorbeeld op SQL‑injectie of cross‑site scripting.

Voorbeelden van test charters

Een test charter beschrijft in het kort het doel van een testsessie, de orakels (waarmee je bepaalt of iets goed of fout is) en de relevante data. Het is geen script, maar een gerichte opdracht.

Charter 1: Broken Access Control (beveiliging)
Doel: controleren of autorisatie goed is ingericht voor order‑ en betaalresources.
Orakels: rollenmatrix, OWASP ASVS‑secties over autorisatie.
Data: gebruikers met rollen Koper, Beheerder en Gast; ID‑manipulatie; zowel horizontale als verticale escalatiepogingen.
Charter 2: Injectie (beveiliging)
Doel: server‑side injectie detecteren in bijvoorbeeld een zoekveld.
Orakels: bekende OWASP‑payloads en patronen in serverfouten.
Data: gefuzete (gevarieerde) inputs, gecodeerde payloads, tijdsgebaseerde probes.
Charter 3: Prestatie‑spike
Doel: toetsen dat P95 responstijd onder 2 seconden blijft bij een burst van 200 naar 400 requests per seconde.
Orakels: service‑level objectives (SLO’s), APM‑traces en error‑budgetbeleid.
Data: realistische datasets, variatie in cache‑toestand en payloadgrootte.
Charter 4: Toegankelijkheid
Doel: controleren of focusvolgorde, ARIA‑labels en hoog‑contrast thema correct zijn geïmplementeerd.
Orakels: resultaten van tools als Axe of Pa11y, aangevuld met een handmatige check met een screenreader.
Data: verschillende componentvarianten, dark/light‑thema’s en diverse zoomniveaus.

Combineer deze charters met coverage‑artefacten, zodat je altijd kunt laten zien welk risico je waar hebt afgedekt.

Test coverage zichtbaar maken

Test coverage mapping betekent dat je expliciet maakt welke tests welke risico’s en requirements afdekken. Dat doe je door:

Requirements en risico’s te koppelen aan testsoorten (bijvoorbeeld BDD‑scenario’s, contracttests, property‑based tests, accessibility‑tests).
Een zichtbare matrix in je repository te onderhouden, waarin per feature REQ‑ID’s gekoppeld zijn aan charters, scenario’s, testruns en releases.
Deze mapping automatisch bij te werken na elke CI‑run; een AI‑agent kan voorstellen doen voor ontbrekende links, maar een mens beslist.

Deze transparantie helpt bij prioriteren, bij audits en bij regressietesten: je ziet snel welke delen van het systeem onvoldoende zijn afgedekt.

Agentic AI met vangrails

Agentic AI‑systemen zijn AI‑agents die zelfstandig taken uitvoeren, zoals requirements scannen, testdata genereren, test charters voorstellen en zelfs bepaalde testruns uitvoeren. Om dit verantwoord te doen, heb je duidelijke vangrails nodig:

Menselijke goedkeuring bij cruciale beslissingen (bijvoorbeeld het accepteren van testresultaten voor productie).
Heldere policies voor dataprivacy en het gebruik van AI‑modellen.
Traceerbare beslissingen: leg vast wie welke AI‑suggestie heeft overgenomen, met onderliggende rationale en bronverwijzingen.
Duidelijke exit‑criteria vóór productie, zoals geslaagde testruns, stabiele SLO’s, doorlopen security‑checks en een toegankelijke user interface.

Zo blijft AI een versterker van je kwaliteitssysteem, in plaats van een black box die beslissingen neemt die niemand kan uitleggen.

Praktische tips voor duurzame shift-left testing met AI

Tot slot een aantal praktische tips om deze aanpak duurzaam in te bedden:

Begin bij de eisen: investeer in de kwaliteit van requirements, maak niet‑functionele eisen net zo meetbaar als functionele.
Gebruik AI voor ambiguïteitsdetectie tijdens reviews en leg bevindingen gestructureerd vast in je checklist.
Zet risicogestuurd testen centraal, met duidelijke test charters en een expliciete coverage mapping.
Maak voorbeelden uitvoerbaar, bijvoorbeeld met Gherkin/BDD, en link ze aan stabiele requirement‑ID’s.
Vermijd “vibe testing”: genereer geen bulk aan generieke tests zonder koppeling aan concrete risico’s of requirements.
Publiceer testrapporten, APM‑traces en accessibility‑bevindingen als evidence, zodat je altijd kunt laten zien waarom je een release verantwoord vindt.

Met deze werkwijze wordt shift-left testing niet alleen een slogan, maar een aantoonbare praktijk waarin AI, testing en requirements‑engineering elkaar structureel versterken.

Deel dit bericht:

Gerelateerde posts