De meeste testcases mislukken al voordat ze ook maar één bug opsporen. Ze zijn geschreven als vage checklists, missen randvoorwaarden, bundelen meerdere acties in één stap of beschrijven de verwachte resultaten zo vaag dat twee testers die dezelfde testcase lezen, het oneens zouden zijn over wat ‘geslaagd’ precies betekent. Het gevolg: bugs glippen erdoorheen, testruns kunnen niet worden gereproduceerd en QA wordt een knelpunt in plaats van een vangnet.
Het schrijven van een goede testcase heeft minder te maken met testvaardigheden en meer met het ontwerp van de verificatie. In de financiële sector noemen ze dit het ‘maker-checker’-proces. Bij nucleaire commando’s heet het de ‘tweepersoonsregel’. Het principe is hetzelfde: kritiek werk mag nooit afhangen van één enkele, ongecontroleerde handeling. Een goed geschreven testcase bouwt diezelfde strengheid in de software in. Het maakt een onderscheid tussen wat je verwacht en wat je waarneemt, zodat de kloof tussen beide onmogelijk te negeren is.
We laten je zien hoe je testcases schrijft, waarom ze belangrijk zijn en hoe je de kwaliteit van je testcases in de loop van de tijd kunt verbeteren.
TL;DR
Een testcase definieert de exacte stappen, invoergegevens en verwachte resultaten die nodig zijn om te verifiëren of een functie correct werkt. Elke testcase moet voorzien zijn van een unieke ID, randvoorwaarden en verwachte resultaten, zodat het resultaat kan worden gecontroleerd. Deze handleiding behandelt het zevenstappenproces voor het schrijven van testcases, drie uitgewerkte voorbeelden en hoe u een testsuite betrouwbaar kunt houden naarmate het product verandert.
Wat zijn testcases?
Een testcase is een gestructureerd document waarin de exacte stappen, invoergegevens, randvoorwaarden en verwachte resultaten worden gedefinieerd die nodig zijn om te verifiëren of een specifiek stuk software correct functioneert. Het is geen testplan (waarin de teststrategie wordt uiteengezet) of een testscript (geautomatiseerde code die de stappen programmatisch uitvoert). Een testcase is de specificatie waarop beide zijn gebaseerd.
Voorbeeld: Je test de inlogfunctionaliteit van een webapplicatie. Een testcase voor deze functie zou de volgende elementen definiëren:
- Acties die de stappen beschrijven die een gebruiker uitvoert en de verwachte reacties van het systeem
- Voorwaarden die de regels definiëren waaraan moet worden voldaan voordat het systeem verder kan gaan met elke stap
- Voer gegevens in met steekproefwaarden om verschillende uitkomsten te testen en zowel succesvolle als mislukte scenario's te verifiëren
Handmatige versus geautomatiseerde testcases: een vergelijking
AI maakt tegenwoordig deel uit van de meeste werkstroomen van testen. 76,8% van de testprofessionals gebruikt AI bij kwaliteitsborging, waarbij het aanmaken van testcases (69,6%) en het onderhouden van scripts (59,6%) de twee meest voorkomende toepassingen zijn, volgens het ‘State of Testing Report 2026’ van PractiTest. Die verschuiving is het duidelijkst zichtbaar bij geautomatiseerde testcases, dus het is de moeite waard om te weten hoe deze verschillen van handmatige testcases.
| Parameter | Handmatige testcases | Geautomatiseerde testcases |
|---|---|---|
| Uitvoering | Uitgevoerd door een menselijke tester die een reeks gedocumenteerde stappen volgt | Uitgevoerd door softwaretools, scripts of AI-agenten |
| Snelheid | Traag en tijdrovend, omdat mensen gegevens handmatig moeten invoeren en de resultaten moeten controleren | Honderden testcases tegelijk uitvoeren |
| Herhaalbaarheid | Gevoelig voor menselijke fouten en inconsistente interpretatie van stappen | Zeer herhaalbaar en consistent wanneer testscripts goed worden onderhouden |
| CI/CD-integratie | Moeilijk te integreren in snel veranderende leveringspijplijnen vanwege menselijke knelpunten | Integreert rechtstreeks in CI/CD-pijplijnen om bij elke build tests uit te voeren |
| Onderhoud | Vereist handmatige aanpassingen aan documenten wanneer de vereisten veranderen | Vereist technisch onderhoud om scripts bij te werken wanneer de gebruikersinterface of de logica verandert |
| Ideaal voor | Verkennende tests | Herhalingstests en regressietests |
Waarom goed geschreven testcases belangrijk zijn
Je ontdekt regressies voordat gebruikers tickets indienen. Elke wijziging in de code brengt het risico met zich mee dat iets wat al werkt, niet meer werkt. Een goed geschreven testcase fungeert als een vast controlepunt dat na elke implementatie wordt uitgevoerd. Wanneer een ontwikkelaar een jaar later je inlogcode herstructureert en per ongeluk de functies voor sessiebeheer verstoort, is het die testcase die dit in de fase van staging signaleert.
Zorg dat 'geslaagd/mislukt' een feit is, geen mening. Vage verwachte resultaten zoals “het systeem reageert op de juiste manier” dwingen elke tester om te interpreteren wat “op de juiste manier” precies betekent. Twee testers voeren dezelfde test uit, de ene markeert deze als geslaagd, de andere meldt een defect, en nu is het team bezig met het oplossen van het meningsverschil in plaats van de software. Als je verwachte resultaat luidt: ‘het systeem geeft de foutmelding ‘Ongeldig wachtwoord’ weer en houdt de gebruiker op de inlogpagina’, is er geen ruimte voor interpretatie. Het resultaat klopt of het klopt niet. Dat is de ‘twee-personenregel’ in de praktijk: de testcase is de maker, de tester is de controleur, en ze moeten allebei dezelfde taal spreken.
Je zet impliciete kennis om in een herbruikbare bron. In de meeste teams draagt de senior QA-engineer een onzichtbare kaart bij zich van elke randgeval, elke workaround, elke „oh, vergeet niet ook X te controleren“. Wanneer die persoon met verlof gaat of van team verandert, gaat die kaart mee. Gedocumenteerde testcases met expliciete voorwaarden en grenswaarden bewaren die kennis op een gestructureerde manier. Een nieuwe tester die bij het team komt, kan op de eerste dag TC_LOGIN_005 oppakken en de werkstroom ‘accountvergrendeling na vijf pogingen’ testen, zonder aan iemand te hoeven vragen wat de drempel is of hoe de timer wordt gereset.
Je lokaliseert fouten tot exacte stappen, niet tot algemene gebieden. Wanneer een testcase “navigeer naar de pagina, voer inloggegevens in en klik op verzenden” in één enkele stap bundelt en de test mislukt, weet je alleen dat “er iets in de werkstroom van het inlogproces is misgegaan”. ” Wanneer elke actie een eigen stap is met een eigen verwacht resultaat, valt de fout op stap 4: ‘Klik op “Reset-link verzenden” → verwacht succesbericht, kreeg 500-fout. ’ Die precisie verkort de foutopsporingstijd drastisch, omdat de ontwikkelaar precies weet welke interactie de fout heeft triggerd, en niet alleen in welk functiegebied hij moet zoeken.
Je ziet wat er gedekt is en wat een blinde vlek is. Zonder gestructureerde testcases is testdekking giswerk. Met gestructureerde testcases kun je elk scenario in kaart brengen en hiaten direct opsporen. Als je functie voor het resetten van wachtwoorden zes scenario’s kent (succesvolle reset, verlopen link, hergebruikte link, niet-geregistreerd e-mailadres, ongeldig format, meerdere verzoeken) en je hebt slechts testcases voor drie daarvan, dan is de leemte zichtbaar en meetbaar. Die zichtbaarheid zorgt ervoor dat testen verandert van “we hebben het getest” naar “dit is precies wat we hebben getest, dit is wat we niet hebben getest, en dit is het risico dat we accepteren.”
Onderdelen van een goede testcase
Een bruikbare testcase doet meer dan alleen beschrijven wat er getest moet worden. Het legt de context, de uitvoeringsstappen en het verwachte systeemgedrag vast, zodat een andere tester, ontwikkelaar of productmanager de test kan herhalen en het resultaat kan verifiëren.
De onderdelen van een testcase zijn:
- Unieke identificatiecode
- Doel of beschrijving
- Voorwaarden
- Uitvoeringsstappen
- Verwachte resultaten
- Werkelijke resultaten ter vergelijking
Voor het voorbeeld van de inlogfunctie op de website dat we hierboven hebben gedeeld, moet je testcase het volgende bevatten:
Testcase-ID: Elke testcase heeft een unieke ID nodig. Bij het testen van een functie maken QA-teams vaak meerdere testcases aan die vergelijkbare voorwaarden valideren. De testcase-ID helpt bij het eenvoudig bijhouden, ordenen en terugvinden ervan tijdens het opsporen van fouten of tijdens de rapportage.
Voorbeeld: TC_LOGIN_001
Beschrijving: Hierin wordt uitgelegd welke functies de testcase valideert. Het biedt een korte samenvatting, zodat iedereen die de testcase leest onmiddellijk het doel ervan begrijpt.
Voorbeeld: Controleer of een geregistreerde gebruiker met geldige inloggegevens succesvol kan inloggen op de applicatie.
Voorwaarden: Voorwaarden beschrijven de systeemtoestand die vereist is voordat de testcase wordt uitgevoerd. Zonder deze voorwaarden kunnen testers dezelfde test onder verschillende voorwaarden uitvoeren en inconsistentie in de resultaten krijgen.
Voorbeelden:
- Het gebruikersaccount moet al in het systeem bestaan
- Het gebruikersaccount moet actief zijn en mag niet vergrendeld zijn
- De inlogpagina moet toegankelijk zijn
Stappen: Dit zijn de handelingen die een gebruiker of tester uitvoert om de testcase uit te voeren. Elke stap moet duidelijk en logisch op elkaar aansluitend zijn, zodat iedereen in het team de test kan reproduceren.
- De gebruiker gaat naar de inlogpagina
- De gebruiker voert een geregistreerd e-mailadres in
- De gebruiker voert het juiste wachtwoord in
- De gebruiker klikt op de knop Inloggen
Verwachte resultaten: Dit beschrijft wat het systeem zou moeten doen als de functie correct werkt.
- Als de inloggegevens geldig zijn, voert het systeem de verificatie van de gebruiker uit
- De gebruiker wordt doorgestuurd naar het dashboard
- Een gebruikerssessie is succesvol aangemaakt
Als de inloggegevens ongeldig zijn, moet het systeem de juiste fout weergeven.
Werkelijke resultaten: deze geven de observaties van de tester weer na het uitvoeren van de testcase. Als het waargenomen gedrag afwijkt van het verwachte resultaat, wordt het probleem geregistreerd als een defect.
Exemplaar van een observatie:
- Je hebt geldige inloggegevens ingevoerd, maar kreeg de foutmelding "Ongeldig wachtwoord"
Laten we nu je vaardigheden op het gebied van het schrijven van testcases in de praktijk brengen.
Wist u dat? Slechts 2,1% van de teams beschrijft hun AI-testpraktijken als geoptimaliseerd, terwijl meer dan 85% zich nog in de begin- of experimentele fase bevindt. De meest voorkomende toepassing is het genereren van testcases (69,6%), en niet strategisch werk zoals risico-identificatie (19,9%).
Hoe schrijf je testcases (stapsgewijze handleiding)
Het schrijven van een testcase bestaat uit zeven stappen: analyseer de vereisten, maak een lijst van scenario's, plan de structuur, schrijf stappen met verwachte resultaten, voeg een bijlage toe, laat het beoordelen, voer het vervolgens uit en registreer de resultaten.
Stap 1: Analyseer de vereisten
Voordat je de testcase schrijft, moet je begrijpen wat de functie moet doen. Hiervoor bekijk je de beschikbare documenten – PRD's (productvereistendocumenten), user stories, functiespecificaties en ontwerpdocumenten – en breng je alle functionaliteiten in kaart die moeten worden getest.
Voorbeeld: Je bouwt een functie waarmee gebruikers hun wachtwoord via e-mail kunnen resetten. Om hiervoor een testcase te maken, moet je het volgende begrijpen:
- Welk probleem lost deze functie op, d.w.z. kan een gebruiker weer toegang krijgen tot zijn account als hij zijn wachtwoord is vergeten?
- Welke acties kan de gebruiker uitvoeren, d.w.z. een resetlink aanvragen, deze via e-mail ontvangen en een nieuw wachtwoord instellen?
- Wat moet er gebeuren wanneer die acties worden uitgevoerd, d.w.z. stuurt het systeem een resetlink en kan de gebruiker zijn wachtwoord succesvol wijzigen?
- Zijn er beperkingen, d.w.z. verloopt de link na een bepaalde tijd of wordt deze na één keer gebruik ongeldig?
- Zijn er validaties of regels, d.w.z. moet het nieuwe wachtwoord aan specifieke vereisten qua format of lengte voldoen?
- Is er een functie die vaag of onduidelijk is? Zo ja, vraag dan om verduidelijking bij de betrokken belanghebbende
Deze duidelijkheid biedt je de basis om één duidelijke doelstelling voor je testcase te formuleren.
Doelstelling: Controleer of een geregistreerde gebruiker zijn of haar wachtwoord succesvol kan resetten via e-mail.
Stap 2: Bepaal verschillende testscenario’s
Maak vervolgens een lijst van de testscenario's die je moet valideren. Een testscenario is een situatie op hoog niveau – een situatie die doorgaans uitmondt in meerdere testcases die verschillende invoergegevens en uitkomsten bestrijken.
Voor de functie voor het opnieuw instellen van het wachtwoord zouden je scenario's er als volgt uit kunnen zien:
- Succesvolle reset: Controleer of een geregistreerde gebruiker een resetlink kan aanvragen en een nieuw wachtwoord kan instellen
- Niet-geregistreerd e-mailadres: Test wat er gebeurt wanneer een e-mailadres wordt ingevoerd dat niet in het systeem voorkomt
- Verlopen link: Controleer of het systeem de toegang blokkeert wanneer er op de resetlink wordt geklikt nadat deze is verlopen
- Hergebruikte link: Test of een reeds gebruikte resetlink niet opnieuw kan worden gebruikt
- Ongeldig nieuw wachtwoord: Controleer of wachtwoorden die niet aan het format voldoen, worden afgewezen
- Meerdere resetverzoeken: Test welke link geldig blijft wanneer een gebruiker er meerdere achter elkaar aanvraagt
Elk scenario hier wordt omgezet in één of meer testcases die specifieke invoergegevens en voorwaarden bestrijken. Door de functie op deze manier op te splitsen, zorg je ervoor dat je testdekking hebt voor zowel het verwachte gedrag als de randgevallen waarmee echte gebruikers onvermijdelijk te maken zullen krijgen.
Lees meer: Hoe maak en implementeer je een QA-checklist
Stap 3: Plan de test en stel de structuur van de testcases vast
Voor repetitieve regressietests heb je een structuur nodig waarmee je je testcase en de resultaten ervan consistent kunt documenteren. Een goed gedefinieerd sjabloon voor testcases zorgt voor die consistentie en maakt hergebruik mogelijk, zodat je niet elke keer helemaal opnieuw hoeft te beginnen.
Plan de uitvoering van je tests door de volgende elementen te verduidelijken:
Wie voert de test uit?
Welke rol of kwalificatie moet de persoon die deze test uitvoert hebben? Wijs rollen toe afhankelijk van de complexiteit van de test en de vereiste menselijke tussenkomst:
- QA-tester: Functionele en regressietests, zoals het controleren van inlogwerkstroomen, formuliervalidaties of afrekenprocessen
- Team voor veiligheid: Tests met betrekking tot verificatie, toegangscontrole of kwetsbaarheden op het gebied van gegevensblootstelling
- Ontwikkelaar: Unit-tests voor afzonderlijke functies, zoals het hashen van wachtwoorden of het genereren van tokens
Hoe wordt de test uitgevoerd?
- Op welke apparaten en besturingssystemen wordt de test uitgevoerd?
- Welke tools of testframeworks worden er gebruikt?
- Wordt de test handmatig uitgevoerd of via een AI-agent?
- Hoe worden de resultaten vastgelegd: in een testbeheertool, een spreadsheet of een bugtracker?
Wat zijn de voorwaarden?
Maak een lijst van alle voorwaarden die moeten zijn vervuld vóór stap 1, en zorg ervoor dat de tester elke voorwaarde kan controleren:
Voorbeeld:
- Er bestaat een gebruikersaccount met het e-mailadres “test@example.com”
- De gebruiker is uitgelogd uit het systeem
- De e-mailservice is actief en kan berichten verzenden
- De testomgeving is toegankelijk en actief
Welke testgegevens worden gebruikt?
Bepaal de exacte waarden die nodig zijn om de test uit te voeren: geldige gegevens, ongeldige gegevens en grenswaarden.
Voorbeeld:
- Geldig: geregistreerd e-mailadres “test@example. com”, wachtwoord voldoet aan het format voor wachtwoorden
- Ongeldig: niet-geregistreerd e-mailadres, wachtwoord voldoet niet aan de minimale limiet aan tekens
- Grenswaarde: wachtwoord dat precies de limiet voor het aantal tekens van het minimum en het maximum heeft
Stap 4: Schrijf de teststappen en de verwachte resultaten op
Verdeel het uitvoeringsproces in opeenvolgende stappen. Gebruik consistente terminologie en zorg ervoor dat elke stap uit één actie bestaat. Geef bij het definiëren van stappen ook aan wat het verwachte resultaat is en wat als geslaagd of mislukt wordt beschouwd.
In het verlengde van onze werkstroom voor het opnieuw instellen van wachtwoorden zouden de teststappen er als volgt uitzien:
| Stappen | Verwacht resultaat |
| Ga naar de inlogpagina | De inlogpagina wordt geladen met een klikbare link ‘Wachtwoord vergeten’ |
| Klik op ‘Wachtwoord vergeten’ | De gebruiker wordt doorgestuurd naar de pagina voor het aanvragen van een nieuw wachtwoord |
| Vul je e-mailadres in het veld 'E-mail' in | E-mailadres is geaccepteerd zonder validatiefout |
| Klik op ‘Resetlink verzenden’ | Er verschijnt een succesmelding: “Resetlink verzonden naar test@example.com” |
| Open de resetlink uit de e-mail | De gebruiker wordt doorgestuurd naar de pagina voor het aanmaken van een nieuw wachtwoord |
| Voer een geldig nieuw wachtwoord in | Het wachtwoordveld accepteert invoer zonder foutmelding |
| Klik op 'Wachtwoord opnieuw instellen' | Er verschijnt een succesmelding en de gebruiker wordt doorgestuurd naar de inlogpagina |
Definieer nu de stappen en verwachte resultaten voor alternatieve scenario’s (zoals eerder besproken). Geef aan wat er gebeurt als de gebruiker een ongeldig e-mailadres invoert of als het wachtwoord niet voldoet aan de vooraf vastgestelde criteria.
Bonus: Zo kun je de automatisering van de documentatie voor al je testcases uitvoeren met behulp van AI.
Stap 5: Voeg relevante bijlagen toe
Voeg relevante documenten of bijlagen toe die testers helpen de testcase in de volledige context en zonder dubbelzinnigheid uit te voeren. Dit kan het volgende omvatten:
- Schermafbeeldingen met toelichting van de gebruikersinterface bij belangrijke stappen
- Schermopnames die laten zien hoe je de test in verschillende scenario's uitvoert en welke resultaten je kunt verwachten
- Systeemlogboeken of configuratiebestanden om backend-problemen te diagnosticeren wanneer een test mislukt
- Vereistendocumenten waarin de testcase wordt in kaart gebracht bij de user story of de acceptatiecriteria die deze valideert
- Testgegevensbestanden met geldige en ongeldige invoer, of gegenereerde gegevens zoals creditcardnummers, willekeurige adressen of gegevens van gebruikers
- Stel documentatie op met informatie over de specifieke softwareversie, de vereiste hardware, het besturingssysteem en eventuele vereiste machtigingen voor veiligheid
- Voor het testen van API's: OpenAPI-specificaties of endpointdocumentatie met gedetailleerde informatie over verzoekmethoden, parameters en verwachte statuscodes
Stap 6: Laat de testcase beoordelen
Deel de geschreven testcase met een collega of senior QA-leider voordat je deze uitvoert. Controleer tijdens de beoordeling of:
- De testcase is uitgebreid en omvat alle mogelijke scenario's die voortvloeien uit de vereisten
- De stappen zijn duidelijk en geven de daadwerkelijke werkstroom weer
- Elk verwacht resultaat verwijst naar een waarneembare uitkomst (een bericht, een omleiding, een statuscode), niet naar een eigenschap zoals ‘werkt correct’
- Testgegevens en randvoorwaarden zijn voltooid en nauwkeurig
- Alle aannames die tijdens het schrijven worden gedaan, worden expliciet gedocumenteerd
Stap 7: Voer de tests uit en registreer de resultaten
Voer de test uit en noteer het daadwerkelijke resultaat naast elk verwachte resultaat. Markeer een test bij elke stap als geslaagd of mislukt. Meld voor elke mislukte stap onmiddellijk een bug en koppel deze aan de testcase. Als er bovendien onverwacht gedrag optreedt dat niet duidelijk als geslaagd of mislukt kan worden aangemerkt, noteer dit dan in het veld voor aantekeningen voor verdere beoordeling.
Voorbeelden van het schrijven van testcases
Deze drie voorbeelden laten zien hoe dezelfde testcasestructuur kan worden aangepast aan verschillende soorten softwaretests. Elk voorbeeld maakt gebruik van de onderdelen en het format voor stappen dat eerder in deze handleiding is beschreven, maar de complexiteit, de testgegevens en de foutmodi variëren afhankelijk van wat je controleert.
Voorbeeld 1: Afrekenwerkstroom bij e-commerce (gebruikersinterface, meerstapswerkstroom)
Een QA-team bij een online retailer test de afrekenprocedure voorafgaand aan een feestdaguitverkoop. De werkstroom omvat meerdere pagina’s: winkelwagen → verzending → betaling → bevestiging. De grootste uitdaging hierbij is de afhankelijkheid van de status: elke stap is afhankelijk van de correcte voltooiing van de vorige stap, en de testgegevens (inhoud van de winkelwagen, verzendadres, betaalmethode) moeten in alle stappen behouden blijven.
Tester: Rahul D.
Testdatum: 09-03-2026
Testcase-ID: TC_CHECKOUT_003
Beschrijving: Controleer of een ingelogde gebruiker een aankoop kan voltooien met een opgeslagen creditcard en standaardverzending.
Vereisten:
- Er bestaat een gebruikersaccount met ten minste één opgeslagen kredietkaart en één opgeslagen verzendadres
- Er is ten minste één item op voorraad en aan het winkelmandje toegevoegd
- De testomgeving draait op Chrome 128, macOS
| Stap | Verwacht resultaat | Werkelijk resultaat | Geslaagd/Niet geslaagd |
| Ga naar de winkelwagenpagina | De winkelwagen toont het juiste item, de juiste hoeveelheid en het juiste subtotaal | Zoals verwacht | Geslaagd |
| Klik op ‘Doorgaan naar afrekenen’ | De verzendpagina wordt geladen met het opgeslagen adres vooraf geselecteerd | Zoals verwacht | Geslaagd |
| Selecteer 'Standaardverzending' en klik op Doorgaan | De betaalpagina wordt geladen en toont het totaalbedrag van de bestelling inclusief verzendkosten | Zoals verwacht | Geslaagd |
| Bevestig de opgeslagen kredietkaartgegevens en klik op ‘Bestelling plaatsen’ | De pagina met de bestelling wordt weergegeven met het nummer van de bestelling, een overzicht van de items en de geschatte leverdatum | De betaalpagina wordt opnieuw geladen met de foutmelding: “Betaling kan niet worden verwerkt” | Mislukt |
Samenvatting van de resultaten: De afrekenwerkstroom verwerkt de overgang van winkelwagen naar verzending correct, maar de betalingsverwerking mislukt bij opgeslagen kredietkaarten. Geregistreerd defect: het opzoeken van de tokenized kaart loopt vast wanneer de betalingsgateway langer dan 3 seconden nodig heeft om te reageren.
Voorbeeld 2: REST API-eindpunt (geen gebruikersinterface, validatie van invoer en uitvoer)
Een backend-engineer test het API-eindpunt ‘Gebruiker aanmaken’ voordat het door het frontend-team wordt gebruikt. Er is geen interface om doorheen te klikken: de testcase valideert rechtstreeks de payloads van verzoeken, responscodes en de persistentie van gegevens. De belangrijkste uitdaging is het testen van de afspraken tussen systemen, niet de gebruikerservaring.
Tester: Sarah S.
Testdatum: 09-05-2026
Testcase-ID: TC_API_USER_001
Beschrijving: Controleer of een POST-verzoek naar /api/v1/users een nieuwe gebruiker aanmaakt en de juiste reactie retourneert.
Vereisten:
- De API-testomgeving is actief en toegankelijk
- Er is een authenticatietoken met toestemming voor beheerders gegenereerd en dit is geldig
- Er bestaat geen gebruiker met het e-mailadres “newuser@testdomain.com” in de database
| Stap | Verwacht resultaat | Werkelijk resultaat | Geslaagd/Mislukt |
| Stuur een POST-verzoek naar /api/v1/gebruikers met de volgende geldige payload: { "naam": "Testgebruiker", "e-mail": "newuser@testdomain.com", "rol": "viewer" } | Het antwoord retourneert 201 Created met een JSON-body die de gebruikers-ID, naam, e-mail en rol bevat | 201 geretourneerd met correcte body | Geslaagd |
| Verzend hetzelfde POST-verzoek nogmaals met hetzelfde e-mailadres | De respons geeft een 409-foutmelding met de tekst: “Er bestaat al een gebruiker met dit e-mailadres” | 200 OK geretourneerd; dubbele gebruiker aangemaakt | Mislukt |
| Verzend een POST-verzoek waarbij het veld ‘e-mail’ ontbreekt | De respons geeft een 400 Bad Request-fout terug met de validatiefout: “E-mailadres is verplicht” | 400 geretourneerd, zoals verwacht | Geslaagd |
| Voer de GET-query /api/v1/users/{id} uit met het ID uit stap 1 | De respons retourneert 200 OK en de gegevens van de gebruiker komen overeen met de oorspronkelijke payload | Zoals verwacht | Geslaagd |
Samenvatting van de resultaten: Het eindpunt maakt gebruikers correct aan en valideert verplichte velden, maar dwingt de uniekheid van e-mailadressen niet af op databaseniveau. Er werden zonder foutmelding dubbele records aangemaakt. Defect geregistreerd met ernstgraad: Hoog.
Voorbeeld 3: Op rollen gebaseerde toegangscontrole (veiligheid, toestemminggrenzen)
Een beveiligingsteam test voorafgaand aan een compliance-audit of de applicatie acties correct beperkt op basis van gebruikersrollen. De uitdaging hierbij is dat je niet test of een functie werkt, maar of een functie correct wordt geweigerd. Het verwachte resultaat voor de meeste stappen is een blokkering, niet een succes.
Tester: Marcus L.
Testdatum: 09-08-2026
Testcase-ID: TC_RBAC_002
Beschrijving: Controleer of een gebruiker met de rol ‘Viewer’ geen projecten kan aanmaken, bewerken of verwijderen.
Vereisten:
- Er zijn twee accounts: één met de rol ‘Beheerder’ en één met de rol ‘Viewer’
- Er is ten minste één project in de werkruimte aanwezig, aangemaakt door de beheerder
- De gebruiker is ingelogd op Firefox 130, Windows 11
| Stap | Verwacht resultaat | Werkelijk resultaat | Geslaagd/Mislukt |
| Ga naar de pagina ‘Projecten’ | De kijker ziet de projectlijst in de alleen-lezenmodus; de knop ‘Project aanmaken’ is verborgen of uitgeschakeld | De knop is zichtbaar, maar grijs weergegeven | Geslaagd |
| Probeer op ‘Project aanmaken’ te klikken | Het systeem blokkeert de actie; het formulier voor een nieuw project wordt niet geladen | Er is geen formulier geladen; de tooltip geeft aan: "Je hebt geen toestemming" | Geslaagd |
| Open een bestaand project en probeer de titel te bewerken | Het titelveld kan niet worden bewerkt, of het systeem blokkeert het opslaan | Het veld ‘Titel’ was bewerkbaar; wijzigingen zijn succesvol opgeslagen | Mislukt |
| Probeer het project te verwijderen via het menu met de drie puntjes | De optie 'Verwijderen' is verborgen of de actie wordt geblokkeerd door een fout in de toestemming | De optie ‘Verwijderen’ heeft geen zichtbaarheid in het menu | Geslaagd |
Samenvatting van de resultaten: De toestemmingen voor het aanmaken en verwijderen van items zijn correct beperkt voor ‘Viewers’, maar de toestemmingen voor bewerking worden niet afgedwongen op veldniveau. Een ‘Viewer’ kan projecttitels wijzigen ondanks dat hij of zij alleen-lezen-toegang heeft. Defect geregistreerd met ernstgraad: Kritiek (belemmering voor naleving).
Welke tools zijn het meest geschikt voor het beheren van testcases?
Testcases kunnen worden beheerd in een speciale QA-tool (TestRail, Zephyr), een algemene PM-tool (ClickUp, Jira) of een spreadsheet; de juiste keuze hangt af van of je ingebouwde uitvoering nodig hebt of alleen het bijhouden van de voortgang.
ClickUp
ClickUp for Software Teams is een projectmanagementplatform waarop testcases als taken worden weergegeven, naast de Sprints, bugs en pull-aanvragen waarmee ze verband houden. Het is geen speciale tool voor testmanagement, maar dankzij de flexibele taakstructuur kunnen teams testcase-werkstroomen opzetten met behulp van aangepaste statussen, velden en taaktypen, zonder dat daarvoor een aparte tool nodig is.
Belangrijkste functies van ClickUp
- Flexibele hiërarchie om testcases te ordenen in ruimtes, mappen en lijsten met aangepaste velden voor testtype, prioriteit en omgeving
- Meer dan 15 ClickUp-weergaven (bord, lijst, tabel) om de uitvoering van tests bij te houden op basis van status, toegewezen persoon of Sprint
- Documentatie voor het bijhouden van PRD's, testplannen en handleidingen voor de installatie van de omgeving, naast de testcases waarop deze betrekking hebben
- Ingebouwde mogelijkheid om te chatten voor communicatie tussen QA-medewerkers en ontwikkelaars, zonder dat je hoeft over te schakelen naar Slack of e-mail
- Door AI aangestuurde taakoverzichten via ClickUp Brain voor snelle context tijdens sprintreviews
Limieten van ClickUp
- Geen ingebouwde engine voor het uitvoeren van tests
- Voor testspecifieke rapporten (dekking per vereiste, slagingspercentage per cyclus) zijn aangepaste dashboards nodig in plaats van kant-en-klare QA-rapportages
Prijzen van ClickUp
Beoordelingen en recensies van ClickUp
- G2: 4,6/5 (meer dan 14.100 beoordelingen)
- Capterra: 4,6/5 (meer dan 4600 beoordelingen)
Wat zeggen echte gebruikers over ClickUp?
Dit is wat een G2-recensent te zeggen heeft:
Wat ik het leukste vind aan ClickUp is dat alles op één plek wordt samengebracht. Taken, tijdlijnen, aantekeningen en updates staan allemaal in hetzelfde systeem, waardoor het heen en weer schakelen tussen verschillende tools wordt verminderd. Ik waardeer ook de flexibiliteit. We kunnen statussen, velden en weergaven aanpassen aan de manier waarop ons team daadwerkelijk werkt. Dat maakt het makkelijker om georganiseerd te blijven en biedt duidelijk zichtbaarheid in wie waarvoor verantwoordelijk is en hoe ver projecten op elk moment zijn gevorderd.
Wat ik het leukste vind aan ClickUp is dat alles op één plek wordt samengebracht. Taken, tijdlijnen, aantekeningen en updates bevinden zich allemaal in hetzelfde systeem, waardoor er minder heen en weer geswitcht hoeft te worden tussen verschillende tools. Ik waardeer ook de flexibiliteit. We kunnen statussen, velden en weergaven aanpassen aan de manier waarop ons team daadwerkelijk werkt. Dat maakt het makkelijker om georganiseerd te blijven en biedt duidelijk zichtbaarheid in wie waarvoor verantwoordelijk is en hoe projecten er op elk moment voor staan.
Meest geschikt voor: Een QA-leider die wil dat een mislukte test met één klik wordt omgezet in een bugticket voor een ontwikkelaar, waarbij de PR, de teststappen en de Sprint allemaal vanuit dezelfde Taak zichtbaar zijn.
Sla dit over als: je testcyclus grotendeels geautomatiseerd is. Als 80% van je testsuite via een CI-pijplijn wordt uitgevoerd, heb je een tool nodig die de uitvoeringsresultaten automatisch verwerkt, en geen tool waarbij een medewerker de status handmatig bijwerkt.
TestRail
TestRail is een speciaal testbeheerplatform dat is ontwikkeld voor QA-teams die behoefte hebben aan gestructureerde controle over hun volledige testproces. Het platform ondersteunt de volledige cyclus van het schrijven, uitvoeren en uitvoeren van rapportage over testcases, waarbij resultaten worden aangeleverd via DevOps- en CI/CD-integraties.
Belangrijkste functies van TestRail
- Gecentraliseerd beheer van testcases en testsuites met herbruikbare testcases voor verschillende projecten
- Testplannen en mijlpalen om testruns over sprints en releases heen te organiseren en in te plannen
- Gedetailleerde rapportage met dekkingsanalyse, voortgang bijhouden en uitvoeringsgeschiedenis
- Integraties met Jira, GitHub, Jenkins, Azure DevOps en meer dan 20 andere DevOps-tools
- REST API voor de automatisering van taken en het synchroniseren van testgegevens met externe systemen
Limieten van TestRail
- Er is geen ingebouwde functie voor het bijhouden van vereisten of problemen – teams moeten een beroep doen op externe tools zoals Jira, wat de traceerbaarheid kan versnipperen
- Een op mappen gebaseerde organisatie wordt moeilijk te doorgronden naarmate testopslagplaatsen uitgroeien tot duizenden
Prijzen van TestRail
- Professional: $39 per zetel per maand
- Enterprise: $78 per zetel per maand
Beoordelingen en recensies van TestRail
- G2: 4,4/5 (meer dan 600 beoordelingen)
- Capterra: 4,3/5 (meer dan 160 beoordelingen)
Wat zeggen echte gebruikers over TestRail?
Dit is wat een G2-recensent te zeggen heeft:
Wat ik het meest waardevol vind aan TestRail, is dat het ons QA-team een veilige en goed georganiseerde omgeving biedt om testplannen, testcases en testruns te beheren. Ik waardeer hoe eenvoudig het is om testsuites te structureren en te implementeren, en om eerder gemaakte testcases te hergebruiken. De integraties met Jira en CI/CD-tools hebben onze werkstroom samenhangender en gemakkelijker te volgen gemaakt. De mogelijkheid om de voortgang en de dekking van tests in realtime te volgen, is ongelooflijk nuttig geweest voor sprintplanning en rapportage. In mijn dagelijkse werk als QA-engineer heeft het gebruik van TestRail me ook veel tijd bespaard.
Wat ik het meest waardevol vind aan TestRail, is dat het ons QA-team een veilige en overzichtelijke omgeving biedt voor het beheren van testplannen, testcases en testruns. Ik waardeer hoe eenvoudig het is om testsuites te structureren en te implementeren, en om eerder gemaakte testcases te hergebruiken. De integraties met Jira en CI/CD-tools hebben onze werkstroom samenhangender en gemakkelijker te bijhouden gemaakt. De mogelijkheid om de voortgang en de dekking van tests in realtime te volgen, is ongelooflijk nuttig geweest voor sprintplanning en rapportage. In mijn dagelijkse werk als QA-engineer heeft het gebruik van TestRail me ook veel tijd bespaard.
Meest geschikt voor: Een QA-team van vijf of meer personen dat per release formele testcyclusen uitvoert, waarbij een manager vanuit een dashboard – en niet vanuit een spreadsheet – moet kunnen beantwoorden: “Welk percentage van Release 2.0 is uitgevoerd en geslaagd?”
Sla dit over als: je testsuite uit minder dan een paar honderd testcases bestaat of je testers tevens als ontwikkelaars fungeren. Bij die omvang zijn de kosten per gebruiker en de aparte login alleen maar een extra uitgave voor rapportages die je toch niet zult bekijken.
Zephyr
Zephyr is de testbeheer-plug-in van SmartBear voor Jira, ontwikkeld om testcases rechtstreeks vanuit de Jira-interface te beheren. De plug-in ondersteunt zowel handmatig als geautomatiseerd testen en biedt krachtige rapportage- en traceerbaarheidsfuncties voor agile- en enterprise-teams.
Belangrijkste functies van Zephyr
- Native Jira-integratie: maak testcases aan, koppel ze en voer ze uit, rechtstreeks vanuit Jira-problemen
- Projectoverschrijdende hiërarchische testbibliotheken voor het hergebruiken en organiseren van testcases op grote schaal
- Meer dan 70 kant-en-klare rapporten over testdekking, voortgang van de uitvoering en het bijhouden van defecten
- BDD-ondersteuning die Gherkin-syntaxis gebruikt voor gedragsgestuurde werkstroom
- CI/CD-integraties met Jenkins, GitHub, GitLab, Bitbucket en Bamboo
Limieten van Zephyr
- Licentie per Jira-gebruiker, niet per tester
- Grote opslagplaatsen voor testen (met duizenden testcases) kunnen lastiger te doorzoeken zijn dan in op zichzelf staande tools zoals TestRail
- Ondersteuning verloopt via de Atlassian Marketplace, wat een extra stap betekent voor teams die gewend zijn aan directe ondersteuning door de leverancier
Prijzen van Zephyr
- Essential: vanaf $ 5,99 per gebruiker per maand (11-50 gebruikers)
- Standard: vanaf $ 6,81 per gebruiker per maand (11-50 gebruikers)
- Advanced: vanaf $8,73 per gebruiker per maand (11-50 gebruikers)
Beoordelingen en recensies van Zephyr
- G2: 4,1/5 (meer dan 80 beoordelingen)
- Capterra: Onvoldoende beoordelingen
Wat zeggen echte gebruikers over Zephyr?
Dit is wat een G2-recensent te zeggen heeft:
Dit is de beste tool om testcases rechtstreeks vanuit een Excel-sheet te importeren. Met deze tool kost het werk van testers minder tijd dan het importeren van testcases in Jira. Een andere geweldige functie van deze tool is de mogelijkheid om testcases als geslaagd of mislukt te markeren en bijlagen toe te voegen.
Dit is de beste tool om testcases rechtstreeks vanuit een Excel-sheet te importeren. Met deze tool kost het testers minder werk dan het importeren van testcases in Jira. Een andere geweldige functie van deze tool is de mogelijkheid om testcases als geslaagd of mislukt te markeren en bijlagen toe te voegen.
Meest geschikt voor: Teams die onder strenge regelgeving vallen of veel te maken hebben met audits (fintech, gezondheidszorg) en waarbij elke test moet worden gekoppeld aan een Jira-vereiste en elk defect moet worden gekoppeld aan de test waarmee het is ontdekt, allemaal binnen één Atlassian-Instance.
Sla dit over als: uw Jira-Instance groot is en uw QA-team klein. Een Jira-Instance met 200 licenties en 10 testers kost 190 Zephyr-licenties die niemand opent; een op zichzelf staande tool die per tester wordt geprijsd, is goedkoper.
Jira
Jira is het platform van Atlassian voor projectmanagement en het bijhouden van problemen, dat op grote schaal wordt gebruikt door engineering- en QA-teams om sprints, problemen en werkstroomen te beheren. Hoewel het geen speciale tool voor testbeheer is, gebruiken veel teams het in combinatie met oplossingen zoals Zephyr Scale of Xray om het beheer van testcases binnen hun bestaande Jira-installatie te regelen.
Belangrijkste functies van Jira
- Scrum- en Kanban-borden voor het beheren van Sprints, backlogs en Agile -werkstroomen
- Aanpasbare werkstroom, probleemtypen en velden die aansluiten bij de manier waarop uw team het werk bijhoudt
- Geavanceerde roadmaps voor teamoverschrijdende planning en het bijhouden van afhankelijkheden (Premium)
- Meer dan 1.000 marktplaatsintegraties, waaronder GitHub, Confluence, Slack en CI/CD-tools
- Automatisering-regels om acties in verschillende projecten te triggeren op basis van updates van problemen of statuswijzigingen
Beperkingen van Jira
- Voor het beheer van testcases is een Marketplace-plug-in (Zephyr Scale, Xray) nodig, waarvoor naast het Jira-abonnement een eigen vergoeding per gebruiker geldt.
- Een steilere leercurve voor niet-technische gebruikers, met opstartkosten die bij grotere teams behoorlijk kunnen oplopen
Prijzen van Jira
- Free
- Standaard: $7,91 per gebruiker per maand
- Premium: $14,54 per gebruiker per maand
- Enterprise: Aangepaste prijzen
Beoordelingen en recensies van Jira
- G2: 4,3/5 (meer dan 7.900 beoordelingen)
- Capterra: 4,4/5 (meer dan 15.400 beoordelingen)
Wat zeggen echte gebruikers over Jira?
Dit is wat een G2-recensent te zeggen heeft:
Jira is een van mijn favoriete digitale programma's voor het bijhouden en visualiseren van de voortgang van al mijn werkprojecten in samenwerking met alle leden van mijn team, omdat het de beste virtuele prestatiemogelijkheden in zijn klasse biedt, waardoor het gemakkelijker wordt om al mijn professionele doelen te bereiken.
Jira is een van mijn favoriete digitale programma's voor het bijhouden en visualiseren van de voortgang van al mijn werkprojecten in samenwerking met alle leden van mijn werkteam, omdat het de beste virtuele prestatiemogelijkheden in zijn klasse biedt, waardoor het gemakkelijker wordt om al mijn professionele doelen te bereiken.
Meest geschikt voor: Technische teams die aan het beoordelen zijn of ze überhaupt behoefte hebben aan specifiek testbeheer. Door eerst een paar testcyclusen uit te voeren als aangepaste Jira-issue-types, wordt duidelijk of de omvang het gebruik van een plug-in rechtvaardigt.
Sla dit over als: je al weet dat je testbeheer nodig hebt. Door direct voor een plug-in of een op zichzelf staande tool te kiezen, vermijd je de migratie wanneer aangepaste issue-types niet meer schaalbaar zijn.
Veelgemaakte fouten die u moet vermijden bij het opstellen van testcases
Vermijd deze fouten bij het schrijven van testcases, die de algehele effectiviteit ervan kunnen verminderen.
| Fout | Wat je in plaats daarvan nog kunt doen |
|---|---|
| Te laat testcases schrijven | Betrek testers bij het vaststellen van de vereisten en de ontwerpfase om mogelijke problemen te identificeren voordat het coderen begint |
| Testcases niet bijwerken | Werk de testcase bij zodra de functie een nieuwe update krijgt, de functionaliteit verandert of de gebruikersinterface wordt aangepast |
| Geen postcondities | Geef aan hoe het systeem eruit moet zien nadat de test is voltooid (testgebruiker verwijderd, winkelwagen leeggemaakt, sessie gesloten), zodat de volgende testcase vanuit een schone toestand begint |
| Alleen 'happy-path'-gegevens | Elk invoerveld moet ten minste één waarde bevatten die het systeem moet afwijzen. Leg vast hoe de dataset wordt gegenereerd of opgehaald |
| Geen prioriteit toekennen aan testcases | Wijs aan elke testcase een prioriteit toe op basis van de impact op het bedrijf, de gebruiksfrequentie en het risico op falen. Zo kun je je testinspanningen gericht inzetten en slimmere beslissingen nemen over het budget en de testmethoden. |
Hoe u testcases op de lange termijn bruikbaar houdt
Een testsuite blijft betrouwbaar wanneer elke test onafhankelijk is, gericht is op de invoergegevens die het meest waarschijnlijk tot fouten leiden, en wordt verwijderd zodra deze geen betrouwbare uitkomst meer oplevert. Deze zes werkwijzen maken het verschil tussen testsuiten die jarenlang bugs opsporen en testsuiten die al na de tweede Sprint worden genegeerd.
Schrijf onafhankelijke, atomaire tests
Een testcase moet zijn eigen toestand opzetten en mag nooit afhankelijk zijn van een andere case die eerst is uitgevoerd. Wanneer TC_CHECKOUT_003 ervan uitgaat dat TC_CHECKOUT_002 een item in het winkelmandje heeft achtergelaten, leidt één fout tot vijf fouten, en ben je de hele ochtend bezig om uit te zoeken welke fout echt was. Als een testtitel het woord ‘en’ bevat, splits deze dan op in twee cases.
Test aan de grenzen
Bugs komen vooral voor aan de randen van de toegestane invoer, niet in het midden. Als een wachtwoordveld 8 tot 128 tekens accepteert, test dan 7, 8, 128 en 129, en niet alleen een 'comfortabel' wachtwoord van 12 tekens. Grenswaardeanalyse is om precies deze reden een formele techniek in de ISO/IEC/IEEE 29119-4-standaard voor testontwerp: het spoort 'off-by-one'-fouten op die bij willekeurige invoer over het hoofd worden gezien.
Gebruik equivalentiepartitionering om overtollige testcases te elimineren
Groepeer invoer die het systeem op dezelfde manier moet behandelen en test vervolgens één representatief voorbeeld uit elke groep. Elk geldig e-mailformat gedraagt zich op dezelfde manier in een inlogformulier, dus één geldig e-mailadres is voldoende. Het testen van user@example.com, jane@company.com en bob@domain.org als drie afzonderlijke testgevallen verdrievoudigt je onderhoudswerk zonder dat dit extra dekking oplevert.
Scheid testgegevens van teststappen
Als je ‘enter test@example.com’ hardcodeert in een stap, moet je die stap elke keer herschrijven wanneer de testomgeving verandert. Houd stappen algemeen (‘voer een geregistreerd e-mailadres in’) en bewaar de daadwerkelijke waarden in een testgegevensveld of -bestand. Dezelfde stappen kunnen dan zonder aanpassingen worden uitgevoerd op de fase-, QA- en preproductieomgevingen, en het vervangen door een nieuwe dataset voor een negatieve test is een wijziging van slechts één regel.
Bijhouden van onbetrouwbare tests en het percentage onopgemerkte fouten bij
Een onbetrouwbare test mislukt wisselend zonder dat er sprake is van een echte productfout, en elke onbetrouwbare test zorgt ervoor dat het team rode resultaten gaat negeren. Houd bij hoe vaak elke testcase bij identieke builds wisselt tussen geslaagd en mislukt. Als een testcase vaker dan een paar keer per maand onbetrouwbaar is, herschrijf of verwijder deze dan. Combineer dit met het defect escape rate (fouten die in de productie worden gevonden en die een testcase had moeten opsporen) om te zien waar de dekking tekortschiet, en niet alleen waar er ruis is.
Automatiseer de tests die je het vaakst uitvoert
Regressie-, smoke- en hoogfrequente functionele testcases lenen zich het best voor automatisering, omdat ze bij elke build worden uitgevoerd en zelden veranderen. Zet deze om in scripts in je CI/CD-pijplijn en gebruik AI-ondersteunde tools met zelfherstellende locators op plaatsen waar UI-elementen vaak verschuiven. Zo blijven menselijke testers vrij voor verkennend werk en voor het soort softwaretesten dat om inzicht vraagt, zoals bruikbaarheidstesten en het opsporen van randgevallen.
Testcases schrijven en uitvoeren in ClickUp
In het gedeelte over tools hierboven wordt besproken waar ClickUp in het plaatje past. In dit gedeelte wordt de daadwerkelijke installatie getoond, in kaart gebracht aan de stappen uit het eerdere deel van de handleiding.
Breng structuur aan in je testcasebibliotheek. Maak een Space aan voor je product, een map voor elk functiegebied (bijv. verificatie, betalingen, onboarding) en een lijst voor elke testcyclus of sprint. Elke taak wordt een afzonderlijke testcase. Gebruik de aangepaste velden van ClickUp om gegevens vast te leggen zoals de testcase-ID, randvoorwaarden, testgegevens, prioriteit en omgeving.
Schrijf teststappen rechtstreeks in de Taak. Gebruik de Taakbeschrijving om opeenvolgende uitvoeringsstappen en verwachte resultaten vast te leggen. Checklists zijn handig voor stapsgewijze werkstroomen waarbij een tester elke actie moet afvinken, terwijl de beschrijving context bevat, zoals randvoorwaarden en testgegevens.
Houd de uitvoering en resultaten bij. Maak aangepaste statussen die aansluiten bij je testwerkstroom: Nog niet gestart → In uitvoering → Geslaagd → Mislukt → Geblokkeerd. Wanneer een test mislukt, zet je deze om in een bugtaak of maak je een gekoppelde taak aan die wordt toegewezen aan de ontwikkelaar, met prioriteit, afhankelijkheden en een deadline. Met de GitHub- en GitLab-integraties kun je die bug rechtstreeks koppelen aan de PR waarin deze is geïntroduceerd. Als de hoofdoorzaak een codefout is, kun je die bugtaak toewijzen aan de ClickUp Codegen Agent, die de taakbeschrijving, gekoppelde specificaties en opmerkingen leest, een voorgestelde oplossing schrijft en een pull-aanvraag opent voor beoordeling, waarbij de voortgang wordt teruggemeld naar de taak.
Pro-tip: QA-leiders kunnen direct een overzicht krijgen van elke taak door ClickUp Brain te vragen een samenvatting te geven van openstaande bugtaken. Zo beschikken ze over alle context die ze nodig hebben voor sprintreviews, zonder dat ze individuele taken hoeven door te spitten om het volledige plaatje te krijgen.
Voer testcycli uit met weergaven. Gebruik de bordweergave, gegroepeerd op status, om tijdens een testrun in één oogopslag de verdeling tussen geslaagd en mislukt te zien. De tabelweergave werkt als een traditionele testmatrix wanneer je de resultaten van tientallen testcases moet doorlopen. Filter op toegewezen persoon om de werklast te verdelen, of op prioriteit om een rooktest eerst op de kritieke paden te richten.
De ClickUp-sjabloon voor testbeheer biedt je een gecentraliseerde manier om de volledige werkstroom voor meerdere functiegebieden, testscenario’s en randgevallen op één plek te beheren. Gebruik deze sjabloon om gebruikersfeedback bij te houden, testschema’s te beheren, de voortgang van je tests te volgen en de resultaten (geslaagd/mislukt) te evalueren zonder tussen verschillende tools te hoeven schakelen.
Beheer je testwerkstroom effectief
Een testcase voldoet aan de eisen zodra twee mensen deze onafhankelijk van elkaar kunnen uitvoeren en tot dezelfde uitkomst komen (geslaagd of mislukt). Alles in deze handleiding (één actie per stap, expliciete voorwaarden, verwachte resultaten zonder ruimte voor interpretatie) is afgestemd op die ene norm. Als je al Sprints plant in ClickUp, kun je met de hierboven beschreven installatie testcases schrijven, uitvoeren en bijhouden, samen met de bugs die ze aan het licht brengen, zonder dat je daarvoor een extra tool hoeft toe te voegen.
Meld je gratis aan bij ClickUp
Veelgestelde vragen over testcases
Hoeveel testcases moet een vereiste hebben?
Voor één vereiste kan één testcase nodig zijn, of wel tien, afhankelijk van het aantal scenario’s, randgevallen en invoervariaties dat ermee gemoeid is. Het idee is om alle realistische paden te bestrijken en zo voldoende dekking te bieden zonder redundantie.
Wat is het verschil tussen testcases en testscripts?
Een testcase beschrijft wat er getest moet worden en welk resultaat verwacht mag worden, en is bedoeld voor handmatige uitvoering. Een testscript daarentegen is de geautomatiseerde versie: code die diezelfde stappen programmatisch uitvoert.
Hoe gedetailleerd moeten teststappen zijn?
Verdeel de test in logische, opeenvolgende stappen die gemakkelijk te volgen zijn zonder voorafgaande context. Bundel niet meerdere acties en maak de test niet onnodig complex.
Een testscenario geeft in één regel aan wat er getest moet worden (“Controleer het resetten van het wachtwoord”); een testcase specificeert hoe, met voorwaarden, stappen, testgegevens en verwachte resultaten. Eén scenario levert doorgaans 3 tot 10 testcases op die het normale verloop, ongeldige invoer en randvoorwaarden omvatten. Scenario’s komen eerst en sturen de planning van de dekking; testcases komen daarna en sturen de uitvoering.
Een positieve testcase maakt gebruik van geldige invoer en verwacht succes: met het juiste e-mailadres en wachtwoord wordt de gebruiker aangemeld. Een negatieve testcase maakt gebruik van ongeldige of onverwachte invoer en verwacht dat het systeem op een correcte manier faalt: bij een verkeerd wachtwoord wordt ‘Ongeldig wachtwoord’ weergegeven zonder dat er een sessie wordt aangemaakt. In geavanceerde testsuites is de verhouding tussen positieve en negatieve testcases ongeveer 1:3 tot 1:5, omdat de meeste productiefouten zich voordoen in foutpaden, niet in succespaden.
Een testplan definieert de omvang, aanpak, middelen en planning voor het gehele testtraject. Een testsuite is een verzameling testcases die zijn gegroepeerd voor één enkele testrun, zoals ‘regressiesuite voor release 2.1’. Een testcase is de basisbouwsteen binnen beide: één gedocumenteerde controle met één uitkomst (geslaagd/mislukt). Het plan bepaalt de strategie, de suite bepaalt de omvang en de testcase bepaalt het oordeel.