Decision Table Testing: Techniques, Examples, and Test Cases

Decision table testing is a black-box software testing technique that verifies how a system behaves under different combinations of conditions. Testers organize business conditions and expected actions in a table, then design test cases to confirm that the application produces the correct outcome for each relevant combination.

For example, imagine an e-commerce application that offers free shipping only when a customer's order meets certain conditions.

The decision may depend on order value, customer membership, and delivery location.

Testing each condition separately may not reveal errors that occur when conditions interact.

A decision table makes those interactions visible.

It allows testers to answer important questions:

• Have all relevant combinations been considered?
• Does the application follow the approved business requirements?
• Are boundary values handled correctly?
• Are exceptions implemented consistently?
• Do different conditions ever produce conflicting outcomes?
• Which decision rules have been tested?

This technique is especially useful for applications involving eligibility, approvals, pricing, insurance claims, customer benefits, and other decisions governed by multiple requirements.

This guide explains the technique, demonstrates a complete worked example, shows how to convert decision rules into executable test cases, and provides practical coverage calculations, test templates, and validation checklists.

What Is Decision Table Testing?

A decision table represents the relationship between input conditions and expected system actions.

Each rule column describes a combination of conditions and the corresponding outcome.

Testers use these combinations to verify whether a software application implements the intended business logic correctly.

The technique is classified as black-box testing because test cases can be designed from requirements and observable behavior without needing access to the source code.

For example, a subscription application might apply this requirement:

A customer receives a loyalty discount when the subscription is active, the membership duration is at least 12 months, and no payment restriction applies.

The decision depends on three conditions:

1. Is the subscription active?
2. Has the customer been a member for at least 12 months?
3. Is there an unresolved payment restriction?

Testing only an eligible customer would not establish whether the software correctly handles every ineligible combination.

A decision table provides a structured way to examine them.

The Four Main Elements of a Decision Table

Element	Purpose	Example
Conditions	Identify the facts influencing a decision	Subscription active?
Condition values	Describe the possible states of each condition	Yes / No
Actions or outcomes	Define the expected behavior	Apply discount
Rules	Connect condition combinations with expected outcomes	Active + qualified duration + no restriction = eligible

A decision rule is not the same as a business rule statement.

A business rule may establish the general requirement, while a decision table rule describes a particular combination of inputs and its expected result.

Why Decision Tables Are Useful in Software Testing

Many software defects occur because developers overlook combinations of otherwise familiar conditions.

For example:

• An approval threshold works correctly for ordinary requests but fails for restricted suppliers.
• A discount applies correctly to eligible members but also applies to members with payment restrictions.
• A refund is rejected after its deadline even when an approved exception exists.
• A claim is processed without checking the required authorization status.

Decision tables help expose these combinations before or during implementation.

They are especially valuable when several Boolean conditions, classifications, or ranges influence one decision.

How the Decision Table Testing Technique Works

The basic process begins with the expected business behavior and ends with evidence that the application handles the relevant conditions correctly.

Step 1: Identify the Decision Being Tested

Start with a specific question.

Examples:

• Is a customer eligible for a discount?
• Does a purchase require additional approval?
• Can an insurance claim proceed?
• Which shipping charge applies?
• Is an employee eligible for a particular benefit?

Avoid beginning with an entire business process.

A narrow decision makes conditions and outcomes easier to identify.

Example decision: Is the customer eligible for a loyalty discount?

Step 2: Identify the Governing Requirements

Review the approved requirements and relevant policies.

For example:

A customer qualifies for a loyalty discount only when the subscription is active, membership duration is at least 12 months, and the account has no unresolved payment restriction.

This requirement establishes three conditions.

It also raises questions that may require clarification.

What qualifies as active? How is membership duration calculated? What counts as an unresolved restriction?

Test design should not silently invent business definitions.

Step 3: List the Input Conditions

For the loyalty discount example:

Condition ID	Condition
C1	Subscription is active
C2	Membership duration is at least 12 months
C3	No unresolved payment restriction exists

Each condition has two possible values: True or False.

Step 4: Identify Expected Outcomes

For this example, the relevant outcomes are:

A1: Discount eligible.

A2: Discount not eligible.

An organization might also need a third outcome, such as Requires Verification, when necessary information is unavailable.

That situation should be modeled explicitly if it belongs to the decision's scope.

Step 5: Generate Condition Combinations

With three independent Boolean conditions, the maximum number of combinations is:

[ 2^3 = 8 ]

This produces eight combinations for review.

The formula assumes that all three conditions have two possible values and that every combination is logically possible.

Step 6: Assign Expected Results

For each combination, determine the expected result using the approved business requirements.

Do not assume that every combination is valid or that the last rule automatically takes precedence.

Step 7: Create Test Cases

Convert the decision-table rules into test cases containing:

• Test case ID.
• Rule reference.
• Input values.
• Preconditions.
• Expected outcome.
• Actual outcome.
• Execution status.

Step 8: Execute and Compare Results

Run the tests against the application or decision service.

Compare actual results with the approved expected outcomes.

Record defects when the system behaves incorrectly.

Step 9: Measure Coverage

Determine which decision-table rules have been exercised.

Also examine whether relevant boundary, missing-data, and exception scenarios have been tested.

Step 10: Review Results With Stakeholders

If a test reveals an unexpected outcome, determine whether the problem comes from:

• An implementation defect.
• An incorrect test expectation.
• An incomplete requirement.
• An undefined business term.
• A conflicting rule.
• An environmental or test-data issue.

Not every failed test proves that the application code is wrong.

Decision Table Testing Examples: Complete Worked Scenario

Consider a fictional subscription service that offers a 15% loyalty discount.

The approved business requirement states:

A customer is eligible for the loyalty discount only when the subscription is active, membership duration is at least 12 months, and no unresolved payment restriction exists.

The organization wants to test its discount eligibility service.

Step 1: Define the Conditions

We have three conditions.

C1: Active subscription?

C2: Membership duration at least 12 months?

C3: No unresolved payment restriction?

The expected outcome is either Eligible or Not Eligible.

Step 2: Build the Full Decision Table

For readability, each row below represents one testable decision rule. A traditional condition/action decision table may instead place these rules in columns.

Rule ID	C1: Active	C2: 12+ Months	C3: No Restriction	Expected Outcome
R1	Yes	Yes	Yes	Eligible
R2	Yes	Yes	No	Not Eligible
R3	Yes	No	Yes	Not Eligible
R4	Yes	No	No	Not Eligible
R5	No	Yes	Yes	Not Eligible
R6	No	Yes	No	Not Eligible
R7	No	No	Yes	Not Eligible
R8	No	No	No	Not Eligible

The table contains eight combinations.

Only R1 produces an eligible outcome.

This is because the hypothetical requirement requires all three conditions to be satisfied.

Step 3: Convert the Rules Into Test Cases

Each rule needs concrete input values.

Assume the application receives:

• subscription_status
• membership_months
• payment_restriction

The test data can be:

Test Case	Decision Rule	Subscription	Membership Months	Restriction	Expected Result
TC-001	R1	Active	18	No	Eligible
TC-002	R2	Active	18	Yes	Not Eligible
TC-003	R3	Active	8	No	Not Eligible
TC-004	R4	Active	8	Yes	Not Eligible
TC-005	R5	Inactive	18	No	Not Eligible
TC-006	R6	Inactive	18	Yes	Not Eligible
TC-007	R7	Inactive	8	No	Not Eligible
TC-008	R8	Inactive	8	Yes	Not Eligible

These are executable test specifications once the test environment, API contract, and required preconditions are defined.

Notice that each test case has an expected result.

The result comes from the business requirement, not from guessing how the application currently behaves.

Step 4: Execute the Tests

Suppose the fictional system produces these results:

Test Case	Expected	Actual	Status
TC-001	Eligible	Eligible	Pass
TC-002	Not Eligible	Eligible	Fail
TC-003	Not Eligible	Not Eligible	Pass
TC-004	Not Eligible	Not Eligible	Pass
TC-005	Not Eligible	Not Eligible	Pass
TC-006	Not Eligible	Not Eligible	Pass
TC-007	Not Eligible	Not Eligible	Pass
TC-008	Not Eligible	Not Eligible	Pass

The results show that TC-002 failed.

The application incorrectly granted a discount when an unresolved payment restriction existed.

This is an illustrative defect, not a real production finding.

Step 5: Investigate the Defect

The tester should examine whether:

• The restriction was correctly stored.
• The test sent the expected input.
• The eligibility service received the value.
• The relevant condition was evaluated.
• Another rule overrode the expected outcome.
• The deployed rule version matched the approved requirement.

The defect report should reference the relevant decision rule and test case.

Step 6: Retest After Correction

After the implementation is corrected, rerun TC-002.

Then execute the broader regression suite to confirm that the change has not affected other combinations.

Key lesson: Testing multiple combinations can reveal defects that a single successful eligibility test would miss.

Decision Table Testing Test Cases: Boundary and Exception Scenarios

The eight tests above cover the Boolean combinations in the model.

However, they do not cover every possible defect.

The membership condition depends on a numeric threshold.

Testing only 8 and 18 months does not confirm correct handling at exactly 12 months.

Boundary Value Tests

Add cases around the threshold.

Test Case	Membership Months	Other Conditions	Expected Result
TC-009	11	Active, no restriction	Not Eligible
TC-010	12	Active, no restriction	Eligible
TC-011	13	Active, no restriction	Eligible

These tests can detect incorrect comparison operators.

For example, the software might incorrectly implement:

membership_months > 12

Instead of:

membership_months >= 12

A test at exactly 12 months would expose this defect.

Missing Information Tests

What happens when membership duration is unavailable?

The original requirement does not specify that behavior.

The analyst should obtain clarification rather than assume eligibility.

Possible additional test scenarios include:

Test Case	Input Problem	Expected Handling
TC-012	Membership duration missing	Follow approved missing-data policy
TC-013	Subscription status unknown	Request verification or return defined error
TC-014	Restriction value unavailable	Do not assume restriction-free status

The final expected results must be approved before these cases become formal acceptance tests.

Invalid Input Tests

A tester should also consider invalid values.

Examples include:

• Negative membership duration.
• Unsupported subscription status.
• Unexpected data type.
• Invalid customer identifier.

These may be best covered through input validation tests rather than by adding every invalid value to the main eligibility decision table.

Exception Tests

If the business permits approved exceptions, they must be represented explicitly.

For example, some customers may qualify under a contract-specific program.

Do not automatically add exceptions to the existing table without confirming their relationship to the general requirement.

An exception may require a separate decision table or additional condition.

Simplified vs. Complete Decision Tables

A complete decision table lists relevant combinations.

A simplified or collapsed table combines combinations that produce the same outcome when certain conditions do not influence the result.

Both forms can support testing.

However, they provide different levels of visibility.

Complete Decision Table

The loyalty example uses eight combinations.

It explicitly shows every combination of the three Boolean conditions.

This makes it useful for identifying missing conditions and testing interactions.

Simplified Decision Table

The same logic can be expressed more compactly:

Rule	Active Subscription	12+ Months	No Restriction	Outcome
S1	No	—	—	Not Eligible
S2	Yes	No	—	Not Eligible
S3	Yes	Yes	No	Not Eligible
S4	Yes	Yes	Yes	Eligible

The dash means the condition does not affect the outcome for that particular rule.

For example, an inactive customer is ineligible regardless of membership duration or payment restrictions.

The order of the rows here is chosen to make the rules mutually exclusive.

Important Testing Consideration

A simplified table reduces the number of rule columns that need representatives for rule coverage.

However, fewer test cases do not automatically provide equivalent confidence.

If the software contains a defect involving a supposedly irrelevant condition, a single representative from the collapsed rule may not expose it.

For critical or complex logic, additional tests should cover interactions, exceptions, and significant boundaries.

Use simplification only when the underlying business requirements justify it.

Decision Table Testing Coverage: How to Measure It

Coverage measures which parts of the defined test model have been exercised.

It should not be confused with the percentage of tests that passed.

These are different metrics.

1. Decision Rule Coverage

Rule coverage measures the proportion of decision-table rules exercised by tests.

A straightforward calculation is:

[ \text{Rule Coverage} = \frac{\text{Rules Exercised}}{\text{Total Applicable Rules}} \times 100 ]

Suppose the complete loyalty table contains eight rules.

If six rules are exercised:

[ \frac{6}{8} \times 100 = 75% ]

The test suite has 75% rule coverage.

If all eight rules are exercised, rule coverage is 100%.

This does not mean the application is defect-free.

2. Test Pass Rate

Pass rate measures the proportion of executed tests that meet expectations.

[ \text{Pass Rate} = \frac{\text{Passed Tests}}{\text{Executed Tests}} \times 100 ]

In the earlier example:

• Eight tests were executed.
• Seven passed.
• One failed.

The pass rate is:

[ \frac{7}{8} \times 100 = 87.5% ]

The decision-rule coverage is 100%, while the pass rate is 87.5%.

Both values are useful, but they answer different questions.

3. Condition Value Coverage

This examines whether relevant condition values have appeared in the tests.

For a Boolean condition, testers may verify that both True and False have been exercised.

However, condition value coverage alone does not prove that all condition combinations have been tested.

For example, two tests might exercise both values of each condition while missing most of the eight combinations.

4. Outcome Coverage

Outcome coverage examines whether all defined decision results have been exercised.

For the loyalty example, the outcomes are Eligible and Not Eligible.

Testing one case for each outcome gives coverage of both outcome categories.

But it does not establish complete rule coverage.

5. Boundary and Exception Coverage

These checks examine whether additional scenarios have been tested.

Examples include:

• Exactly at a threshold.
• Immediately below or above a threshold.
• Missing required information.
• Invalid values.
• Approved exceptions.
• Conflicting requirements.

These coverage areas require their own defined scope and criteria.

They should not be reported as interchangeable with decision-table rule coverage.

Coverage Comparison

Coverage Type	What It Measures	What It Does Not Guarantee
Rule coverage	Decision-table rules exercised	Correct outcomes or complete requirements
Condition value coverage	Relevant condition states exercised	Every combination tested
Outcome coverage	Defined outcomes exercised	Every rule tested
Boundary coverage	Specified edge values tested	All condition interactions
Exception coverage	Documented exceptional paths tested	All unexpected production scenarios
Test pass rate	Executed tests meeting expectations	Test model completeness

Practical recommendation: Use rule coverage as a baseline, then add appropriate boundary, invalid-data, and exception testing based on business risk.

How to Write Effective Decision Table Test Cases

A good test case contains enough information for another tester to reproduce the scenario and understand why the expected outcome is correct.

Recommended Test Case Template

Field	Description
Test Case ID	Unique identifier
Decision Name	Decision being evaluated
Decision Rule ID	Relevant rule column or combination
Business Rule Reference	Governing requirement
Preconditions	Required initial state
Input Data	Values supplied to the system
Test Steps	Actions required to execute the test
Expected Result	Approved expected outcome
Actual Result	Observed behavior
Execution Status	Pass, Fail, Blocked, Not Run
Defect Reference	Related issue identifier
Evidence	Logs, output, screenshots, or test records
Rule Version	Version being evaluated

Example Test Case

Test Case ID: TC-002

Decision: Loyalty Discount Eligibility

Decision Rule: R2

Preconditions: Test customer exists with an active subscription and verified membership history.

Inputs:

• Subscription status: Active.
• Membership duration: 18 months.
• Unresolved payment restriction: Yes.

Steps:

1. Prepare the customer record.
2. Submit the eligibility request.
3. Capture the returned decision.
4. Compare it with the expected outcome.

Expected result: Not Eligible.

Actual result: Eligible.

Status: Fail.

Potential defect: The implementation did not properly enforce the payment restriction.

The test case provides a direct connection between an input combination, the expected business result, and observable behavior.

Keep Tests Traceable

Tests should remain connected to their source requirements.

A useful traceability relationship is:

Policy → Business Rule → Decision Table Rule → Test Case → Execution Result

A business rules traceability matrix helps teams preserve these connections as requirements and implementations change.

For example, if the membership requirement changes from 12 to 18 months, the team can identify affected decision rules, boundary cases, and test data.

Decision Table Testing vs. Other Testing Techniques

Decision tables are particularly useful for testing combinations of business conditions.

Other techniques address different types of defects.

Technique	Primary Focus	Example
Decision table testing	Combinations of conditions and expected actions	Discount eligibility
Equivalence partitioning	Groups of inputs expected to behave similarly	Valid and invalid customer categories
Boundary value analysis	Values near defined thresholds	11, 12, and 13 months
State transition testing	Changes between system states	Account active → suspended
Use case testing	User-system interactions across scenarios	Complete refund request
Pairwise testing	Selected pairs of parameter values	Browser, device, and configuration combinations
Branch testing	Code decision outcomes	True and false execution branches

These techniques are complementary.

For example, a discount eligibility decision may use a table to cover condition combinations and boundary analysis to verify threshold handling.

A subscription lifecycle may require state transition tests in addition to eligibility tests.

Decision Table Testing vs. State Transition Testing

A decision table answers:

What outcome should occur for this combination of conditions?

State transition testing answers:

What state change should occur when an event happens in the current state?

For example, a subscription may move from Active to Suspended after a qualifying event.

A state model describes the permitted transitions.

A decision table can describe the rules determining whether suspension is required.

Decision Table Testing vs. Branch Coverage

These techniques are also different.

Decision tables can be designed from requirements without source-code knowledge.

Branch coverage measures whether alternative control-flow outcomes in implemented code have been executed.

A test suite may achieve complete branch coverage while failing to test important combinations defined in business requirements.

Conversely, full decision-table rule coverage does not guarantee every code branch has been executed.

Both measures may be relevant in a comprehensive test strategy.

Handling Conflicting and Overlapping Decision Rules

A decision table can reveal ambiguous or conflicting outcomes.

For example, consider these fictional purchasing requirements:

Rule A: Purchases above $10,000 require finance director approval.

Rule B: Purchases from restricted suppliers require procurement review.

A $15,000 purchase involving a restricted supplier satisfies both rules.

The outcomes are not necessarily contradictory.

Both approvals may be required.

The application needs defined behavior for handling simultaneous requirements.

Common Conflict Types

Overlapping rules: Multiple conditions apply to one transaction.

Contradictory outcomes: Two applicable requirements produce incompatible results.

Missing precedence: The system has no approved way to resolve overlapping outcomes.

Undefined cases: A combination has no specified result.

Version mismatch: The implementation uses an outdated requirement.

How Testers Should Handle Conflicts

1. Identify the condition combination.
2. Record the competing expected outcomes.
3. Check the authoritative rule sources.
4. Confirm whether the rules apply to the same context.
5. Investigate any approved exceptions.
6. Obtain clarification from the appropriate business owner.
7. Update the expected outcome before finalizing the test.

Do not allow test designers to invent organizational policy.

For a deeper framework, see how to identify conflicting business rules across departments when different stakeholders or systems apply incompatible requirements.

Testing should expose unresolved business logic rather than conceal it.

Common Mistakes in Decision Table Testing

1. Testing Only the Successful Outcome

A tester checks one eligible customer and assumes the decision works.

Why it fails: The application may incorrectly accept ineligible combinations.

Better approach: Cover the relevant positive and negative conditions.

2. Omitting Impossible Combinations Without Explanation

Some combinations cannot occur under the business model.

Why it fails: An excluded combination may actually be possible under unusual circumstances.

Better approach: Document why each combination is infeasible, and validate that assumption.

3. Confusing Rule Coverage With Pass Rate

All rules can be tested even when some tests fail.

Better approach: Report coverage and execution results separately.

4. Ignoring Boundary Values

A condition such as membership duration of at least 12 months has an important boundary.

Better approach: Test values at, below, and above the threshold.

5. Over-Simplifying Decision Tables

Collapsing combinations can reduce testing effort but may hide interaction defects.

Better approach: Retain additional tests for significant combinations when risk justifies them.

6. Using Unapproved Expected Results

Testers sometimes infer what the system should do from existing application behavior.

Better approach: Base expectations on validated business requirements.

7. Ignoring Missing or Invalid Information

Normal decision tables often assume valid inputs.

Better approach: Add appropriate validation tests for unknown, missing, or malformed values.

8. Failing to Revisit Tests After Rule Changes

A requirement change may affect several test cases.

Better approach: Maintain traceability and perform targeted regression analysis.

How to Validate Decision Tables Before Test Execution

Before executing the tests, review the underlying decision model.

This prevents teams from spending time automating ambiguous or incorrect expectations.

Completeness

Check whether every relevant combination has an expected outcome.

For a complete Boolean table, review all feasible combinations.

For a collapsed table, verify that merged combinations genuinely share the same behavior.

Consistency

Ensure that a particular combination does not produce incompatible outcomes unless the business explicitly allows multiple actions.

If multiple actions are expected, document how they interact.

Business Accuracy

Verify that the decision outcomes reflect approved requirements rather than assumptions.

A clearly structured table can still represent the wrong business logic.

Boundary Precision

Check comparison operators and threshold definitions.

For example:

• Greater than $10,000.
• Greater than or equal to $10,000.
• Less than or equal to $10,000.

These conditions are not interchangeable.

Exception Handling

Identify cases requiring:

• Human review.
• Additional approval.
• Missing-data verification.
• Alternative policy evaluation.
• Explicit rejection.

Traceability

Ensure each important outcome can be connected to the requirement establishing it.

A practical business rules validation checklist can support this review before decision logic is implemented or automated.

Can Decision Table Testing Be Automated?

Yes. Decision tables are well suited to data-driven test automation because their condition combinations can be represented as structured test data.

A test framework can execute the same application or API operation repeatedly using different inputs.

Example Automated Test Logic

The following Python example shows a simplified eligibility function and parameterized-style test data.

def is_eligible(active, months, no_restriction):
    return active and months >= 12 and no_restriction


test_cases = [
    ("TC-001", True, 18, True, True),
    ("TC-002", True, 18, False, False),
    ("TC-003", True, 8, True, False),
    ("TC-004", True, 8, False, False),
    ("TC-005", False, 18, True, False),
    ("TC-006", False, 18, False, False),
    ("TC-007", False, 8, True, False),
    ("TC-008", False, 8, False, False),
]

for test_id, active, months, no_restriction, expected in test_cases:
    actual = is_eligible(active, months, no_restriction)
    assert actual == expected, (
        f"{test_id}: expected {expected}, got {actual}"
    )

This demonstrates how decision-table data can drive automated assertions.

However, it tests the sample function, not an independently deployed business system.

For meaningful implementation testing, the same cases should be executed against the actual application or decision API using representative test data.

When Automation Is Valuable

Automation is particularly helpful when:

• A decision has many combinations.
• Rules change frequently.
• The same decision is used across several applications.
• Regression testing is repeated regularly.
• Results must be compared across software versions.
• A rule engine exposes a suitable evaluation interface.

Automation Limitations

Test automation does not determine whether the underlying business requirement is correct.

It also does not guarantee complete coverage simply because every generated test passes.

Human review remains necessary to confirm applicability, exceptions, and expected business outcomes.

Decision Table Testing Checklist

Use this checklist when designing or reviewing a decision-based test suite.

Requirements Review

• The business decision is clearly identified.
• Relevant requirements are approved.
• Important business terms are defined.
• Conditions have unambiguous meanings.
• Exceptions and precedence are documented.

Table Design

• All relevant conditions are included.
• Possible condition values are identified.
• Feasible combinations are represented.
• Excluded combinations have documented reasons.
• Every applicable rule has an expected outcome.
• Overlapping and conflicting rules have been reviewed.

Test Case Design

• Test cases have unique identifiers.
• Each applicable decision rule has test coverage.
• Concrete input values are defined.
• Expected results are documented.
• Boundary values are included where relevant.
• Invalid and missing-data cases are considered.
• Authorized exceptions are tested.

Execution and Reporting

• Tests run against the intended system version.
• Actual results are recorded.
• Defects are linked to affected rules.
• Coverage and pass rate are reported separately.
• Failed cases are investigated.
• Corrected defects are retested.
• Related regression tests are executed.

Maintenance

• Business rules are linked to tests.
• Rule versions are recorded.
• Test cases are reviewed after relevant changes.
• Obsolete tests are updated or retired.
• Results remain available for appropriate review.

Frequently Asked Questions

What Is Decision Table Testing in Software Testing?

It is a black-box test technique used to verify how software responds to combinations of input conditions. Testers define the expected action or outcome for each relevant combination and create test cases to confirm that the implementation follows the approved requirements.

What Is a Simple Decision Table Testing Example?

Consider a loyalty discount that requires an active subscription, at least 12 months of membership, and no payment restriction. A table lists combinations of these conditions and their expected eligibility outcomes. Tests verify that the application grants the discount only when all required conditions are satisfied.

How Do You Create Test Cases From a Decision Table?

Identify each applicable decision rule, select concrete input values that satisfy its conditions, and document the expected outcome. Add preconditions and execution steps. Then run the test against the system, compare the actual result, and record the execution status.

What Is 100% Decision Table Coverage?

For a specified decision table, 100% rule coverage means every applicable rule column or represented combination has been exercised by at least one test. It does not mean all tests passed, all business requirements are correct, or every possible software defect has been detected.

What Is the Difference Between a Full and a Collapsed Decision Table?

A full table explicitly represents the relevant condition combinations. A collapsed table combines combinations when some conditions do not affect the outcome. Collapsing can reduce the number of representative tests needed for rule coverage, but additional testing may still be necessary to detect interaction defects.

Is Decision Table Testing Black-Box or White-Box Testing?

It is generally classified as a black-box technique because test cases are derived from specified conditions and expected outcomes rather than source-code structure. Developers may also use decision tables during unit testing, but the technique itself focuses on observable decision behavior.

When Should You Use Decision Table Testing?

Use it when a decision depends on multiple conditions that interact to determine an outcome. Common applications include eligibility checks, approval decisions, discounts, insurance processing, and policy-driven workflows. It is especially useful when separate tests of individual conditions may overlook important combinations.

Conclusion

Decision table testing helps software testers and business analysts verify that applications behave correctly when multiple business conditions interact.

Rather than testing only successful scenarios, the technique organizes relevant combinations and connects them to defined outcomes.

A reliable approach includes identifying the governing requirements, constructing a complete or justified simplified table, generating concrete test cases, and measuring which rules have been exercised.

The worked loyalty discount example shows why this matters.

A system can correctly approve an eligible customer while incorrectly approving another customer with a payment restriction.

Testing condition combinations exposes this type of defect.

However, effective testing goes beyond exercising every table rule.

Teams should also consider boundary values, missing information, authorized exceptions, conflicting requirements, and regression impacts.

For business analysts and QA professionals, the central principle is simple:

A decision table describes what should happen under defined conditions. Testing provides evidence that the implemented system behaves accordingly.