Decision table testing in Testing Fundamentals - Framework Patterns

Framework Mode - Decision table testing

Folder Structure for Decision Table Testing Framework

  decision-table-testing/
  ├── decision_tables/
  │   ├── login_decision_table.csv
  │   ├── payment_decision_table.csv
  │   └── user_registration_decision_table.csv
  ├── tests/
  │   ├── test_login.py
  │   ├── test_payment.py
  │   └── test_user_registration.py
  ├── utils/
  │   ├── decision_table_parser.py
  │   └── test_executor.py
  ├── config/
  │   └── config.yaml
  ├── reports/
  │   └── latest_report.html
  └── README.md
  

Test Framework Layers

• Decision Tables Layer: Stores decision tables as CSV or Excel files defining conditions and expected actions.
• Parser Layer: Reads and interprets decision tables into test cases programmatically.
• Test Executor Layer: Runs tests based on parsed decision table data, driving the application or system under test.
• Test Scripts Layer: Contains test scripts that call the executor with specific decision tables for different features.
• Utilities Layer: Helper functions for data handling, logging, and assertion support.
• Configuration Layer: Holds environment settings, test parameters, and credentials.
• Reporting Layer: Generates readable test reports showing which decision table rules passed or failed.

Configuration Patterns

Use a config.yaml file to manage:

• Test environment URLs (dev, staging, production)
• Browser or platform settings if UI tests are involved
• Credentials or API keys (stored securely, not in code)
• Paths to decision table files

Load configuration at test start to keep tests flexible and environment-independent.

Test Reporting and CI/CD Integration

• Generate HTML or XML reports summarizing which decision table rules passed or failed.
• Include detailed logs showing input conditions and expected vs actual outcomes for each rule.
• Integrate with CI/CD pipelines (e.g., Jenkins, GitHub Actions) to run decision table tests automatically on code changes.
• Fail builds if critical decision table rules fail, ensuring quality gates.

Best Practices for Decision Table Testing Framework

• Keep decision tables clear and simple: Use concise condition and action descriptions for easy understanding.
• Automate parsing: Write reusable code to convert decision tables into test cases automatically.
• Separate data from code: Store decision tables outside test scripts to allow easy updates without code changes.
• Use descriptive test reports: Show which rules passed or failed with clear input and output details.
• Maintain traceability: Link decision table rules to requirements or user stories for coverage tracking.

Self Check Question

Where in this framework structure would you add a new decision table for testing the password reset feature?

Key Result

Organize decision tables as external data files parsed by reusable code to drive automated tests with clear reporting.

Practice

1. What is the main purpose of decision table testing in software testing?

easy

A. To improve software performance

B. To write code faster

C. To design user interfaces

D. To organize conditions and actions to cover all possible cases

Solution

1. Step 1: Understand decision table testing basics

   Decision table testing helps testers list all conditions and their possible actions systematically.

2. Step 2: Identify the main goal

   The goal is to cover all possible combinations of conditions to avoid missing or conflicting rules.

3. Final Answer:

   To organize conditions and actions to cover all possible cases -> Option D

4. Quick Check:

   Decision table = organize all cases [OK]

Hint: Think of decision tables as a checklist for all condition combos [OK]

Common Mistakes:

• Confusing decision tables with performance testing
• Thinking it is about coding speed
• Mixing it up with UI design

2. Which of the following is the CORRECT way to represent a condition in a decision table?

easy

A. Writing long paragraphs explaining the condition

B. Using 'Yes' or 'No' to show condition states

C. Using random numbers without meaning

D. Ignoring conditions and only listing actions

Solution

1. Step 1: Review how conditions are shown in decision tables

   Conditions are usually shown as simple states like 'Yes' or 'No' to keep clarity.

2. Step 2: Eliminate incorrect options

   Long paragraphs or random numbers confuse the table. Ignoring conditions defeats the purpose.

3. Final Answer:

   Using 'Yes' or 'No' to show condition states -> Option B

4. Quick Check:

   Conditions = Yes/No states [OK]

Hint: Use simple states like Yes/No for conditions in tables [OK]

Common Mistakes:

• Writing detailed text instead of simple states
• Using meaningless numbers
• Skipping conditions entirely

3. Given the decision table below, what is the expected action if Condition A = No and Condition B = Yes?

Condition A	Condition B	Action
Yes	Yes	Action 1
Yes	No	Action 2
No	Yes	Action 3
No	No	Action 4

medium

A. Action 3

B. Action 1

C. Action 2

D. Action 4

Solution

1. Step 1: Locate the row matching Condition A = No and Condition B = Yes

   Check the table row where Condition A is 'No' and Condition B is 'Yes'.

2. Step 2: Identify the corresponding action

   The matching row shows 'Action 3' as the action.

3. Final Answer:

   Action 3 -> Option A

4. Quick Check:

   Conditions No/Yes = Action 3 [OK]

Hint: Match conditions row to find the correct action quickly [OK]

Common Mistakes:

• Mixing up Yes/No order
• Choosing action from wrong row
• Ignoring one condition

4. A tester created a decision table but missed one condition combination. What is the likely problem caused by this mistake?

medium

A. All conditions are tested anyway

B. The software will run faster

C. Some test cases will be missing, causing incomplete testing

D. The decision table will have duplicate rows

Solution

1. Step 1: Understand the impact of missing condition combinations

   Missing a condition combo means that scenario is not tested.

2. Step 2: Identify the consequence

   Incomplete testing can let bugs slip through because not all cases are covered.

3. Final Answer:

   Some test cases will be missing, causing incomplete testing -> Option C

4. Quick Check:

   Missing combos = incomplete tests [OK]

Hint: Missing combos mean missing tests, not faster software [OK]

Common Mistakes:

• Thinking missing combos speed up software
• Assuming all conditions tested anyway
• Confusing missing combos with duplicates

5. You have a system with three conditions: C1, C2, and C3, each can be Yes or No. How many unique rules (rows) should a complete decision table have to cover all combinations?

hard

A. 8

B. 12

C. 9

D. 6

Solution

1. Step 1: Calculate total combinations for three binary conditions

   Each condition has 2 states (Yes/No). Total combinations = 2 * 2 * 2 = 8.

2. Step 2: Understand decision table rows

   Each unique combination corresponds to one rule (row) in the decision table.

3. Final Answer:

   8 -> Option A

4. Quick Check:

   2^3 = 8 rules needed [OK]

Hint: Use 2^number_of_conditions for total rules [OK]

Common Mistakes:

• Adding conditions instead of multiplying
• Using wrong powers (like 3^2)
• Confusing rules with actions