Combinatorial Validation for a Taxation Rules Module

The validation challenge

The module supported deemed assessment when a taxpayer had not submitted a return. In those cases, the system applied business rules using available information, including prior-year records and estimated values.

The interactions among these inputs created too many scenarios for dependable ad hoc testing. Checking selected examples could demonstrate that individual cases worked, but it could not establish systematic coverage of the feasible input space.

My contribution

My first task was to understand the business logic. I worked directly with tax experts and systems analysts to clarify the assessment rules, identify the relevant input dimensions, define invalid combinations, and understand the expected results.

I then designed an Oracle-based process that generated the feasible combinations defined by those rules and executed the resulting scenarios in batches. Within the agreed dimensions and constraints, this provided systematic coverage without requiring users to construct and test every case manually.

Validation and resolution

I reviewed the errors produced during batch execution, documented the failures, and worked with the development team to resolve them.

The wider delivery team already used structured requirements, issue reporting, and defect-resolution practices. My framework extended that discipline by making scenario generation and coverage repeatable.

I completed the assigned validation in approximately two months during a short engagement. I subsequently left to begin my PhD program in the United States, so this entry makes no claims about the system’s later deployment or operational performance.

Why it matters

This work combined business-rule analysis, database-driven test generation, systematic coverage, and collaborative defect resolution. It converted a validation problem that was impractical to address manually into a bounded and repeatable engineering process.