De meeste testcases mislukken nog 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 inhoudt. Het gevolg: bugs glippen erdoorheen, testruns kunnen niet worden gereproduceerd en kwaliteitsborging 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 nauwgezetheid 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 testcases in de loop van de tijd kunt verbeteren.
TL;DR
Een testcase definieert de exacte stappen, invoergegevens en verwachte uitkomsten 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 de uitkomst kan worden gecontroleerd. Deze gids behandelt het zevenstappenproces voor het schrijven van testcases, drie uitgewerkte voorbeelden en hoe je een testsuite betrouwbaar houdt 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 controleren 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 met elke stap verder kan gaan
- Voer gegevens in met voorbeeldwaarden om verschillende uitkomsten te testen en zowel succesvolle als mislukte scenario's te controleren
Handmatige versus automatiserde 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 onderhoud 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 de gegevens handmatig moeten invoeren en de resultaten moeten controleren | Kan honderden testcases tegelijkertijd uitvoeren |
| Herhaalbaarheid | Gevoelig voor menselijke fouten en inconsistente interpretatie van stappen | Zeer goed herhaalbaar en consistent wanneer testscripts goed worden onderhouden |
| CI/CD-integratie | Moeilijk te integreren in snel veranderende leveringspijplijnen vanwege menselijke knelpunten | Kan direct in CI/CD-pijplijnen worden geïntegreerd om bij elke build tests uit te voeren |
| Onderhoud | Vereist handmatige updates van documenten telkens 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 daarbij 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’, dan 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.
U zet impliciete kennis om in een herbruikbaar hulpmiddel. In de meeste teams heeft de senior QA-engineer een onzichtbare kaart in zijn hoofd van elke randgeval, elke workaround, elk “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 TC_LOGIN_005 oppakken en de werkstroom ‘accountvergrendeling na vijf pogingen’ al op de eerste dag testen, zonder aan iemand te hoeven vragen wat de drempel is of hoe de timer wordt gereset.
Je isoleert fouten tot exacte stappen, niet tot algemene gebieden. Wanneer een testcase “ga 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 afzonderlijke stap is met een eigen verwacht resultaat, valt de fout te herleiden tot stap 4: “Klik op ‘Resetlink verzenden’ → verwacht succesbericht, kreeg 500-fout. ” Die precisie verkort de debugging-tijd drastisch, omdat de ontwikkelaar precies weet welke interactie de fout heeft triggerd, en niet alleen in welk functiegebied hij moet zoeken.
U ziet wat er gedekt is en wat een blinde vlek is. Zonder gestructureerde testcases is testdekking giswerk. Met gestructureerde testcases kunt u elk scenario in kaart brengen en hiaten direct opsporen. Als je functie voor het opnieuw instellen 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’ in ‘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 geeft de context, de uitvoeringsstappen en het verwachte systeemgedrag weer, 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
- Vereisten
- Uitvoeringsstappen
- Verwachte resultaten
- Daadwerkelijke resultaten ter vergelijking
Voor het voorbeeld van de inlogfunctie op de website dat we hierboven hebben gedeeld, moet uw 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 bevat een korte samenvatting, zodat iedereen die de testcase leest onmiddellijk het doel ervan begrijpt.
Voorbeeld: Controleer of een geregistreerde gebruiker zich met geldige inloggegevens succesvol kan aanmelden bij 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 gebruikeraccount moet actief zijn en mag niet geblokkeerd 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 herhalen.
- De gebruiker navigeert 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.
Daadwerkelijke 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.
Voorbeeld van een observatie:
- U hebt geldige inloggegevens ingevoerd, maar kreeg de foutmelding “Ongeldig wachtwoord”
Laten we nu je vaardigheden in 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. Het meest voorkomende gebruik is het genereren van testcases (69,6%), niet strategisch werk zoals risico-identificatie (19,9%).
Hoe schrijf je testcases (stapsgewijze werkwijze)
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 context toe, laat het beoordelen, voer het vervolgens uit en registreer de resultaten.
Stap 1: Analyseer de vereisten
Voordat u de testcase schrijft, moet u begrijpen wat de functie nog moet doen. Hiervoor bekijkt u de beschikbare documenten – PRD's (productvereistendocumenten), user stories, functiespecificaties en ontwerpdocumenten – en brengt u alle functionaliteiten in kaart die moeten worden getest.
Voorbeeld: Je ontwikkelt een functie waarmee gebruikers hun wachtwoord via e-mail kunnen resetten. Om hiervoor een testcase op te stellen, moet je het volgende begrijpen:
- Welk probleem lost de functie op, d.w.z., kan een gebruiker weer toegang krijgen tot zijn account als hij zijn wachtwoord is vergeten?
- Welke handelingen kan de gebruiker uitvoeren, d.w.z. een resetlink aanvragen, deze via e-mail ontvangen en een nieuw wachtwoord instellen?
- Wat zou er moeten gebeuren wanneer die acties worden uitgevoerd, d.w.z., stuurt het systeem een resetlink en stelt het de gebruiker in staat om zijn of haar wachtwoord succesvol te wijzigen?
- Zijn er beperkingen, d.w.z. verloopt de link na een bepaalde tijd of wordt deze ongeldig na één keer gebruik?
- Zijn er validaties of regels, d.w.z. moet het nieuwe wachtwoord aan specifieke eisen 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: Controleren of een geregistreerde gebruiker zijn of haar wachtwoord met succes via e-mail kan resetten.
Stap 2: Bepaal verschillende testscenario’s
Maak vervolgens een lijst van de testscenario’s die u 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 vertaald naar één of meer testcases die specifieke invoergegevens en voorwaarden omvatten. Door de functie op deze manier op te splitsen, zorg je ervoor dat je testdekking hebt voor zowel het verwachte gedrag als de randgevallen waar echte gebruikers onvermijdelijk mee te maken zullen krijgen.
Stap 3: Plan de test en bepaal de structuur van de testcases
Voor herhaalde regressietests hebt u een structuur nodig waarmee u uw testcase en de resultaten ervan op een consistente manier kunt documenteren. Een goed gedefinieerd sjabloon voor testcases zorgt voor die consistentie en maakt hergebruik mogelijk, zonder dat u elke keer opnieuw hoeft te beginnen.
Plan uw testuitvoering 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 zal de test worden uitgevoerd?
- Welke tools of testframeworks zullen worden 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 met alle voorwaarden die moeten gelden vóór stap 1, en zorg ervoor dat de tester ze allemaal 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 bevat een limiet aan tekens dat lager is dan het minimum
- Grenswaarde: wachtwoord dat precies de limiet voor het aantal tekens van het minimum tot en met 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 uw e-mailadres in het veld 'E-mail' in | E-mail is geaccepteerd zonder validatiefout |
| Klik op ‘Resetlink verzenden’ | Er verschijnt een succesmelding: “Resetlink verzonden naar test@example.com” |
| Open de resetlink in 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 succesbericht 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 wanneer de gebruiker een ongeldig e-mailadres invoert of het wachtwoord niet voldoet aan de vooraf vastgestelde criteria.
Bonus: Zo kunt u de automatisering van de documentatie voor al uw 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 onduidelijkheden 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
- Systeemlogs of configuratiebestanden om backend-problemen te helpen diagnosticeren wanneer een test mislukt
- Requirements-documenten die de testcase in kaart brengen bij de gebruiker 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 waarin de specifieke softwareversie, de vereiste hardware, het besturingssysteem en eventuele vereiste machtigingen voor veiligheid worden beschreven
- 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 een senior QA-leider voordat u deze uitvoert. Controleer tijdens de beoordeling of:
- De testcase is uitgebreid en omvat alle mogelijke scenario’s die zijn afgeleid van 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 werkelijke resultaat naast elk verwachte resultaat. Markeer een test bij elke stap als geslaagd of mislukt. Meld bij 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 opmerkingen voor verdere beoordeling.
Voorbeelden van het schrijven van testcases
Deze drie voorbeelden laten zien hoe dezelfde testcasestructuur kan worden aangepast aan verschillende soorten softwaretesten. 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 faalmodi verschillen naargelang wat u controleert.
Voorbeeld 1: Afrekenwerkstroom bij e-commerce (gebruikersinterface, meerstapswerkstroom)
Een QA-team bij een online winkel test de afrekenprocedure vóór een feestdaguitverkoop. De werkstroom omvat meerdere pagina’s: winkelmandje → verzending → betaling → bevestiging. De belangrijkste uitdaging hierbij is de statusafhankelijkheid: elke stap is afhankelijk van de correcte voltooiing van de vorige stap, en de testgegevens (inhoud van het winkelmandje, 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 gebruikeraccount met ten minste één opgeslagen kredietkaart en één opgeslagen verzendadres
- Er is ten minste één item op voorraad en dit is 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 geeft het juiste item, de juiste hoeveelheid en het juiste subtotaal weer | Zoals verwacht | Slaag |
| Klik op ‘Doorgaan naar afrekenen’ | De verzendpagina wordt geladen met het opgeslagen adres vooraf geselecteerd | Zoals verwacht | Slaag |
| Selecteer ‘Standaardverzending’ en klik op ‘Doorgaan’ | De betaalpagina wordt geladen en toont het totaalbedrag van de bestelling inclusief verzendkosten | Zoals verwacht | Slaag |
| 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 meer dan 3 seconden nodig heeft om te reageren.
Voorbeeld 2: REST API-eindpunt (geen gebruikersinterface, validatie van invoer/uitvoer)
Een backend-engineer test het API-eindpunt ‘Create User’ 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 gegevenspersistentie. 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 het juiste antwoord 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 | Daadwerkelijk resultaat | Geslaagd/Niet geslaagd |
| Stuur een POST-verzoek naar /api/v1/gebruikers met de volgende geldige payload: { "naam": "Test Gebruiker", "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 | Slaag |
| Verzend hetzelfde POST-verzoek nogmaals met hetzelfde e-mailadres | De respons retourneert 409 Conflict met de melding: “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-foutmelding met de validatiefout: “E-mailadres is verplicht” | 400 werd geretourneerd zoals verwacht | Slaag |
| Voer een GET-query uit naar /api/v1/users/{id} met de ID uit stap 1 | De respons retourneert 200 OK, waarbij de gegevens van de gebruiker overeenkomen met de oorspronkelijke payload | Zoals verwacht | Slaag |
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 ernst: Hoog.
Voorbeeld 3: Op rollen gebaseerde toegangscontrole (veiligheid, grenzen van de toestemming)
Een beveiligingsteam test voorafgaand aan een compliance-audit of de applicatie acties op basis van gebruikersrollen correct beperkt. De bijzondere uitdaging 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 blok, 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 | Daadwerkelijk resultaat | Geslaagd/Niet geslaagd |
| Ga naar de pagina ‘Projecten’ | De gebruiker ziet de projectlijst in de alleen-lezenmodus; de knop ‘Project aanmaken’ is verborgen of uitgeschakeld | De knop is zichtbaar maar grijs weergegeven | Slaag |
| Probeer op ‘Project aanmaken’ te klikken | Het systeem verhindert de actie; het formulier voor een nieuw project wordt niet geladen | Er is geen formulier geladen; de tooltip geeft aan: “U hebt geen toestemming” | Slaag |
| 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’ kon worden bewerkt; 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 | Slaag |
Samenvatting van de resultaten: De toestemmingen voor het aanmaken en verwijderen zijn correct beperkt voor kijkers, maar de toestemmingen voor bewerking worden niet afgedwongen op veldniveau. Een kijker kan projecttitels wijzigen ondanks dat hij alleen-lezen toegang heeft. Defect geregistreerd met ernst: 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.
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 testbeheer, maar dankzij de flexibele taakstructuur kunnen teams testcase-werkstroomen opzetten met behulp van aangepaste statussen, velden en taaksoorten, 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 Sprint-reviews
Limieten van ClickUp
- Geen ingebouwde testuitvoeringsengine
- 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 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 inzicht in wie waarvoor verantwoordelijk is en hoe de projecten er op elk moment voor staan.
Wat ik het leukste vind aan ClickUp is dat alles op één plek samenkomt. Taken, tijdlijnen, aantekeningen en updates staan 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-manager die wil dat een mislukte test met één klik wordt omgezet in een bugticket voor de 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 niet een tool waarbij een medewerker de status handmatig bijwerkt.
TestRail
TestRail is een gespecialiseerd testbeheerplatform dat is ontwikkeld voor QA-teams die behoefte hebben aan gestructureerde controle over hun gehele testproces. Het platform verzorgt de volledige cyclus van het schrijven, uitvoeren en doen 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 testrondes 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 zijn geen ingebouwde functies voor het bijhouden van vereisten of problemen – teams moeten vertrouwen op externe tools zoals Jira, wat de traceerbaarheid kan versnipperen
- Naarmate testopslagplaatsen uitgroeien tot duizenden items, wordt het steeds moeilijker om je weg te vinden in de op mappen gebaseerde organisatie.
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 overzichtelijke 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 beter 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 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 beter traceerbaar 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 medewerkers dat per release formele testcyclussen uitvoert, waarbij een manager vanuit een dashboard – en niet vanuit een spreadsheet – moet kunnen aangeven “welk percentage van Release 2.0 is uitgevoerd en geslaagd”.
Sla dit over als: uw testsuite uit minder dan een paar honderd testcases bestaat of als uw testers tevens ontwikkelaars zijn. Op die schaal zijn de kosten per gebruiker en de aparte inloggegevens alleen maar een investering in rapportages die u toch niet zult bekijken.
Zephyr
Zephyr is de testbeheerplug-in van SmartBear voor Jira, ontwikkeld om testcases rechtstreeks vanuit de Jira-interface te beheren. Het ondersteunt zowel handmatig als met automatisering, met krachtige functies voor rapportage en traceerbaarheid voor agile- en enterprise-teams.
Belangrijkste functies van Zephyr
- Native Jira-integratie: maak, koppel en voer testcases rechtstreeks vanuit Jira-problemen uit
- 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 fouten
- BDD-ondersteuning die Gherkin-syntaxis gebruikt voor gedraggestuurde werkstroomen
- 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
- Essentieel: vanaf $ 5,99 per gebruiker per maand (11-50 gebruikers)
- Standaard: vanaf $ 6,81 per gebruiker per maand (11-50 gebruikers)
- Geavanceerd: vanaf $ 8,73 per gebruiker per maand (11-50 gebruikers)
Beoordelingen en recensies van Zephyr
- G2: 4,1/5 (meer dan 80 beoordelingen)
- Capterra: Te weinig 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 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.
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 audits ondergaan (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 gevonden, 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 betaalt voor 190 Zephyr-licenties die niemand opent; een op zichzelf staande tool die per tester wordt geprijsd, kost minder.
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 specifieke 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, issue-types 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) vereist, waarvoor naast het Jira-abonnement een eigen vergoeding per gebruiker geldt
- Een steilere leercurve voor niet-technische gebruikers, met opstartkosten die bij grotere teams flink kunnen oplopen
Prijzen van Jira
- Free
- Standaard: $7,91 per gebruiker per maand
- Premium: $14,54 per gebruiker per maand
- Enterprise: Aangepaste prijzen
Jira-beoordelingen en recensies
- 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 speciaal testbeheer. Door eerst een paar testcycli uit te voeren met aangepaste Jira-issue-types, wordt duidelijk of de omvang een plug-in rechtvaardigt.
Sla dit over als: Je weet al dat je testbeheer nodig hebt. Door direct voor een plug-in of een zelfstandige tool te kiezen, voorkom 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 moet 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 upgrade 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, winkelmandje 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 fouten. Dit helpt u om uw testinspanningen te focussen en slimmere beslissingen te 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 invoer die het meest waarschijnlijk tot fouten leidt, en wordt verwijderd zodra deze geen betrouwbare uitkomst meer oplevert. Deze zes werkwijzen maken het verschil tussen testsuiten die jarenlang fouten opsporen en testsuiten die al na de tweede Sprint worden genegeerd.
Schrijf onafhankelijke, atomaire tests
Een testcase moet zijn eigen toestand opbouwen en mag nooit afhankelijk zijn van een andere case die eerst moet zijn 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 de echte 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 gemakkelijk te onthouden 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 uw 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 bewerkingen worden uitgevoerd in de staging-, QA- en pre-productieomgeving, en het invoeren van 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 willekeurig zonder dat er sprake is van een echte productfout, en elke onbetrouwbare test leert het team om rode resultaten te 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. Koppel dit aan het defect escape rate (fouten die in de productie worden gevonden en die een testcase had moeten opsporen) om te zien waar de dekking onvoldoende is, en niet alleen waar er ruis is.
Automatiseer de tests die u het vaakst uitvoert
Regressie-, smoke- en hoogfrequente functionele testcases zijn de meest geschikte kandidaten voor automatisering, omdat ze bij elke build worden uitgevoerd en zelden veranderen. Zet deze om in scripts in uw CI/CD-pijplijn en gebruik AI-ondersteunde tools met zelfherstellende locators op plaatsen waar UI-elementen vaak verschuiven. Zo komen 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 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 ruimte 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 testcase-ID, randvoorwaarden, testgegevens, prioriteitsniveau en omgeving.
Schrijf teststappen rechtstreeks in de Taak. Gebruik de Taakbeschrijving om opeenvolgende uitvoeringsstappen en verwachte resultaten te documenteren. Checklists zijn geschikt voor stapsgewijze werkstroomen waarbij een tester elke actie moet afvinken, terwijl de beschrijving context biedt, zoals randvoorwaarden en testgegevens.
Volg de uitvoering en resultaten. Maak aangepaste statussen die aansluiten bij je testwerkstroom: Niet gestart → In uitvoering → Geslaagd → Mislukt → Geblokkeerd. Als 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 taak, de gekoppelde specificaties en opmerkingen leest, de oplossing schrijft en een pull-aanvraag opent 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 maken van openstaande bugtaken. Zo beschikken ze over alle context die ze nodig hebben voor sprintreviews, zonder dat ze door afzonderlijke taken hoeven 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 u de resultaten van tientallen testcases moet doorlopen. Filter op toegewezen persoon om de werklast evenwichtig te verdelen, of op prioriteit om een rooktest eerst op de kritieke paden te richten.
De ClickUp-sjabloon voor testbeheer biedt u 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 uw tests te volgen en de resultaten (geslaagd/mislukt) te evalueren, zonder dat u tussen verschillende tools hoeft te schakelen.
Beheer uw testwerkstroom effectief
Een testcase is geslaagd 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 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 enkele vereiste kan één testcase nodig zijn, of tien, afhankelijk van het aantal scenario’s, randgevallen en invoervariaties dat erbij komt kijken. Het idee is om alle realistische paden te dekken en zo voldoende dekking te bieden zonder dat er sprake is van redundantie.
Wat is het verschil tussen testcases en testscripts?
Een testcase beschrijft wat er getest moet worden en welk resultaat verwacht wordt, 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 grensvoorwaarden bestrijken. Scenario's komen eerst en sturen de dekkingsplanning; 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 succesvolle paden.
Een testplan definieert de reikwijdte, 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 kleinste eenheid binnen beide: één gedocumenteerde controle met één uitkomst (geslaagd/mislukt). Het plan bepaalt de strategie, de suite bepaalt de reikwijdte en de case bepaalt het oordeel.