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.