Antwoord.

Beheer van testdata is één van de oudste problemen in automatisering. Al bij de start van automatisering (testscripts in Excel, macro's, oude QTP) werden gegevens vaak "in het hoofd" van de testmaker of rechtstreeks in de code opgeslagen. Met de ontwikkeling van CI/CD en parallelle runs waren nieuwe strategieën vereist: hoe kunnen we races vermijden wanneer meerdere tests tegelijkertijd dezelfde gegevens gebruiken en herhaalbaarheid van resultaten waarborgen?

Probleem: gedeelde testdata leiden snel tot conflicten en onvoorspelbare resultaten. Tests worden instabiel, het is moeilijk ze te debuggen, en fragmenten van gegevens "vervuilen" databases, terwijl het draaien in meerdere threads leidt tot fouten (data race).

Oplossing — implementatie van de strategieën "data per test" (Test Data Per Test):

Gebruik van unieke of geparametriseerde testdata voor elke test
Genereren/schoonmaken van gegevens voor en na de test (setup/teardown, fixtures)
Scheiding van testomgevingen met behulp van namespaces, tenants, users
Gebruik van in-memory databases met herinitialisatie per test

Belangrijke kenmerken:

Genereren van unieke gegevens (UUID, timestamp), automatisch verwijderen na de test
Gebruik van sjablonen en fabrieken voor testdata (Test Data Factories)
Werken met geïsoleerde sandbox-omgevingen

Misleidende vragen.

Is het acceptabel om productiegegevens als testdata te gebruiken?

Nee! Dit is riskant voor de veiligheid, vertrouwelijkheid, en leidt tot onvoorspelbaarheid van tests door de veranderlijkheid van gegevens.

Is het voldoende om setUp en tearDown te gebruiken voor het schoonmaken van gegevens?

Niet altijd. Ze helpen de risico's te minimaliseren, maar parallelle runs kunnen tests botsen als de gegevens globaal blijven of niet uniek zijn.

Kan ik dezelfde testdata gebruiken in smoke- en regressiescenario's?

Bij voorkeur niet. Smoke-tests moeten zo onafhankelijk mogelijk zijn, en regressietests vereisen complexe voorbereiding van gegevens, anders kunnen er valse positieven optreden.

Veelvoorkomende fouten en anti-patronen

Gebruik van gedeelde, "magische" gegevens die per ongeluk bij veel tests passen
Gegevensartefacten die niet na de test zijn schoongemaakt
Dubbel gebruik van dezelfde records in alle tests

Voorbeeld uit het leven

Negatieve case

In het bedrijf was er één gemeenschappelijke login en meerdere "gedeelde" gebruikers en bestellingen die in alle geautomatiseerde tests werden gebruikt. Een parallelle run leidde ertoe dat tests elkaars bestellingen overschreven of de status van een bestelling in meerdere threads wijzigden.

Voordelen:

Snel en eenvoudig te implementeren met een klein aantal tests
Geen extra infrastructuur vereist

Nadelen:

Onduidelijke mislukkingen, moeilijkheden met debuggen
Tests kunnen niet veilig parallel of in verschillende omgevingen worden uitgevoerd

Positieve case

Testdata-fabrieken werden geïmplementeerd: voor het starten van de test werd voor elk scenario een unieke bestelling en gebruiker aangemaakt, die na afloop van de test werd verwijderd, en de sandbox-omgeving werd herinitialiseerd.