Negatieve tests: ontdek de foutieve invoer die uw team niet test

Uw team voert al negatieve tests uit. Ongeldige e-mailadressen worden afgewezen. Lege verplichte velden geven de juiste foutmelding. Grenswaarden worden gedekt voor elke numerieke invoer. En toch stroomt de ondersteuningsmailbox nog steeds vol met zaken waarvoor niemand een testgeval heeft geschreven: twee identieke bestellingen die met 400ms tussenruimte zijn geplaatst door een dubbelklik, een analysepijplijn die vastloopt op een emoji in een weergavenaam, een uniciteitscontrole die [email protected] en hetzelfde adres met een onzichtbare spatie aan het einde als twee verschillende accounts behandelt.

Geen van deze bugs ontbrak per ongeluk in het testplan. Ze ontbraken omdat het testplan was gebouwd op basis van het vereistendocument, dat invoer beschrijft, geen mensen. Dit stuk gaat over de tweede categorie: een heuristiek met vier lenzen om de scenario’s naar boven te halen die uw team momenteel niet genereert. Het staat naast bredere functionele testen als de laag die opvangt wat specificaties missen.

Wat negatief testen werkelijk is (en waar de meeste teams stoppen)

Negatief testen is de praktijk waarbij ongeldige, onverwachte of onjuist geformatteerde gegevens in een systeem worden ingevoerd om te verifiëren of het systeem correct faalt. Dat betekent: geen crash, geen stille corruptie, geen achtergebleven status en een foutmelding waar de gebruiker iets mee kan. Dit concept is al twintig jaar gevestigd, dus we gaan daar niet opnieuw over debatteren.

Het probleem is wat er daarna in de meeste handleidingen gebeurt. Ze sommen vijf categorieën op: ongeldig gegevenstype, grenswaarde, leeg verplicht veld, speciaal karakter en SQL-injectie. Daarna stoppen ze. Elke QA-lead die dit artikel leest, is in de eerste maand op het werk al voorbij die checklist gegaan. De bugs die in productie belanden, komen ergens anders vandaan. Het rapport van IBM stelde de wereldwijde gemiddelde kosten van een datalek op 4,44 miljoen dollar en de gemiddelde levenscyclus van een datalek op 241 dagen; een groot deel van de incidenten in die dataset is terug te voeren op sessiebeheer, race conditions en gaten in statusovergangen die in niets lijken op een gemiste regex.

Negatief testen bij softwaretesten is het meest nuttig wanneer u het behandelt als een ontwerpprincipe dat verankerd is in gebruikersgedrag. Deze herformulering is wat de rest van dit artikel u biedt.

Vier gebruikerstypen die uw testplan vergeet

De heuristiek is simpel: voordat u akkoord gaat met een user story, loopt u deze na aan de hand van vier gebruikerstypen die de specificatie bijna nooit beschrijft. Elke lens is een persoon wiens gedrag uw ‘happy path’ over het hoofd ziet. Elk opent een categorie bugs die de standaardchecklist overleeft, omdat deze bugs niet gaan over wat er is ingevoerd. Ze gaan over hoe, wanneer of in welke status het werd ingevoerd.

Bij elke onderstaande lens benoemen we het patroon van de productie-bug, geven we drie tot vijf concrete voorbeelden en wijzen we op de specifieke blinde vlek in de vereisten waardoor de bug verborgen bleef.

Lens 1: de ongeduldige gebruiker

Het patroon: de gebruiker klikt op ‘Betalen’, het netwerk hapert 300ms, de gebruiker klikt nogmaals, de backend ontvangt twee identieke POST-verzoeken en de klant wordt dubbel belast. Of de gebruiker verzendt een formulier, ziet een laadicoon, verveelt zich en klikt op ‘verversen’. Het tabblad laadt opnieuw, het formulier wordt opnieuw verzonden en nu zijn er twee supporttickets met opeenvolgende ID’s en identieke inhoud.

Dit zijn de negatieve testgevallen die het waard zijn om voor deze lens te schrijven:

• Dubbelklik op de verzendknop binnen een venster van 500ms en verifieer dat er precies één record aan de serverkant is aangemaakt.
• Ververs de pagina tijdens het verzenden en verifieer dat een idempotency-sleutel de tweede schrijfactie voorkomt.
• Klik na het succes-scherm op de terug-knop van de browser en verzend opnieuw; verifieer dat er geen duplicaat wordt aangemaakt.
• Open hetzelfde formulier in twee browsertabbladen, verzend beide binnen enkele seconden en verifieer dat de tweede wordt afgewezen of samengevoegd.
• Verbreek de netwerkverbinding tijdens een verzoek, herstel deze, probeer opnieuw en verifieer dat er aan geen van beide kanten een gedeeltelijke status achterblijft.

De blinde vlek: de specificatie zegt “de gebruiker verzendt het formulier” alsof die actie atomair is. De vinger van een gebruiker is niet atomair, en een mobiele verbinding in een metrotunnel evenmin.

Lens 2: de kopiëren-plakken-gebruiker

Gebruikers kopiëren tekst uit Word, Slack, Google Docs, PDF’s en elkaars e-mails. Elk van die bronnen voegt karakters toe die de gebruiker niet kan zien. ‘Smart quotes’ vervangen rechte aanhalingstekens. Een geplakt e-mailadres komt binnen met een spatie aan het einde omdat de bron een regelafbreking bevatte. Emoji’s stromen in een naamveld, worden prima opgeslagen en breken vervolgens de analysepijplijn drie services verderop, omdat de doelkolom varchar is en de emoji vier bytes groot is.

Praktische voorbeelden van negatief testen binnen deze lens:

• Spaties aan het begin of einde van velden met uniciteitsbeperkingen (e-mail, gebruikersnaam, couponcode).
• Zero-width joiners, right-to-left marks en andere onzichtbare Unicode-tekens in velden die worden gebruikt voor zoeken of matchen.
• Smart quotes en en-dashes die vanuit Word of Outlook in e-mail-, wachtwoord- of regex-gevalideerde velden worden geplakt.
• Emoji’s in naam-, titel- of beschrijvingsvelden die worden doorgezet naar SMS, PDF-export, CSV-download of een legacy-backend.
• Tekst gekopieerd uit gerenderde HTML die verborgen -fragmenten of non-breaking spaces bevat.

De blinde vlek: de vereisten sommen op welke karakters een gebruiker mag typen. Ze sommen zelden de karakters op die een gebruiker onbedoeld kan plakken. Invoersanitisatie is niet hetzelfde als normalisatie voor elk downstream-systeem dat de waarde ontvangt.

Lens 3: de tijdreizende gebruiker

Klokken liegen. De klok van de client loopt 40 minuten achter omdat de gebruiker deze na een reis nooit heeft aangepast. De serverklok is leidend, maar de CDN-cache is dat niet. Een sessietoken verloopt om middernacht UTC terwijl de gebruiker midden in het betaalproces zit. Bij de overgang naar zomertijd worden geplande taken twee keer of helemaal niet uitgevoerd. Een JWT die geldig was toen de pagina werd geladen, is verlopen tegen de tijd dat de gebruiker op ‘Opslaan’ klikt.

Testgevallen die de moeite waard zijn:

• Zet de clientklok 10 minuten of meer voor of achter en verifieer dat de tokenvalidatie op de server nog steeds correct wordt afgehandeld.
• Laat een sessie verlopen tijdens een formulier met meerdere stappen en verifieer dat het concept de her-authenticatie overleeft en de gebruiker terugkeert naar dezelfde stap.
• Verstuur een verlopen token bij een herhaalde poging na een netwerkfout en verifieer dat de herhaalde poging geen spookactie creëert.
• Test alle geplande of tijdgebonden logica tijdens de overgangen naar zomer- en wintertijd in elke tijdzone waar uw gebruikers zich bevinden.
• Verstuur twee schrijfacties met dezelfde tijdstempel maar verschillende Last-Modified-headers en verifieer dat uw conflictresolutie deterministisch is.

De blinde vlek: de specificatie gaat uit van één klok. In productie zijn er minstens drie: de client, de applicatieserver en de database, en ze zijn het constant oneens.

Lens 4: de verwarde gebruiker

Een gebruiker opent een tabblad om af te rekenen, wordt twee dagen afgeleid, keert terug, klikt op aankoop voltooien en betaalt voor een product dat 36 uur geleden offline is gehaald. Een beheerder verwijdert een project terwijl een teamgenoot halverwege de bewerking zit; de teamgenoot klikt op opslaan en krijgt een 500-foutmelding in plaats van een duidelijke melding als “dit project bestaat niet meer”. Iemand accepteert een uitnodiging voor een team dat al verwijderd was. Twee beheerders keuren tegelijkertijd hetzelfde verzoek goed, en beide goedkeuringen worden naar de database weggeschreven.

Scenario’s:

• Voltooi de derde stap van een wizard nadat het onderliggende object in een andere sessie is verwijderd.
• Betaal voor een product dat offline is gehaald tussen “Toevoegen aan winkelwagen” en “Afrekenen”.
• Accepteer een teamuitnodiging nadat het team is ontbonden.
• Keur een in behandeling zijnd verzoek goed dat een andere beheerder 30 seconden eerder al had goedgekeurd.
• Verzend een formulier waarvan de server-side validatieregels zijn gewijzigd terwijl het tabblad openstond.

De blinde vlek: de requirements beschrijven de ideale toestand van het object. Ze beschrijven bijna nooit wat er gebeurt wanneer het beeld dat de client van de status heeft en de werkelijke status op de server niet overeenkomen. Die kloof is waar race conditions ontstaan, en het is een natuurlijk overdrachtspunt naar exploratory testing, dat is ontworpen om precies deze dubbelzinnige transities te onderzoeken.

Negative testing versus edge case testing: het onderscheid dat er echt toe doet

Deze twee worden in bijna elk resultaat in de zoekmachine op één hoop gegooid, en door die verwarring schrijven teams de verkeerde tests. Kort gezegd: negative testing verifieert een correcte foutafhandeling bij ongeldige of onverwachte input. Edge case testing verifieert correct gedrag aan de uiterste grenzen van geldige input.

Een dubbelklik die dubbele bestellingen aanmaakt, is een negative case. Een gebruiker met precies 65.535 items in één winkelwagen is een edge case. Ze overlappen elkaar bij grenswaarden, maar het instinct bij het genereren ervan is verschillend. Bij negative testing vraag je: wat zou niet moeten werken? Bij edge case testing vraag je: wat zijn de uitersten van wat wel zou moeten werken? Als u een diepere behandeling van de tweede vraag wilt, bekijk dan het gerelateerde artikel: Edge Case Testing: Where Requirements End and Reality Starts.

Beide categorieën gaan niet in op beveiliging. SQL injection, XSS en auth bypass verschijnen volgens traditie in de literatuur over negative testing, maar ze volgen een ander dreigingsmodel en vallen onder specifieke security testing.

Hoe past u deze heuristiek toe in een echte sprint?

Deze lenzen werpen alleen vruchten af als ze onderdeel zijn van het werkproces, in plaats van een document dat niemand opent. Wat in de praktijk werkt:

Voeg een negative pass van 15 minuten toe aan elke user story voordat deze de status In Progress krijgt. Eén lens per teamlid. Vijf scenario’s per persoon. Dat zijn twintig scenario’s per story die anders nooit geschreven zouden worden. Registreer elke bug in productie onder de lens die het had kunnen vangen. Na een kwartaal heeft u een heatmap: de lens met de meeste treffers is het zwakste punt in uw template voor requirements. U kunt de template vervolgens bijwerken in plaats van te vertrouwen op het geheugen van individuen.

Combineer de lenzen met charters voor exploratory testing. Waar gestructureerde tests de lenzen gebruiken als checklist, gebruiken sessies voor exploratory testing ze als prompts. Het gerelateerde artikel Exploratory Testing Charters That Actually Find Bugs gaat dieper in op dat patroon.

Houd de lijst geversioneerd per product. Een fintech-app heeft een vijfde lens nodig voor de regelgevende status (een gebruiker die handelt onder nalevingsvoorwaarden die niet in de specificaties stonden). Een multi-tenant SaaS heeft er een nodig voor verwarring over organisatorische grenzen (een gebruiker die handelt in tenants die ze technisch gezien kunnen zien, maar niet zouden mogen wijzigen). De vier lenzen zijn een startkit, geen voltooide taxonomie.

De bug waarvoor u geen test heeft geschreven

Elke bug in productie die het team verrast, heeft in de basis dezelfde vorm. Iemand ging ervan uit dat de gebruiker zich zou gedragen volgens de specificatie. De checklist met vijf categorieën beschermt het product tegen invoer. De heuristiek met vier lenzen beschermt het tegen gebruikers. Het zal niet alles vangen — dat doet niets — maar het verplaatst de ontdekking van “boze klant op zondag” naar “dinsdag-standup”, wat het verschil is tussen een brand blussen en een taak uitvoeren.

Als u een tweede paar ogen wilt dat deze lenzen op uw product toepast voordat uw gebruikers de hiaten voor u vinden, neem dan contact met ons op, dan plannen we een gesprek in.