Een quality engineer beoordeelt automatiseringscode en testresultaten op een laptop.

Gegenereerde data is nog geen testdata

AI kan in enkele seconden tien klanten, twintig bestellingen en een reeks grensgevallen bedenken. Dat klinkt als een snelle route naar betere tests. Maar zonder duidelijke verwachtingen ontstaat vooral méér invoer: geloofwaardige namen, willekeurige bedragen en combinaties waarvan niemand weet welk risico ze afdekken.

De bruikbare combinatie is daarom niet om tijdens iedere Cypress-run iets nieuws te laten verzinnen. Laat AI eerst kandidaatdata voorstellen, controleer die data tegen expliciete regels en laat Cypress vervolgens een vaste, herhaalbare toestand opbouwen. AI vergroot de variatie. Cypress bewaakt de reproduceerbaarheid.

Die scheiding wordt actueler nu leveranciers AI dichter bij testontwerp brengen. IBM kondigde op 17 september 2026 bijvoorbeeld een agent aan die vanuit requirements concepttestgevallen en scripts opstelt. IBM vermeldt ook dat engineers verantwoordelijk blijven voor controle, verfijning en goedkeuring. Dat is waar Quality Engineering begint: niet bij genereren, maar bij aantoonbaar maken waarom een scenario ertoe doet.

Begin met het risico, niet met de prompt

Stel dat een applicatie korting berekent voor bestellingen vanaf 100 euro. De vraag ‘maak twintig bestellingen’ levert waarschijnlijk nette JSON op, maar zegt niets over de grens die we willen onderzoeken. Een betere opdracht beschrijft de beslisregel en de gewenste categorieën:

Maak kandidaat-testdata voor een bestel-API.
De korting begint bij een totaalbedrag van 100,00 euro.
Lever geldige voorbeelden op voor 99,99, 100,00 en 100,01,
plus één ontbrekend bedrag en één bedrag met te veel decimalen.
Gebruik fictieve identifiers en geen persoonsgegevens.
Geef per record het verwachte resultaat en de gedekte risicoregel.

Maak de uitvoer controleerbaar

Het verschil zit niet in mooiere voorbeelddata. Elk record krijgt een reden: onder de grens, precies op de grens, erboven of ongeldig. Daardoor kan een reviewer beoordelen of de set volledig genoeg is voordat Cypress hem gebruikt.

Laat een model bij voorkeur een afgesproken JSON-structuur vullen. Controleer daarna automatisch of verplichte velden aanwezig zijn, bedragen het juiste formaat hebben, identifiers uniek zijn en uitsluitend toegestane waarden voorkomen. Behandel modeluitvoer als onbetrouwbare invoer: eerst valideren, dan pas opslaan.

{
  "caseId": "discount-boundary-10000",
  "orderTotalCents": 10000,
  "expectedDiscountCents": 1000,
  "risk": "korting start exact op de grens"
}

Laat Cypress de toestand opbouwen

Sla de goedgekeurde set versieerbaar op, bijvoorbeeld als fixture of als invoer voor een testdata-API. Gebruik geen gekopieerde productiedata in de prompt. Fictieve namen zijn niet automatisch veilig als andere velden nog naar echte personen, dossiers of transacties te herleiden zijn.

Cypress adviseert om de benodigde toestand waar mogelijk rechtstreeks via een API of een Node-task klaar te zetten. Dat is sneller en stabieler dan iedere klant en bestelling via de gebruikersinterface aanmaken. Een test kan de gevalideerde fixture lezen en vóór de controle een testrecord laten aanmaken:

describe("kortingsgrens", () => {
  beforeEach(() => {
    cy.fixture("discount-boundaries").then(({ cases }) => {
      cy.request("POST", "/test-support/orders/seed", { cases });
    });
  });

  it("past korting toe vanaf 100 euro", () => {
    cy.visit("/orders/discount-boundary-10000");
    cy.findByTestId("discount").should("have.text", "€ 10,00");
  });
});

Genereer vooraf, niet tijdens de test

Als er geen veilige testdata-API bestaat, kan cy.task() een bestaand seed-script in het Node-proces aanroepen. Houd zo’n route of taak beperkt tot de testomgeving, controleer autorisatie en ruim data voorspelbaar op. De browsertest hoeft niet te weten hoe de database intern werkt; hij vraagt alleen om een bekende uitgangssituatie.

Live een AI-model aanroepen vanuit een Cypress-test lijkt flexibel, maar maakt een regressiesuite moeilijker te verklaren. De invoer kan per run veranderen, een externe dienst kan traag of niet beschikbaar zijn en achteraf is onduidelijk of een fout uit de applicatie of uit de gegenereerde data kwam.

Voor verkennend onderzoek mag variatie juist nuttig zijn. Bewaar in dat geval de prompt, modelversie, instellingen, gegenereerde dataset en validatieresultaten. Zodra een scenario een echt risico blootlegt, promoveer je het naar een vaste regressiecase. Zo blijft toeval een bron van ontdekking zonder dat de vaste suite onvoorspelbaar wordt.

Vijf controles voor een bruikbare aanpak

AI kan het saaie combinatiewerk versnellen en onverwachte varianten voorstellen. De kwaliteitswinst ontstaat pas wanneer een team de verwachtingen expliciet maakt. Cypress is daarin niet alleen de uitvoerder van gegenereerde data. Het is het controlepunt dat van een idee een herhaalbaar experiment maakt.

  1. Welke businessregel of welk risico dekt ieder record?
  2. Is de modeluitvoer technisch én inhoudelijk gevalideerd?
  3. Bevat de prompt of dataset geen productiegegevens of herleidbare persoonsgegevens?
  4. Kan dezelfde goedgekeurde dataset lokaal en in CI opnieuw worden gebruikt?
  5. Kan een mislukte test worden herleid tot data, inrichting, verwachting of productgedrag?

Bronnen

← Alle artikelen