13 april 2026 · Jorick Timmer

Hoe Test Ik Complexe Business Logica?

Als QA-engineer voor een klant met complexe verzendlogica (meerdere landen, business units en uitzonderingen) zocht ik een manier om alles grondig te testen zonder er dagen over te doen. De oplossing: Claude inzetten als denkpartner om testscenario's op te stellen op basis van echte klantdocumentatie.

Verzendkosten, kortingen, op een ander adres laten bezorgen, toeslagen, landen buiten Nederland, landen buiten de EU. Dit zijn allemaal punten waarmee rekening mee gehouden moet worden bij een klant waar ik op dit moment de QA engineer ben. De hamvraag die je hierbij kan stellen, hoe kan ik dit allemaal goed en grondig testen zonder dagen lang bezig te zijn met het opsommen van alle regels en documentatie?

Situatie

Onderstaande diagrammen laten een duidelijk overzicht zien van de verschillende verzendmethodes die beschikbaar zijn. In de tweede diagram is te zien wat de uitzonderingen zijn per business unit (lees klant)

Diagram 1: Verzendopties overzicht

Diagram 1: Verzendopties overzicht

Diagram 2: Uitzonderingen per optie

Diagram 2: Uitzonderingen per optie

Aanpak

Het antwoord ligt in de huidige tijd voor de hand: een beetje van mezelf, en een beetje van Maggi (lees Claude). De documentatie voor de business logica wordt in dit geval aangereikt door de klant, deze wil immers de implementatie van deze logica hebben. Vanuit de klant zijn goede voorbeelden gegeven van allerlei mogelijke scenario's.Dit zorgt ervoor dat Claude makkelijk test scenario's en cases kan uitschrijven, die ik vervolgens zelf goed kan testen (dit kan natuurlijk ook geautomatiseerd, maar dat laten we voor nu even achterwege). Het gevolg is een goed en uitgebreid testplan met duidelijke stappen hoe ik het beste de test cases kan uitvoeren. Omdat er in de voorbeelden veel context wordt meegegeven worden de teksten uitgebreid. Het gevaar van LLM gebruik in het algemeen is het meegeven van weinig of incorrecte context waardoor het gaat hallucineren, echter met het meegeven vanharde voorbeelden wordt dit gedrag voorkomen. De prompts die ik gegeven heb waren simpel door de goede context:

Vat dit ticket voor mij samen zodat ik hiermee kan testen

Met als bijlage het document van 5 kantjes met alle logica.

Vervolgens:

Geef mij voor elke shipment option een test scenario met bijbehorende test cases

Klein nadeel, dit project is een monorepo met twee applicaties. Hierdoor moet ik wel telkens erbij vermelden dat Claude moet zoeken in Project X en niet in project Y. Echter kan je dit makkelijk afvangen met een .md file waarin dit staat vermeld. Door de .md file te update blijft hij goede specifieke antwoorden geven.

Test scenario' en cases

Onderstaande tabel laat de test scenario's en bijbehorende cases van een van de vele scenario's zien.


Test scenario's en cases

Resultaat:

Een uitgebreid test rapport met testen voor alle 6 scenarios (de 6 verzendmethoden) en nog een paar testcases die overkoepelend zijn en niet direct te linken aan een scenario. Dit rapport heeft alle nodige stappen, het verwachte resultaat, en na een extra prompt ook eenkolom met het eigenlijke resultaat. Met dit test rapport ben ik aan de slag gegaan. Bugs heb ik gerapporteerd in de correcte kolom, vervolgens aan Claude gevraagd of die alle gevonden bugs netjes wilt uitschrijven in aparte. bug reports waar vervolgens het dev team weer aan de slag kon om de bugs te fixen. Ook hier kun je weer een .md gebruiken voor specifieke bug rapportage wensen

Conclusie

Claude heeft in dit project goed geholpen door alle logica voor mij uit te pluizen en op te sommen in duidelijke testscenario's. Dit heeft mij gigantisch veel tijd gescheeld waardoor ik bezig kon met andere uitdagingen binnen het project, zoals een user acceptance test en falende automatisering in de pipeline.

Klaar voor sneller leveren?

Plan een vrijblijvend intro-gesprek van 30 minuten.

Plan gesprek →