Nieuwe testers horen deze twee termen vaak gebruiken alsof ze hetzelfde betekenen. Dat doen ze niet. Het verschil tussen een testcase en een testscenario heeft vooral te maken met de mate van detail. Als u dit begrijpt, kunt u beslissen hoeveel u moet schrijven voordat u begint met testen.

Deze handleiding legt ze allemaal uit en werkt vervolgens via één enkele functie voor het opnieuw instellen van wachtwoorden, van vereisten tot scenario’s tot volledige testcases. De functie en de bijbehorende regels zijn een verzonnen voorbeeld. De terminologie varieert ook enigszins tussen teams en tools, dus spreek af wat deze woorden betekenen in je eigen team.

Het korte antwoord

Een testscenario beschrijft een situatie die moet worden gecontroleerd, zoals ‘controleren of een gebruiker een vergeten wachtwoord opnieuw kan instellen’. Het is meestal één regel en laat de details over aan de tester.

In een testcase wordt precies beschreven hoe je één voorwaarde binnen die situatie kunt controleren: randvoorwaarden, stappen, testgegevens en het verwachte resultaat. Twee testers die het volgen, zouden tot hetzelfde oordeel moeten komen.

Denk aan het plannen van een reis. Het scenario is “reizen van Pune naar Delhi”. De testcase is het volledige reisschema, met het vluchtnummer, de vertrektijd en wat u in elke etappe moet doen.

Testcase versus testscenario naast elkaar

Wat is een testscenario?

Een testscenario is een korte beschrijving van iets dat een gebruiker zou kunnen doen, of van een situatie die het systeem moet afhandelen. Het richt zich op wat er van buitenaf toe doet, en komt meestal rechtstreeks voort uit een vereiste of gebruikersverhaal.

Scenario’s zijn waardevol omdat ze snel zijn. Je kunt er dertig opsommen in de tijd die nodig is om drie gedetailleerde cases te schrijven, wat ze een geweldige manier maakt om de berichtgeving met een producteigenaar te bespreken: “Hebben we aan alles gedacht?” Een niet-technische lezer kan zonder problemen een lijst met scenario’s volgen.

Wat is een testcase?

Een testcase is een reeks specifieke voorwaarden en stappen die worden gebruikt om te bepalen of iets werkt. Een typische testcase bevat:

• Een unieke ID en duidelijke titel
• Voorwaarden, dat wil zeggen wat waar moet zijn voordat je begint
• Genummerde stappen
• Specifieke testgegevens
• Een verwacht resultaat
• Het werkelijke resultaat en status, ingevuld tijdens de uitvoering

Testgevallen schitteren wanneer consistentie ertoe doet. Een nieuw teamlid kan ze uitvoeren, de resultaten kunnen tussen releases worden vergeleken en u heeft een overzicht van wat er is geverifieerd. In onze gids gaan we dieper in op het schrijven van testcases.

Eén functie, van begin tot eind

Stap 1: De vereiste

Gebruikers die hun wachtwoord vergeten, kunnen per e-mail een resetlink aanvragen. De link werkt eenmalig en vervalt na 30 minuten. Een nieuw wachtwoord moet minimaal 8 tekens lang zijn.

Stap 2: De testscenario’s

Kijk naar TS-02. De vereiste zegt nooit wat er moet gebeuren met een onbekende e-mail, en het schrijven van het scenario heeft die leemte blootgelegd. Moet uit de pagina blijken dat het adres niet geregistreerd is? Uit veiligheidsoverwegingen zou dit meestal niet moeten gebeuren, omdat aanvallers hierdoor geldige accounts kunnen ontdekken. Het vroegtijdig vinden van deze vragen is een van de grootste voordelen van het schrijven van scenario’s.

Stap 3: De testgevallen

Nu breiden we alleen TS-05 uit naar testgevallen. Eén scenario wordt meerdere:

Deze waarden waren niet willekeurig. TC-051 en TC-052 bevinden zich aan weerszijden van de limiet en maken gebruik van grenswaardeanalyse, en de andere komen voort uit equivalentiepartitionering.

Een testcase-sjabloon

Hier is TC-052 volledig uitgeschreven. Kopieer deze indeling als jouw team nog geen standaard heeft:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Merk op dat het verwachte resultaat meer controleert dan het foutbericht. Het bevestigt ook dat het oude wachtwoord nog steeds werkt en dat de link bruikbaar blijft. Zwakke testgevallen stoppen vaak bij wat op het scherm zichtbaar is.

Waar ze passen in het grotere geheel

Traditioneel worden scenario’s en cases geschreven tijdens de testontwerpfase van de levenscyclus van softwaretests.

Wanneer moet u ze allemaal gebruiken?

Scenario’s zijn vaak voldoende wanneer:

• Het team is klein, ervaren en kent het product goed.
• De tijd is kort, of de eisen veranderen regelmatig.
• De functie heeft een laag risico.
• U wilt de dekking snel met belanghebbenden beoordelen.
• Je begeleidt verkennende tests.

Gedetailleerde testgevallen zijn de moeite waard wanneer:

• Een mislukking zou kostbaar zijn, net als bij betalingen, beveiligings- of gezondheidsgegevens.
• Regelgevers of auditors hebben bewijs nodig van wat er is getest.
• Nieuwe of uitbestede testers moeten de tests uitvoeren.
• Resultaten moeten exact worden herhaald, zoals in een regressiesuite.
• De stappen worden geautomatiseerde tests.

De meeste volwassen teams gebruiken beide. Ze vermelden voor alles scenario’s en schrijven alleen volledige cases voor de hoogste risico’s. Het is niet nodig om elke stap van een instellingenpagina met een laag risico op dezelfde manier te documenteren als bij een bankoverboeking.

Scenario’s, cases en automatisering

Een goed geschreven testcase komt vrijwel direct overeen met een geautomatiseerde test. Randvoorwaarden worden instellingen, stappen worden acties en het verwachte resultaat wordt een bewering. Gedragsgestuurde ontwikkelingsframeworks gebruiken zelfs het woord ‘Scenario’ voor hun uitvoerbare specificaties:

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

Het is verwarrend dat wat BDD een scenario noemt, veel dichter bij een testcase ligt, omdat het over specifieke gegevens en uitkomsten beschikt. Dat is een goede herinnering om het eens te worden over de voorwaarden. Als je deze controles wilt automatiseren, bekijk dan onze Tutorial voor toneelschrijvers of pytest-tutorial.

Wat maakt ze goed

Veel voorkomende fouten

• Alleen gelukkige paden schrijven. De meeste bugs bevinden zich in de foutcondities, dus vermeld ook wat zou moeten mislukken.
• Gebruik vage verwachte resultaten. ‘Het zou goed moeten werken’ laat elke tester alles beslissen.
• Alles volledig documenteren. Duizenden zaken die niemand onderhoudt, zijn erger dan een nuttig klein stel.
• Scenario’s overslaan. Als je meteen op zaken ingaat, kun je hele gebieden vergeten.
• Koffers laten verouderen. Als het product verandert, misleiden oude koffers mensen. Bekijk ze regelmatig.
• Stappen koppelen aan fragiele details. ‘Klik op de blauwe knop bovenaan’ breekt met elk herontwerp.

Tot slot

Scenario’s geven je breedte, en testcases geven je diepgang. Begin met scenario’s voor uw volgende functie en bespreek deze met een ontwikkelaar en een producteigenaar. Breid vervolgens alleen de risicovolle gevallen uit naar volledige gevallen. U zult eerder hiaten ontdekken en uw schrijftijd besteden daar waar het telt.

Veelgestelde vragen

Blijf leren