Antwoord.

Automatisering van negatieve scenario's is een onmisbaar onderdeel van een volledig testsysteem. Dit zijn controles waarbij de veerkracht van het systeem tegen foutieve acties, onjuiste gegevens, service-uitval en andere ongewone situaties wordt gevalideerd.

Achtergrond van de vraag:

Eerder lag de focus voornamelijk op positieve scenario's (happy paths), omdat deze eenvoudiger te automatiseren en te onderhouden zijn. Echter, de vereisten voor kwaliteit zijn gestegen, en steeds meer bugs ontstaan juist op de grenzen, met foutieve of onduidelijk onjuiste voorwaarden. Handmatig testen veroudert snel, en automatisering maakt het mogelijk om degradaties te volgen.

Probleem:

Het definiëren en dekken van alle mogelijke negatieve scenario's
Correcte controle van foutmeldingen, validiteit van de systeemstatus na een mislukte bewerking
Ondersteuning van tests bij wijzigingen in de bedrijfslogica

Oplossing:

Identificatie van negatieve scenario's en hun systematisering (Boundary Value Analysis, Equivalence Partitioning)
Gebruik van aangepaste asserts en validators voor het controleren van foutberichten, HTTP-codes, uitzonderingen
Automatische "opruiming" van de systeemstatus na een negatieve test

Belangrijke kenmerken:

Expliciete testopstellingen voor fouten, uitzonderingen, ongewone invoerdata
Controle van foutmeldingen en interne systeemstatus
Beheer van bijwerkingen: na een negatieve test moet het systeem in een consistente staat blijven

Vragen met valstrikken.

Is het voldoende om alleen te controleren welke fouten worden geretourneerd bij negatieve testing?

Nee. Het is belangrijk om niet alleen de inhoud van de fout te controleren, maar ook ervoor te zorgen dat er na de fout geen wijziging in de systeemstatus heeft plaatsgevonden (bijvoorbeeld dat er geen onjuiste record aan de database is toegevoegd).

Moet je alle mogelijke negatieve scenario's automatiseren?

Nee. Er kunnen er oneindig veel zijn; je moet de meest waarschijnlijke en kritieke identificeren (Boundary Value, Null/Empty, onjuiste types, SQL-injecties, enz.), de rest naar behoefte voorbereiden wanneer bugs zich voordoen.

Kan dezelfde verwerking voor alle negatieve gevallen worden gebruikt?

Nee. Verschillende negatieve scenario's vereisen verschillende controles, foutafhandelingsprocessen en rollback-instructies, en sjabloon asserts zijn niet voldoende.

Typische fouten en anti-patronen

Negatieve scenario's negeren of ze "voor de schijn" dekken
Onduidelijke foutcontroles (bijvoorbeeld alleen code 500 controleren, zonder de tekst of bijeffecten te controleren)
Niet-opgeruimde testomgeving na een mislukte test

Voorbeeld uit het leven

Negatief geval

In het systeem worden alleen geldige registratiescenario's getest. Registratie met een leeg e-mailadres wordt niet automatisch gecontroleerd. Uiteindelijk wordt het probleem dat je een gebruiker met een leeg e-mailadres kunt registreren, pas opgemerkt in de productie.

Voordelen:

Eenvoudige ondersteuning van tests
Weinig autotests en snelle uitvoering

Nadelen:

Kritische bugs komen in productie
Toenemende kosten voor herstel en rollback

Positief geval

Voor elk negatief scenario (afwezigheid van e-mail, onjuiste opmaak, SQL-injectie) is er een geautomatiseerde test die expliciet controleert op de afwezigheid van een nieuw account en de inhoud van het foutbericht.