How Do I Test Complex Business Logic?

Shipping costs, discounts, delivering to a different address, surcharges, countries outside the Netherlands, countries outside the EU. These are all factors that need to be taken into account for a client I am currently working for as QA engineer. The key question you can ask yourself: how can I test all of this thoroughly without spending days listing all the rules and documentation?

Situation

The diagrams below give a clear overview of the different shipping methods available. The second diagram shows the exceptions per business unit (read: client).

Diagram 1: Shipping options overview

Diagram 2: Exceptions per option

Approach

The answer is obvious in this day and age: a bit of myself, and a bit of Maggi (read: Claude). The business logic documentation is provided by the client — they want the implementation of that logic, after all. The client has given good examples of all kinds of possible scenarios. This makes it easy for Claude to write out test scenarios and cases, which I can then test myself (this can of course also be automated, but let's leave that aside for now). The result is a thorough and comprehensive test plan with clear steps on how to best execute the test cases. Because the examples provide a lot of context, the output is detailed. The general danger with LLM usage is providing little or incorrect context, which causes hallucinations — but by providing concrete examples, this behavior is prevented. The prompts I gave were simple, thanks to the good context:

Summarize this ticket for me so I can use it for testing.

With the 5-page logic document attached.

Then:

"Give me a test scenario with corresponding test cases for each shipment option"

One minor downside: this project is a monorepo with two applications. This means I have to keep reminding Claude to look in Project X and not Project Y. You can easily handle this with a .md file that specifies this. By keeping the .md file up to date, it continues to give accurate, specific answers.

Test scenario's and cases

The table below shows the test scenarios and corresponding cases for one of the many scenarios.

Result:

A comprehensive test report covering all 6 scenarios (the 6 shipping methods), plus a few overarching test cases not directly tied to a specific scenario. The report has all the necessary steps, the expected result, and — after one extra prompt — a column for the actual result. I used this test report to do my testing. Bugs I reported in the correct column, then asked Claude to write up all the found bugs neatly in separate bug reports, which the dev team could then work through to fix. Here too, you can use a .md file for specific bug reporting preferences.

Conclusion

Claude helped a great deal on this project by breaking down all the logic and summarizing it into clear test scenarios. This saved me an enormous amount of time, freeing me up for other challenges in the project — such as a user acceptance test and failing automation in the pipeline.