Test het plan: ook documenten kunnen stuk

Laat je AI een plan toetsen zoals een tester software toetst, en je vindt de fouten op papier in plaats van in de uitvoering. Dit is les acht van Read, de laatste van de reeks: een korte, praktische les over testen, van je eerste toets tot tien userstories waarvan er twee elkaar tegenspreken.

Zeg wat je ervan vindt. Dit is les acht van de reeks, en ik hoor graag of je er iets aan hebt gehad. Goed of niet goed, allebei even welkom, en je hoeft niet te wachten tot het einde. Twee zinnen zijn genoeg: geef feedback. Anoniem mag; laat je je e-mailadres achter, dan kunnen we er eventueel over sparren. Je feedback wordt nergens publiek getoond.

Wat je hierna kunt

• Een document toetsen zoals je software toetst: met vaste testvragen in plaats van een algemene indruk.
• Vier soorten fouten vinden: wat ontbreekt, wat niet (meer) klopt, wat elkaar tegenspreekt en wat op meer manieren te lezen is.
• Tegenspraak opsporen tussen userstories, afspraken en eerdere beslissingen, met de vraag erbij die het oplost.
• Een vaste toets bouwen die je bij elk plan, elke offerte en elke set userstories opnieuw draait.

En misschien wel het belangrijkste: je herkent hierna het moment waarop een document "wel goed" lijkt omdat vijf mensen het gelezen hebben, en denkt: dit is nog niet getest.

Waarom niet gewoon vragen of het goed is? Vraag je AI "is dit een goed plan?", dan krijg je meestal een compliment met drie algemene tips. Dat is een mening, geen test. Een test stelt vaste vragen, vergelijkt met een verwachting en levert bevindingen op: waar het zit, wat er mis is, hoe erg het is. Het verschil is dat tussen "ziet er goed uit" en een keuringsrapport.

Wat je nodig hebt

• Een Claude-account. Alles in deze les werkt in de Claude-apps (web en desktop) én in Claude Code. Waar de twee verschillen, staat het erbij.
• Een document waar binnenkort op gebouwd wordt: een projectplan, een offerte, een set userstories, een procesbeschrijving (zoals die uit les 07).
• Als je die hebt: de stukken waartegen je toetst, zoals eerdere beslissingen, het contract of het projectgeheugen uit les 03.
• Een uur. Lezen alleen kan in een kwartier, maar de opzet is dat je meteen meedoet met een document uit je eigen werk.

De denkwijze

Het probleem is niet dat je AI het niet kan. Het probleem is dat niemand het plan test.

Herken je dit? Een plan gaat langs vijf mensen en iedereen keurt het goed. Ieder heeft het eigen deel gelezen, en daarin klopte het. Pas in week zes van de bouw blijkt dat het ene hoofdstuk iets belooft wat het andere uitsluit. Op papier had die fout een doorhaling gekost; nu kost hij een verbouwing.

Software wordt getest voordat hij live gaat, dat vindt iedereen normaal. Documenten gaan meestal ongetest door, terwijl er net zo goed op gebouwd wordt: een offerte wordt een contract, een userstory wordt een functie, een plan wordt een begroting.

De oplossing: toets documenten zoals je software toetst: met vaste testvragen, tegen een referentie, voordat iemand erop bouwt. Daar is een AI goed in. Hij leest het hele document in één keer, legt pagina twee naast pagina veertien, en is bij de laatste userstory net zo scherp als bij de eerste.

Wat een documenttoets precies is

Een documenttoets is een vaste lijst testvragen plus een vast format voor de bevindingen. Je legt hem één keer vast als skill (les 01), en daarna vraag je gewoon "toets dit plan". De AI loopt de vragen langs, vergelijkt met de referentie die je meegeeft en levert een lijst bevindingen op, gesorteerd op ernst.

Het belangrijkste woord is "referentie". Zonder referentie kan de AI alleen toetsen of een document met zichzelf klopt. Mét referentie (de beslissingen uit je projectgeheugen, het contract, de vorige versie) toetst hij ook of het klopt met wat er al is afgesproken. Daar zitten vaak de duurste fouten.

De anatomie: vier toetsen

Wanneer je toetst, en wanneer niet

• Toets wat een basis wordt. Documenten waar anderen op bouwen, tekenen of begroten: plannen, offertes, userstories, procesbeschrijvingen. Daar is een gevonden fout het meeste waard.
• Een kort mailtje: gewoon teruglezen. Voor stukken waar niemand op verder bouwt, is een testrapport meer werk dan het oplevert.
• Toets vroeg, en na elke grote wijziging. Een eerste versie toetsen is goedkoper dan een definitieve, en een wijziging kan een nieuwe tegenspraak veroorzaken.

Het voorbeeld: tien userstories voor een klantportaal

We bouwen nu samen een toets en halen er een echte set userstories doorheen. Pak er zelf een document bij waar binnenkort op gebouwd wordt: een plan, een offerte, een lijst met eisen. De stappen werken voor allemaal; ik gebruik tien userstories als voorbeeld, voor het klantportaal van een installatiebedrijf waar klanten hun onderhoudsafspraak zelf plannen en verzetten. Heb je les 05 gelezen, dan ken je het portaal al.

Stap 1: leg het document en de referentie klaar

Het document: de tien userstories. De referentie: wat er al vaststaat, in dit geval twee beslissingen uit het projectgeheugen. Ze zijn verzonnen, maar dit soort fouten kom ik in echte projecten steeds weer tegen. Lees ze gerust eerst zelf: zie je de tegenspraak al?

# Userstories klantportaal (versie 0.3)

1. Als klant wil ik inloggen met mijn klantnummer en wachtwoord,
   zodat ik maar één account heb.
2. Als klant wil ik mijn geplande onderhoudsafspraak zien, met
   datum, tijdvak en naam van de monteur.
3. Als klant wil ik zelf een onderhoudsafspraak plannen, zodat
   ik niet hoef te bellen.
4. Als klant wil ik mijn afspraak tot 24 uur van tevoren
   kosteloos verzetten, zodat ik flexibel blijf.
5. Als klant wil ik twee dagen voor mijn afspraak een
   herinnering krijgen.
6. Als klant wil ik mijn facturen van de afgelopen twee jaar
   downloaden als pdf.
7. Als klant wil ik mijn telefoonnummer aanpassen, zodat de
   monteur mij kan bereiken.
8. Als klant wil ik dat het portaal snel is.
9. Als planner wil ik dat afspraken 48 uur van tevoren
   vastliggen, zodat de routes van de monteurs kloppen.
10. Als planner wil ik zien welke klanten hun afspraak hebben
    verzet, zodat ik de routes kan bijwerken.

# Referentie: beslissingen uit het projectgeheugen

- 2026-07-10: het portaal toont facturen vanaf 1 januari 2026.
  Oudere facturen staan in het oude systeem en gaan niet mee.
- 2026-08-05: klanten loggen in met hun bestaande klantnummer,
  zodat ze maar één account hebben.

Stap 2: kies je testvragen

Neem de vier toetsen uit de anatomie en maak ze concreet voor dit soort document. Voor userstories wordt dat:

• Volledigheid: heeft elke story een rol, een wens en een doel (het "zodat")? Zijn er acceptatiecriteria? En wat ontbreekt er in de reeks als geheel?
• Geldigheid: klopt elke story met de beslissingen in de referentie?
• Tegenspraak: vergelijk elke story met elke andere, vooral op termijnen, aantallen en rollen.
• Eenduidigheid: welke woorden zijn niet te meten, en dus straks niet te testen?

Voor een offerte of een plan zien de vragen er anders uit; het sjabloon verderop helpt je die op te stellen.

Stap 3: bepaal het opleverformat

Zonder vast format krijg je een lap tekst waarin een tikfout even zwaar lijkt als een tegenstrijdige termijn. Geef de toets daarom een vaste indeling: per bevinding de ernst, de soort toets, de vindplaats, wat er aan de hand is en de vraag die het oplost. Sorteer van blokkerend naar klein.

Die laatste kolom, de vraag, is de belangrijkste. Een tegenspraak oplossen betekent kiezen, en die keuze hoort bij de opdrachtgever. De toets zorgt dat de vraag nú op tafel komt, scherp genoeg om in één overleg te beantwoorden.

Stap 4: het complete bestand

De toets als skill, in de opbouw uit les 01:

---
name: documenttoets
description: Gebruik deze skill bij het toetsen, testen of
  controleren van een plan, offerte, userstories, eisenlijst of
  procesbeschrijving. Ook bij "klopt dit plan?", "spreekt dit
  elkaar tegen?" of "toets dit document".
---

# Documenttoets

Je toetst een document zoals een tester software toetst: met
vaste vragen, tegen een referentie, en je levert bevindingen op.

## Werkwijze
1. Gebruik de referentie die je krijgt: eerdere beslissingen,
   contract of vorige versie. Krijg je er geen, toets dan het
   document op zichzelf en meld dat in de eerste zin.
2. Loop de vier toetsen langs:
   - Volledigheid: wat ontbreekt er? Bij userstories: rol,
     wens, doel ("zodat") en acceptatiecriteria.
   - Geldigheid: klopt elk getal, elke datum en elke
     verwijzing, en klopt alles met de referentie?
   - Tegenspraak: vergelijk elk onderdeel met elk ander
     onderdeel, vooral op termijnen, bedragen, aantallen en
     rollen.
   - Eenduidigheid: markeer woorden die niet te meten zijn,
     zoals snel, gebruiksvriendelijk en zo nodig.
3. Formuleer bij elke bevinding de vraag die hem oplost. De
   keuze laat je aan de opdrachtgever; voorstellen mag.
4. Markeer wat je niet kunt toetsen als "niet getoetst", met
   de reden erbij.

## Opleverformat
Begin met één zin: het aantal bevindingen per ernst.
Daarna per bevinding, gesorteerd van blokkerend naar klein:
- Ernst: blokkerend, belangrijk of klein
- Toets: volledigheid, geldigheid, tegenspraak of eenduidigheid
- Waar: de vindplaats, zo precies mogelijk
- Wat: het probleem in maximaal twee zinnen
- Vraag: de vraag die de opdrachtgever moet beantwoorden

Maximaal tien bevindingen; noem daarna alleen het aantal overige.

Stap 5: installeer de toets

Maak een map met de naam documenttoets en zet het bestand erin als SKILL.md. Daarna, precies zoals in les 01:

• Claude-apps: Instellingen → Vaardigheden (Skills) → skill toevoegen en je map (of een zip ervan) uploaden.
• Claude Code: zet de map in ~/.claude/skills/, dus ~/.claude/skills/documenttoets/SKILL.md. Dan geldt hij in al je projecten.

Dat teken ~ is een afkorting voor je thuismap, zie de begrippenlijst onderaan.

Op Windows

Je thuismap is C:\Users\jouwnaam. Open Verkenner, typ %USERPROFILE% in de adresbalk en druk op Enter. Ga naar de map .claude en daarin skills (bestaan ze nog niet, maak ze dan aan), maak daar een map documenttoets en zet je SKILL.md erin.

Op een Mac

Je thuismap is /Users/jouwnaam, en mappen die met een punt beginnen zijn daar verborgen. De snelste route is via Terminal (Programma's → Hulpprogramma's): plak mkdir -p ~/.claude/skills/documenttoets en druk op Enter. Openen kan daarna met open ~/.claude/skills/documenttoets. Zet daar je SKILL.md in.

Werk je in Claude Code en wil je dat de toets met een eigen, schoon werkgeheugen leest? Maak er dan een subagent van (les 02), met dezelfde werkwijze en hetzelfde opleverformat. De maker en de toetser horen elk hun eigen werkgeheugen te hebben; een toetser die het hele gesprek over het plan heeft meegemaakt, leest wat er bedoeld werd in plaats van wat er staat.

Stap 6: draai de toets, mét en zónder

Open een nieuw gesprek, plak de userstories en de referentie erin en vraag:

"Toets deze userstories. De referentie zijn de beslissingen eronder."

Het verschil dat je mag verwachten:

Zonder toets: "Dit is een overzichtelijke set userstories die de belangrijkste behoeften van klant en planner goed dekt! Enkele suggesties: overweeg acceptatiecriteria toe te voegen, en denk eventueel na over toegankelijkheid…"

Met toets: "6 bevindingen: 2 blokkerend, 2 belangrijk, 2 klein." Met als eerste bevinding de tegenspraak tussen story 4 en story 9, en de vraag die hem oplost.

De eerste bevindingen uit het rapport:

6 bevindingen: 2 blokkerend, 2 belangrijk, 2 klein.

1. Ernst: blokkerend · Toets: tegenspraak
   Waar: story 4 en story 9 (raakt ook story 5)
   Wat: klanten mogen verzetten tot 24 uur van tevoren, maar
   voor de planner liggen afspraken 48 uur van tevoren vast.
   De herinnering uit story 5 komt precies op het moment dat
   verzetten volgens story 9 niet meer kan.
   Vraag: mag een klant tussen 48 en 24 uur van tevoren nog
   verzetten? Zo ja, hoe krijgt de planner dat op tijd door;
   zo nee, wordt de termijn in story 4 dan 48 uur?

2. Ernst: blokkerend · Toets: geldigheid (referentie)
   Waar: story 6
   Wat: de story belooft facturen van twee jaar terug, maar
   volgens de beslissing van 10 juli staan alleen facturen
   vanaf 1 januari 2026 in het nieuwe systeem.
   Vraag: wordt story 6 "facturen vanaf 1 januari 2026", of
   komt er alsnog een koppeling met het oude systeem?

3. Ernst: belangrijk · Toets: volledigheid
   Waar: alle stories
   Wat: geen enkele story heeft acceptatiecriteria, dus
   niemand kan straks aantonen dat een story af is.
   Vraag: wie schrijft per story twee of drie criteria, en
   wanneer?

4. Ernst: belangrijk · Toets: volledigheid
   Waar: story 3 en 4
   Wat: wat er gebeurt als er geen tijdvak vrij is, of als
   een klant wil annuleren in plaats van verzetten, staat
   nergens.
   Vraag: horen annuleren en "geen plek vrij" in deze versie,
   of in een volgende?

Daarna volgen nog twee kleine bevindingen: "snel" in story 8 is niet te meten, en bij story 2, 5 en 6 ontbreekt het doel. Let ook op wat de toets níét doet: hij kiest niet tussen 24 en 48 uur. Dat is een afweging tussen klantgemak en de planning van de monteurs, en die hoort bij de opdrachtgever. De toets zorgt dat die vraag nu op tafel komt, in plaats van in week zes van de bouw.

Stap 7: los op en toets opnieuw

Beantwoord de vragen, pas het document aan en draai de toets nog een keer: de hertest. Dat is geen overbodige luxe. Stel dat de opdrachtgever kiest voor 48 uur in story 4. Dan komt de herinnering uit story 5 (twee dagen vooraf) precies op het moment dat verzetten niet meer kan, en is die herinnering voor verzetten nutteloos geworden. Een oplossing kan dus een nieuwe tegenspraak maken; de hertest vindt hem.

Scherp daarna de toets zelf aan, net als elke skill. Vind je bij het nalezen nog iets wat de toets miste? Dat wordt een nieuwe testvraag. En test af en toe de tester: zet bewust één fout in een document (een termijn die niet klopt, een optelling die er net naast zit) en kijk of de toets hem vindt. Vindt hij hem niet, dan weet je waar je de testvragen moet aanscherpen.

Zelf doen: sjabloon en drie starters

Hetzelfde recept werkt voor elk soort document. Hier is het lege sjabloon, plus de drie toetsen waarmee ik iedereen laat beginnen.

---
name: [kleine-letters-met-streepjes]
description: Gebruik deze skill bij het toetsen van [documenttype],
  en bij [de woorden die jij typt als je om zo'n controle vraagt].
---

# [Naam van de toets]

## Referentie
[Waartegen toets je: beslissingen, contract, tarievenlijst,
vorige versie? Laat de referentie per keer meegeven.]

## Testvragen
- Volledigheid: [wat hoort er in dit type document altijd in?]
- Geldigheid: [welke getallen, datums en verwijzingen check je?]
- Tegenspraak: [waar spreken delen elkaar in jouw vak het
  vaakst tegen?]
- Eenduidigheid: [welke vage woorden komen in jouw vak vaak
  voor?]

## Opleverformat
[Per bevinding: ernst, toets, waar, wat, vraag. Gesorteerd op
ernst, maximaal tien.]

Starter 1: de offertetoets

Wanneer: voor elke offerte die de deur uit gaat. Referentie: je aantekeningen van het intakegesprek en je actuele tarievenlijst. Geef die per keer mee in plaats van ze in de skill te zetten; tarieven horen niet in een skillbestand (les 01). Testvragen: tellen de bedragen op, klopt de btw, staat de geldigheidsduur erin, en komt alles wat de klant in de intake vroeg in de offerte terug?

Starter 2: het plan tegen het geheugen

Wanneer: een nieuw plan of een wijziging in een lopend project. Referentie: de beslissingen uit je projectgeheugen (les 03). Testvraag: gaat dit plan in tegen een eerdere beslissing? Zo ja: is dat bewust, en moet de beslissing dan worden bijgewerkt, met nieuwe datum en reden? Zo blijft het geheugen kloppen met wat er werkelijk gebeurt.

Starter 3: de doe-proef

Wanneer: een stappenplan, handleiding of procesbeschrijving, zoals het teamproces uit les 07. Toets: laat de AI de stappen doorlopen alsof hij ze voor het eerst uitvoert, en laat hem noteren waar hij vastloopt: een stap die voorkennis veronderstelt, een bestand dat nergens genoemd wordt, een beslissing zonder eigenaar. Zo test je een proces voordat de nieuwe collega het moet doen.

Acht lessen, één geheel

Met deze les is de reeks compleet. Elke les voegt één gereedschap toe, en ze werken samen:

In het klantportaal komt alles samen. De ontwerpafspraken zorgen dat elk scherm bij de rest past (les 05), het projectgeheugen bewaart de beslissingen (les 03), en de documenttoets legt elke nieuwe versie van de userstories naast die beslissingen, voordat er één regel code geschreven wordt.

Valkuilen en gouden regels

Vijf dingen die ik bij anderen zie misgaan, plus de twee regels die je nooit loslaat.

1. Vragen of het goed is. "Is dit een goed plan?" levert een compliment op, geen test. Stel vaste testvragen en vraag om bevindingen in een vast format; dan krijg je een keuringsrapport in plaats van een mening.
2. Toetsen zonder referentie. Zonder de afspraken ernaast kan de AI alleen zien of het document met zichzelf klopt. De duurste fouten zitten juist tussen het document en wat er al besloten is. Geef de beslissingen, het contract of de vorige versie mee.
3. Veertig bevindingen, één blokkade. Een lijst waarin een tikfout even zwaar weegt als een tegenstrijdige termijn, leest niemand uit. Sorteer op ernst en begrens het aantal; het opleverformat doet dat werk voor je.
4. "Geen bevindingen" lezen als "geen fouten". Een toets vindt veel, maar niet alles. Test de tester af en toe met een bewust geplante fout, en lees zelf mee bij alles waar geld, veiligheid of een handtekening aan hangt.
5. Eén keer toetsen en daarna nooit meer. Documenten veranderen, en elke wijziging kan een nieuwe tegenspraak maken. Toets opnieuw na elke grote wijziging, en neem de toets zelf mee in het vaste onderhoudsmoment (eerste maandag van de maand is populair): welke testvraag mis je, en welke vindt nooit iets?

⚠️ Twee gouden regels. Eén: de toets stelt de vraag, de opdrachtgever geeft het antwoord. Een tegenspraak oplossen is kiezen, en kiezen hoort bij mensen: klantgemak of planbaarheid, twee jaar facturen of een eenvoudiger systeem. Laat de AI de keuzes zichtbaar maken en voorstellen doen, en laat de beslissing bij de opdrachtgever, vastgelegd met datum en reden (les 03). Twee: toets vertrouwelijke stukken alleen in een omgeving die daarvoor bedoeld is. Offertes, contracten en plannen bevatten namen, bedragen en afspraken. Gebruik het zakelijke account dat je organisatie daarvoor heeft goedgekeurd, controleer in de privacy-instellingen of je gesprekken gebruikt mogen worden om modellen te trainen, en haal persoonsgegevens eruit als ze voor de toets niet nodig zijn.

Je volgende stap

Testen is de achtste en laatste stap van deze reeks. Op het AI-groeipad hoort het bij de sprong van fase 3 naar fase 4, waar per toepassing is bekeken wat er mis kan gaan. Een team dat zijn plannen toetst voordat erop gebouwd wordt, doet precies dat, en begint bij de goedkoopste plek: het papier.

Doe deze week één ding: pak het eerstvolgende document waar iemand op gaat bouwen, en haal het door de toets, mét referentie. Tel wat je vindt voordat het de deur uit gaat.

Dit was de laatste les van Read. Alle acht op een rij, om terug te lezen of door te sturen naar een collega, vind je in het overzicht. Daar kun je je ook aanmelden voor een bericht zodra er nieuwe lessen of de interactieve variant klaarstaan.

Benieuwd waar in jouw processen een toets het meeste oplevert? Een uurtje praten of een korte quickscan van je processen maakt dat meestal snel helder. Plan een kennismaking: een half uur, eerlijke aanbeveling, ook als die "gewoon zelf beginnen" is.

Wat vond je ervan?

Je bent er doorheen, en daarmee door de hele reeks. Vertel me wat werkte, wat je miste en wat onduidelijk bleef. Twee zinnen zijn genoeg, en elke reactie maakt de volgende versie van Read beter: geef feedback. Anoniem mag; laat je je e-mailadres achter, dan kunnen we er eventueel over sparren. Je feedback wordt nergens publiek getoond.