Auteur: Marcel Smit

  • De AI-Tester: Hoe je Claude inzet als Testpartner

    Als software tester anno 2026 is de vraag niet meer of je AI gebruikt, maar hoe je het aanstuurt. Een van de krachtigste manieren om Claude (of vergelijkbare LLM’s) in te zetten, is door het definiëren van specifieke Skills. In plaats van ad-hoc vragen te stellen, leer je de AI een rol aan met een specifiek doel, een set regels en een verwacht resultaat.

    Hieronder duiken we in twee cruciale toepassingen voor de moderne tester.

    1. Skill: De Testbasis Reviewer

    Voordat er ook maar één regel code wordt geschreven, valt of staat de kwaliteit bij de testbasis (user stories, requirements of functioneel ontwerpen). Gaps in de specificaties leiden onherroepelijk tot bugs in productie.

    De Uitdaging: Handmatige reviews van documentatie zijn tijdrovend en menselijke fouten (zoals het over het hoofd zien van een edge-case) liggen op de loer.

    Hoe je Claude toepast: Je kunt Claude een “Skill” aanleren waarbij hij fungeert als een kritische Business Analyst en QA Lead in één.

    De Prompt-opzet (De Skill): *”Je bent een expert in Requirement Engineering. Jouw taak is om de aangeleverde testbasis te toetsen op drie fronten:

    1. Gaps: Wat ontbreekt er (bijv. foutafhandeling, performance eisen)?
    2. Testbaarheid: Zijn de criteria meetbaar en objectief?
    3. Consistentie: Tegenstrijdigheden binnen het document.”*
    4. Via MCP verbinding maken met bijvoorbeeld Jira en Git om de documentatie uit te lezen.

    Het Resultaat: Binnen seconden identificeert Claude dat een user story over “snelle laadtijden” niet testbaar is omdat “snel” niet gedefinieerd is in milliseconden. Het resultaat is een kortere feedbackloop met de Product Owner en een hogere kwaliteit aan de poort (Shift Left).

    2. Skill: De Unit Test Architect

    Developers schrijven de unit tests, maar de tester bewaakt vaak de kwaliteit en de dekking (coverage). Soms is de coverage hoog (bijv. 80%), maar worden de kritieke paden alsnog gemist.

    De Uitdaging: Het analyseren van complexe code om te bepalen of de unit tests wel de juiste logica afdekken, is complex en vraagt veel tijd van zowel dev als test.

    Hoe je Claude toepast: Gebruik Claude om code-architectuur te begrijpen en ontbrekende scenario’s voor te stellen.

    • Boundary Value Analysis: Claude kan razendsnel zien waar variabelen worden gecheckt en suggesties doen voor grenswaarden die de huidige unit tests missen.
    • Path Coverage: Door de code te uploaden, kan Claude de “cyclomatic complexity” bepalen en aangeven welke logische paden nog niet zijn geraakt door de bestaande testsuite.

    Praktijkvoorbeeld: Je voert een Java-methode in die kortingen berekent. Claude ziet dat er wel wordt getest op positieve bedragen, maar dat de ‘null-pointer’ of een negatief bedrag in de unit tests ontbreekt. Hij genereert direct de benodigde JUnit of Pytest code om dit gat te dichten.

    Waarom Claude voor Testers?

    Waarom specifiek Claude? In vergelijking met andere modellen blinkt Claude uit in:

    • Context Window: Je kunt volledige documentatiepakketten of grote codebases uploaden zonder dat de AI de draad kwijtraakt.
    • Nuance: Claude is minder “blij” en vaker “analytisch”, wat perfect aansluit bij de kritische blik van een tester.
    • Code-begrip: De logica in programmeren wordt door Claude vaak nauwkeuriger begrepen, wat essentieel is voor technische testtaken.

    Conclusie: Van Uitvoerder naar Regisseur

    Door Claude te trainen in specifieke skills, verander je jouw rol als tester. Je bent niet meer degene die alleen maar testgevallen klikt of scripts tikt; je wordt de regisseur van kwaliteit. Je gebruikt AI om de saaie, repetitieve analyses te doen, zodat jij je kunt focussen op de complexe integratievraagstukken en de gebruikerservaring.

    Begin klein: Neem je volgende user story, geef Claude de rol van ‘Kritische Tester’ en vraag om 5 scenario’s waar nog niet aan gedacht is. Je zult versteld staan van de diepgang.

  • Het Testing Manifest

    Als QA engineer werk ik dagelijks met teams die software bouwen in een Agile omgeving. Maar wat betekent het eigenlijk om “Agile”
    te testen? Het Agile Testing Manifesto geeft daar een helder antwoord op — en het verandert fundamenteel hoe we naar kwaliteit
    kijken.

    Wat is het Agile Testing Manifesto?

    Het Agile Testing Manifesto is geïnspireerd door het originele Agile Manifesto en vertaalt dezelfde principes naar de wereld van
    software testing. De kern bestaat uit vijf waarden:

    1. Testing throughout over testing at the end
      Testen is geen fase die begint als de ontwikkelaar “klaar” is. In een Agile team test je continu: tijdens refinement, tijdens
      ontwikkeling, en na oplevering. Hoe eerder je een probleem vindt, hoe goedkoper het is om het op te lossen. In de praktijk betekent dit dat ik als QA engineer al betrokken ben bij user story refinement. Ik stel vragen, identificeer
      risico’s en denk mee over acceptatiecriteria — nog voordat er één regel code geschreven is.
    2. Preventing bugs over finding bugs
      Dit is misschien wel de belangrijkste verschuiving. Traditioneel was een tester iemand die bugs vond. In Agile draait het om het
      voorkómen van bugs. Door goede teststrategieën, duidelijke acceptatiecriteria en vroege feedback loops zorgen we ervoor dat bugs
      niet eens ontstaan. Test automation speelt hier een cruciale rol. Met geautomatiseerde regressietests in je CI/CD pipeline vang je fouten op voordat ze
      de gebruiker bereiken.
    3. Testing understanding over checking functionality
      Testen gaat niet alleen over “werkt de knop?”. Het gaat over begrijpen wat de gebruiker nodig heeft en of de software daaraan
      voldoet. Dit vereist een dieper begrip van het domein, de gebruiker en de business value. Als ik een nieuwe feature test, vraag ik mezelf altijd af: lost dit het probleem van de gebruiker op? Niet alleen: voldoet het aan
      de specificatie?
    4. Building the best system over breaking the system
      De oude mentaliteit van “ik ga het systeem breken” maakt plaats voor een constructieve aanpak. Als tester draag je bij aan het
      bouwen van het beste mogelijke systeem. Je bent geen poortwachter, maar een teamspeler die kwaliteit toevoegt. Dit betekent ook dat je meedenkt over architectuur, performance en gebruikerservaring — niet alleen over functionele correctheid.
    5. Team responsibility for quality over tester responsibility
      Kwaliteit is niet de verantwoordelijkheid van de tester alleen. Het hele team is verantwoordelijk. Developers schrijven unit tests,
      product owners definiëren duidelijke acceptatiecriteria, en testers zorgen voor de overkoepelende teststrategie. In de beste teams die ik heb meegemaakt, voelt iedereen zich eigenaar van de kwaliteit. De tester is de facilitator, niet de enige
      bewaker. Hoe pas ik dit toe? In mijn werk als freelance QA engineer breng ik deze principes in de praktijk:
    • Vroege betrokkenheid bij refinement en planning
    • Test automation in de CI/CD pipeline voor continue feedback
    • AI-driven testing om slimmer en efficiënter te testen
    • Kennisdeling zodat het hele team verantwoordelijkheid neemt voor kwaliteit Het Agile Testing Manifesto is geen checklist — het is een mindset. En die mindset maakt het verschil tussen software die “werkt”
      en software waar je op kunt vertrouwen.