Decision Table Test Generation Prompt Template

This prompt is designed for test analysts and QA engineers who need to systematically convert a set of business rules into an exhaustive, combinatorial decision table. The core job-to-be-done is ensuring complete logical coverage: every possible permutation of conditions is mapped to its expected action, making implicit or missing rules visible. Use it when you have a formal or semi-formal specification—such as a requirements document, a user story's acceptance criteria, or a regulatory rule set—that defines conditions and their corresponding actions. The ideal input is a structured list of conditions (each with defined possible values) and actions, not a narrative paragraph.

The prompt's value is in exposing gaps. It forces the model to generate all combinations, flag contradictions where the same condition set maps to different actions, and highlight missing combinations where no action is defined. This is critical for high-stakes logic in finance, insurance, healthcare, or access control, where an unhandled condition permutation can lead to a compliance violation or a security flaw. For example, if a loan origination system has rules based on credit_score (high/low) and employment_status (employed/unemployed), the prompt will produce four test cases and flag if the low+unemployed combination has no defined action. Do not use this for simple input validation (e.g., checking a single field's format), API contract tests, or performance scenarios. It is specifically for logic-intensive, multi-condition business rules where interactions must be verified.

Before using this prompt, ensure your business rules are clearly defined and that you can articulate the conditions and their possible values. The prompt will not interpret vague prose; it requires discrete logical inputs. If your rules are embedded in long, unstructured documents, use a separate extraction prompt first to pull out the conditions and actions. The output is a structured test matrix, not executable code. Your next step after generation should be a human review of any flagged contradictions or missing rules, as these often indicate a defect in the specification itself, not just the test model.

This prompt template converts business rule specifications into structured decision table test cases. It is designed for test analysts who need to produce combinatorial test matrices with condition combinations, expected actions, and rule coverage. The template uses square-bracket placeholders that you must replace with your actual inputs before sending to the model. Each placeholder maps to a specific input type—business rules, constraints, output format requirements, and risk level—so the model has enough context to generate a complete, traceable decision table.

textCopy
You are a test analyst specializing in decision table testing. Your task is to convert business rule specifications into a complete decision table test matrix.

## INPUT
Business Rules Specification:
[RULES_SPECIFICATION]

Additional Context (domain, system behavior, dependencies):
[CONTEXT]

## CONSTRAINTS
- Generate all condition combinations unless explicitly limited
- Flag contradictory rules and missing permutations
- Include rule coverage summary
- Risk level for this test effort: [RISK_LEVEL]

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "decision_table_id": "string",
  "source_rules": ["rule_id", "rule_description"],
  "conditions": [
    {
      "condition_id": "string",
      "description": "string",
      "possible_values": ["value1", "value2"]
    }
  ],
  "test_cases": [
    {
      "test_case_id": "string",
      "condition_values": {"condition_id": "value"},
      "expected_action": "string",
      "expected_result": "string",
      "rule_reference": "rule_id",
      "notes": "string"
    }
  ],
  "coverage_summary": {
    "total_combinations": number,
    "combinations_tested": number,
    "untested_combinations": ["description"],
    "contradictory_rules_detected": [
      {
        "rule_pair": ["rule_id", "rule_id"],
        "conflict_description": "string"
      }
    ],
    "missing_permutations": ["description"]
  },
  "warnings": ["string"]
}

## EXAMPLES
Example business rule: "If customer is premium AND order total exceeds $500, apply 10% discount. If customer is premium AND order total does not exceed $500, apply 5% discount. If customer is not premium, no discount applies."

Example condition: {"condition_id": "C1", "description": "Customer is premium", "possible_values": ["true", "false"]}

Example test case: {"test_case_id": "TC-01", "condition_values": {"C1": "true", "C2": "true"}, "expected_action": "Apply 10% discount", "expected_result": "Discount applied to order total", "rule_reference": "R1", "notes": "Premium customer with high-value order"}

## INSTRUCTIONS
1. Extract all conditions from the business rules specification
2. Identify all possible values for each condition
3. Generate the full combinatorial matrix of condition values
4. Determine the expected action and result for each combination based on the rules
5. Flag any contradictory rules where the same condition combination maps to different actions
6. Identify any condition combinations not covered by the rules
7. If [RISK_LEVEL] is "high", include a human-review flag on any test case where the expected action is ambiguous
8. Return the complete JSON object following the output schema exactly

To adapt this template, replace each square-bracket placeholder with your actual content. [RULES_SPECIFICATION] should contain the full text of the business rules you are testing—include all conditions, actions, and any exception logic. [CONTEXT] should describe the system under test, relevant domain knowledge, and any dependencies that affect rule interpretation. [RISK_LEVEL] accepts values like "low", "medium", or "high" and controls whether ambiguous test cases receive a human-review flag. After replacing placeholders, validate that the output schema matches your test management system's expected format before integrating the prompt into your pipeline. For high-risk domains such as financial compliance or healthcare, always route the generated decision table through a human reviewer before committing it to your test suite.

This prompt is designed to be called from a test management pipeline where business rule specifications are the primary input. The typical integration pattern is: retrieve the specification document, extract the relevant rule statements, inject them into the [RULE_SPECIFICATION] placeholder along with any [DOMAIN_CONSTRAINTS] and [OUTPUT_SCHEMA], then submit the assembled prompt to the model. The output should be parsed as structured JSON and validated before ingestion into your test case management system (e.g., TestRail, Zephyr, Xray). Do not treat the raw model output as final—always run it through a validation layer that checks for schema conformance, contradictory rules, and missing condition permutations.

Validation is the critical post-processing step. Implement a validator that checks: (1) every condition combination in the Cartesian product of input conditions appears in the output table, (2) no two rows have identical condition values but different expected actions, (3) all action values match the enumerated set defined in [OUTPUT_SCHEMA], and (4) any domain invariants specified in [DOMAIN_CONSTRAINTS] are not violated. If validation fails, construct a retry prompt that includes the original specification, the invalid output, and a structured error report describing exactly which rows or rules failed. Limit retries to a maximum of three attempts before escalating to a human reviewer. Log every attempt—including the prompt version, model, timestamp, and validation result—for auditability and regression testing.

For high-risk domains such as financial compliance or healthcare eligibility rules, insert a mandatory human approval gate after validation passes. Route the validated decision table to a review queue where a subject matter expert can confirm that the generated rule combinations match business intent. The approval step should be lightweight: present the original rule specification alongside the generated table, highlight any rows the validator flagged as borderline (e.g., ambiguous condition boundaries), and require explicit sign-off before the test cases are committed to the test repository. Avoid fully automated ingestion for regulated workflows unless you have a calibrated eval harness with historical accuracy data. For model selection, prefer models with strong structured output and logical reasoning performance; test across at least two model families to identify which produces the fewest contradictory rule errors for your domain's rule complexity.