Hoe schrijf je een goede testcase?

Een goede testcase schrijf je door elk testgeval op te bouwen rond een duidelijk doel, concrete teststappen, verwachte resultaten en de juiste precondities. Wie als software tester werkt, merkt snel dat een goed geschreven testcase het verschil maakt tussen een betrouwbaar testproces en een onvoorspelbaar resultaat. In dit artikel beantwoorden we de meest gestelde vragen over het schrijven, structureren en beheren van testcases. Bekijk ook ons overzicht van trainingen als je je testvaardigheden verder wilt ontwikkelen.

Wat zijn de onderdelen van een goede testcase?

Een goede testcase bestaat uit een unieke identificatie, een duidelijke titel, precondities, teststappen, verwachte resultaten en de testomgeving. Elk onderdeel heeft een specifieke functie: samen zorgen ze ervoor dat de test herhaalbaar, begrijpelijk en controleerbaar is voor elke software tester die hem uitvoert.

Hieronder staan de kernonderdelen op een rij:

• Test-ID en titel: een unieke code en een beschrijvende naam die meteen duidelijk maken wat er getest wordt
• Precondities: de situatie of toestand waarin het systeem zich moet bevinden voordat de test begint
• Teststappen: een genummerde reeks acties die de tester stap voor stap uitvoert
• Verwacht resultaat: wat het systeem hoort te doen na elke stap of na de volledige reeks stappen
• Werkelijk resultaat: wat het systeem daadwerkelijk deed tijdens de uitvoering
• Testomgeving: het platform, de browser, het besturingssysteem of de versie waarop de test plaatsvindt
• Prioriteit en status: hoe kritisch de test is en of hij geslaagd, gefaald of geblokkeerd is

Een testcase zonder verwacht resultaat is geen testcase maar een instructie. Het verwachte resultaat is juist het criterium waaraan je meet of de software correct functioneert.

Hoe schrijf je duidelijke teststappen?

Duidelijke teststappen schrijf je door elke stap als één concrete actie te formuleren, in de gebiedende wijs, zonder aannames over voorkennis van de lezer. Elke stap beschrijft wat de tester doet en eindigt met een meetbaar resultaat of een overgang naar de volgende stap.

Praktische richtlijnen voor heldere teststappen:

• Gebruik de actieve gebiedende wijs: “Klik op de knop Opslaan” in plaats van “De knop Opslaan wordt ingedrukt”
• Schrijf één actie per stap zodat fouten makkelijk te isoleren zijn
• Vermijd vage termen als “controleer of het werkt” en wees specifiek: “Controleer of het bevestigingsbericht ‘Opgeslagen’ verschijnt”
• Neem invoergegevens expliciet op in de stap, inclusief testdata zoals gebruikersnamen of waarden
• Houd rekening met de volgorde: een stap die afhankelijk is van een vorige stap moet dat impliciet of expliciet aangeven

Een vuistregel: als een nieuwe collega de teststappen kan uitvoeren zonder extra uitleg, zijn ze goed genoeg geschreven.

Wat is het verschil tussen een testcase en een testscenario?

Een testscenario beschrijft een situatie of gebruikssituatie op hoog niveau die getest moet worden, terwijl een testcase de gedetailleerde stappen en verwachte resultaten bevat om die situatie daadwerkelijk te verifiëren. Een testscenario is het wat, een testcase is het hoe.

Een voorbeeld maakt het verschil concreet:

• Testscenario: “Controleer of een gebruiker kan inloggen met geldige inloggegevens”
• Testcase 1: Inloggen met een correct e-mailadres en een correct wachtwoord, verwacht resultaat: toegang tot het dashboard
• Testcase 2: Inloggen met een correct e-mailadres en een leeg wachtwoordveld, verwacht resultaat: foutmelding “Wachtwoord is verplicht”
• Testcase 3: Inloggen met een niet-bestaand e-mailadres, verwacht resultaat: foutmelding “Gebruiker niet gevonden”

Eén testscenario leidt dus vrijwel altijd tot meerdere testcases. In de praktijk worden testscenario’s gebruikt voor testplanning en schatting, terwijl testcases worden gebruikt voor de daadwerkelijke uitvoering en rapportage.

Hoeveel testcases heb je nodig voor één functionaliteit?

Het aantal testcases voor één functionaliteit hangt af van de complexiteit van de functie, het aantal invoervarianten, de randgevallen en het risiconiveau. Er is geen universeel getal, maar een goed startpunt is om minimaal de happy path, de negatieve paden en de grenssituaties te dekken.

Factoren die het benodigde aantal testcases bepalen:

• Complexiteit: een eenvoudig invoerveld vereist minder testcases dan een meerstaps betaalproces
• Risiconiveau: kritieke functies zoals authenticatie of betalingen verdienen meer dekking
• Equivalentieklassen: groepeer vergelijkbare invoerwaarden en schrijf één testcase per klasse in plaats van voor elke waarde apart
• Grenswaarden: test altijd de minimale en maximale toegestane waarden, plus de waarden net daarbuiten
• Beschikbare tijd: risicogebaseerd testen helpt om prioriteiten te stellen als de tijd beperkt is

Meer testcases betekent niet automatisch betere kwaliteit. Een kleine set goed doordachte testcases dekt meer risico af dan een grote set overlappende of onduidelijke gevallen.

Welke fouten worden het vaakst gemaakt bij het schrijven van testcases?

De meest voorkomende fouten bij het schrijven van testcases zijn het ontbreken van een concreet verwacht resultaat, te brede teststappen die meerdere acties samenvoegen, en het vergeten van negatieve testscenario’s. Deze fouten verminderen de herhaalbaarheid en de waarde van de tests.

Een overzicht van veelgemaakte fouten:

• Geen verwacht resultaat: de tester weet niet wanneer de test geslaagd is
• Te vage stappen: “Voer de gegevens in” zegt niets over welke gegevens en in welk veld
• Alleen positieve paden testen: negatieve scenario’s en randgevallen worden overgeslagen
• Testcases zonder precondities: de test is niet reproduceerbaar omdat de beginsituatie onduidelijk is
• Afhankelijkheid tussen testcases: een testcase die alleen werkt als een vorige testcase is geslaagd, creëert kwetsbare testsuites
• Verouderde testcases: testcases die niet worden bijgehouden na wijzigingen in de software geven een vals beeld van de kwaliteit

Welke tools kun je gebruiken om testcases te beheren?

Testcases kun je beheren met gespecialiseerde testmanagementtools zoals TestRail, Zephyr, Xray of qTest. Voor teams die al werken met projectmanagementsoftware zijn er integraties beschikbaar met platforms als Jira. Eenvoudige projecten kunnen ook starten met een gestructureerd spreadsheet in Excel of Google Sheets.

Een vergelijking van gangbare opties:

• TestRail: een zelfstandige testmanagementtool met uitgebreide rapportage en integraties, geschikt voor middelgrote en grote teams
• Zephyr voor Jira: een populaire keuze voor teams die al Jira gebruiken, testcases leven direct naast de user stories
• Xray: vergelijkbaar met Zephyr, sterk in het koppelen van testcases aan requirements en Jira-issues
• qTest: gericht op enterprise-omgevingen met uitgebreide ondersteuning voor testplanning en traceerbaarheid
• Excel of Google Sheets: laagdrempelig en flexibel, maar minder geschikt naarmate het aantal testcases en teamleden groeit

De keuze voor een tool hangt af van de teamgrootte, de bestaande toolstack en het belang van traceerbaarheid naar requirements. Begin klein en schaal op wanneer de complexiteit dat vraagt.

Hoe Startel helpt met het schrijven van testcases

Goed testwerk begint bij een solide basis in softwaretesten. Bij Startel bieden we trainingen die software testers helpen om niet alleen testcases te schrijven, maar het volledige testproces te begrijpen en toe te passen. Onze opleidingen sluiten aan bij erkende certificeringen zoals ISTQB en TMAP, zodat je kennis direct toepasbaar is in de praktijk.

Wat we bieden voor aankomende en ervaren software testers:

• Klassikale trainingen en live online cursussen voor flexibel leren
• Zelfstudiepakketten voor wie in eigen tempo wil werken
• Maatwerktrajecten afgestemd op de behoeften van jouw organisatie
• Examenvoorbereiding en begeleiding via erkende examencentra
• Meer dan 25 jaar ervaring in IT-onderwijs en certificering

Wil je weten welke opleiding het beste past bij jouw situatie of die van je team? Neem gerust contact met ons op en we helpen je op weg.