Configuring Parameter Sources in a Scenario – ACCELQ

Every input parameter in a Scenario needs a value at execution time. By default, that value comes from the Test Cases defined for the Scenario: each Test Case row supplies its own value, which is what makes the Scenario data-driven. See Concept of Parameterization and Test Cases and Support for data-driven testing for the underlying model.

Some parameters should not vary by Test Case. An application URL is the same for every run, admin credentials are managed centrally, a value may only be known when the test is kicked off, or a step needs data produced by an earlier step. For these situations, you can configure a different source for any parameter. Configuring a source other than Test Case is referred to as overriding the parameter.

For example, a Scenario verifying employee records in an HRMS application logs in as an admin and verifies records for multiple employees defined in Test Cases. The employee data varies per Test Case, but the admin username and password do not. Overriding those two parameters with fixed values keeps the Test Cases focused on the data that actually varies.

ACCELQ provides two surfaces for this configuration: the Input Parameter Configuration panel, which shows every parameter in the Scenario in one place, and the Parameter Configuration dialog, which configures a single parameter. Both are described below.

Where a parameter can get its value

Parameter sources are organized in three categories. Data Driven sources vary per Test Case. Fixed sources use one value for all Test Cases. Dynamic sources compute the value during execution.

Category	Source	The value comes from	Typical use
Data Driven	From Test Case (default)	The Test Case grid, one value per Test Case	Business data that varies per data set, such as item names, amounts, expected results
Fixed	Literal Value	A static value entered in the configuration	A constant that never changes, such as a fixed account number
Fixed	Global Property	A Global Property managed centrally	Environment-specific data such as application URLs, managed across QA, Staging and Production
Fixed	Run Property	A value supplied when the test is kicked off	Values known only at run time, such as a one-time password
Dynamic	Linked Parameter	An input or output parameter of a preceding step	Passing data through the flow, such as an Order ID generated in one step and consumed in a later step

Global Properties and Run Properties are managed centrally; see Global Properties and Run Properties. A Run Property can also carry information across test cases within a Job; see Storing output parameters and passing data between different test cases.

Choosing a source

When deciding how a parameter should get its value, work through these questions:

Does the value vary by business data set? Keep it on From Test Case; that variation is exactly what your Test Cases are meant to cover.
Is it the same for every Test Case but different per environment, such as QA, Staging and Production? Use a Global Property, so Suites move across environments without touching any test.
Is it known only when the test is kicked off, supplied by a person or a CI pipeline, or regularly rotating like a password of the day? Use a Run Property.
Is it produced by the flow itself, such as an Order ID generated in an earlier step? Use a Linked Parameter and consume real data instead of pre-staging it.
Is it genuinely constant? Use a Literal Value when the value is specific to this one Scenario. If the same value is shared by multiple tests, or should be updatable in one place, prefer a Global Property even when it does not vary by environment; a Literal Value lives only inside this Scenario's configuration. Either way, keeping constants out of the grid leaves the Test Cases holding only meaningful variation.

A Fixed or Dynamic source applies to the entire Scenario. Every Test Case executes with the same configuration for that parameter, and the corresponding column in the Test Case grid becomes read-only.

The Input Parameter Configuration panel

The panel presents the full parameter configuration of the Scenario in one view. Open it from the toolbar icon in the Test Cases tab of the Scenario.

[Image placeholder: Input Parameter Configuration panel with steps expanded, From Test Case rows and overridden rows visible, and the source dropdown open showing the Data Driven, Fixed and Dynamic groups]

Parameters are grouped by the Scenario step they belong to. Each step header shows the step sequence number, the step name, the parameter count, and how many of its parameters are overridden. The panel footer summarizes the totals for the Scenario, for example 16 Parameters (05 overridden).

Reading the panel:

A parameter marked From Test Case is data-driven. This is the default state and needs no configuration.
An overridden parameter shows its source in a dropdown, alongside its configuration: the literal value, the selected Global Property or Run Property, or the linked parameter.

Changing a source:

For a data-driven parameter, hover over the row and click Change. For an overridden parameter, use its source dropdown directly.
Pick the source from the dropdown. Sources are grouped under Data Driven, Fixed and Dynamic as described above.
Complete the configuration for the chosen source, such as entering the literal value or selecting the property.
Click Update Configuration. Changes are not applied until you update, and ACCELQ presents a review of the change impact before applying (see the next section). Cancel discards all changes.

Selecting From Test Case in the dropdown returns an overridden parameter to the data-driven default.

Configuring a single parameter

When you are working with one specific parameter, the Parameter Configuration dialog offers the same choices for that parameter alone. Open it by clicking the parameter in a Scenario step in the Business Process view, or from the configuration icon in the parameter's column header in the Test Cases grid.

[Image placeholder: Parameter Configuration dialog for a single parameter, four options visible with Use Test Case values selected]

The dialog asks how the parameter gets its value during test execution:

Use Test Case values. The value is provided in the individual Test Cases defined for this Scenario. This is the default.
Use fixed value. A specific value used for all Test Cases, either a Global Property or a static value.
Get value from previous step (Parameter Linking). The value comes from a previous step, either an input to a step or a step output.
Ask for value at runtime. The value is requested when the test is kicked off, referred to as a Run Property, and used for all Test Cases.

These are the same sources as in the panel, phrased as choices. Click Update to apply, subject to the same change-impact review described below.

The All Parameters link at the bottom of the dialog opens the full Input Parameter Configuration panel, useful when one change leads to reviewing the rest of the Scenario.

Change impact when you update

Changing a parameter's source changes what the Test Case grid holds for it. Before applying your changes, ACCELQ shows a review of the impact so you can confirm with full knowledge of the consequences. Three kinds of impact can appear, individually or together.

Parameters will lose their values. When a parameter moves from Test Case to any other source, the values already entered for it in the Test Case grid are no longer used, and they are permanently deleted when you update. The review lists the affected parameters with their steps and states how many Test Cases are affected. You must acknowledge the deletion before the update proceeds. This deletion cannot be undone, so export your Test Case data first if you may need those values later.

[Image placeholder: Review changes before saving dialog listing parameters that will lose their values, with the acknowledgment checkbox]

Parameters now need values. When a parameter moves from another source to Test Case, it becomes data-driven, but no values exist for it yet. The review lists these parameters. After updating, add their values in the Test Cases grid. Until you do, executions run with empty values for these parameters.

All parameters become non-data-driven. If the update leaves no parameter sourcing from Test Case, the Scenario is no longer data-driven. All Test Cases are deleted, and the Scenario becomes a single non-data-driven test. This is the most consequential change and requires explicit acknowledgment. See Understanding Scenarios Not Eligible for Data-Driving for how such a Scenario behaves.

[Image placeholder: Review dialog for the case where all parameters become non-data-driven and all Test Cases are deleted]

Changes between two non-Test-Case sources, for example moving a parameter from Literal Value to Global Property, do not affect Test Case data and are applied without a data warning.

Behavior notes

Overrides are Scenario-wide. A Fixed or Dynamic source applies to every Test Case. It cannot be varied per Test Case; per-Test-Case variation is exactly what the Test Case source is for.
Grid columns become read-only. In the Test Case grid, the column of an overridden parameter is read-only. To change its value, change the parameter's configuration rather than editing cells.
Linking is backward-only. A Linked Parameter can reference input or output parameters of preceding steps only. A step cannot consume a value produced later in the flow.
Required parameters still need a complete configuration. An override without its configuration, such as Literal Value with no value entered, is not a valid state for a required parameter.