Understanding Scenarios Not Eligible for Data-Driving (Default Test Cases)

In ACCELQ, the standard automation workflow involves creating Scenarios driven by test case data. Typically, input parameters defined at the Action level bubble up to the Scenario level, allowing users to create multiple Test Cases, each with unique data sets (e.g., testing a login flow with positive, negative, and boundary data).

However, there are specific situations where a Scenario is deemed "Not Eligible for Data-Driving." In these instances, the system automatically generates a single Default Test Case.

Conditions for Non-Data-Driven Scenarios

A Scenario is considered ineligible for data-driving when there are no dynamic input parameters exposed to the Test Case level. This occurs in two primary cases:

1. Scenarios with No Parameters

The simplest cause is when the Scenario consists of steps (Actions) that naturally require no user input, or where values are fixed within the Action logic itself.

• Example: A "Guest User Verification" Scenario.

  • Step 1: The Invoke Browser Action has the application URL hardcoded directly within the Action's logic, rather than passed as a parameter.

  • Step 2: The Verify Home Page Action checks for the existence of a logo.

  • Step 3: The Verify Footer Action checks for copyright text.

None of these steps requires external input to function, and the Scenario has no data requirements.

2. Scenarios with Fully Overridden Parameters

A Scenario may contain Actions that originally had input parameters (e.g., a specific "Search Term" or "User ID"), but these parameters have been handled or "consumed" at the Scenario step level.

Parameters are considered handled at the Scenario step level if they are configured in one of the following ways:

1. Static Value Override: The user manually assigns a hardcoded static value to the parameter within the Scenario step.

2. Global Property Override: The parameter is assigned a value from a Global Property (e.g., Admin URL).

3. Parameter Linking: The parameter is linked to an output or input from a previous step in the flow (e.g., Step 2 uses an "Order ID" output generated by Step 1).

4. Run Properties: The parameter is linked to a Run Property. These are values supplied by the user at the moment of execution, or passed dynamically from a previous test case in a suite. 

Learn more about Parameter Overriding here.

When all parameters across all steps in a Scenario are resolved using the methods above, there are no remaining variables for a Test Case to control. Consequently, data-driven testing (multiple data rows) is not feasible.

The Default Test Case

When the system detects that a Scenario has no exposed parameters, it automatically creates a Default Test Case.

Characteristics:

• System-Generated: It is created automatically; users do not need to manually add it.

• Single Instance: Since there are no data variations possible, only one Test Case is required to represent the execution of this Scenario.

• Placeholder for Execution: This Test Case serves as the entity that is selected when adding the Scenario to a Test Suite.

• Read-Only Data: The data grid usually seen in standard Test Cases is hidden. Users will see an informational message: "Scenario is Not Eligible for Data-Driving. All step parameters in the business process use non-test case sources (overridden)."

Managing Custom Fields and Tags

Even though the data for a Default Test Case cannot be varied, the metadata remains fully editable. This ensures the Test Case can still be effectively organized, tracked, and reported on within the project lifecycle.

Users can modify (by double-clicking the cell):

1. Custom Fields: Any custom fields defined for Test Cases in the Project Administration (e.g., Test Type, Priority etc.) can be populated for the Default Test Case.

2. Tags: Users can add tags for filtering and regression suite planning.