Parameter Configuration for Manual Scenario – ACCELQ

Parameterization multiplies your testing outcome by abstracting out the test data from the actual test steps. A given Scenario can be exercised across multiple test data combinations without rewriting and duplicating the test steps.

ACCELQ takes Parameterization capability to the next level by allowing you to configure acceptable values for the parameters, there by guiding the user with valid values for inputs and facilitating automated test case generation.

Configuring a parameter may involve defining what values the parameter can accept, associating with the AUT environment etc. This article explains various capabilities with examples and the rationale from test design point of view.

Parameterization Example

Consider the following manual test Scenario with parameters for User Name, Password, Origin, Destination, Date of Journey and No of passengers.

When a user defines a Test Case, they can enter any valid values for these 6 parameters, as in the screenshot below.

Configuring Parameters

Click on the Configuration icon in the toolbar area of the Scenario.

This displays list of parameters in the Scenario and allows configuring each parameter. Following options are available against each parameter for configuration:

Supply Parameter Values sensitive to Application Environment

Let's consider that you want to use a fixed User Name and Password for all the test cases in this example. However, these credentials may be sensitive to the Application Environment where the test is run.

You can define 2 Global Properties and mark them as sensitive to App Environment. You use these two properties and configure User Name and Password parameters. When you do this, every individual test case does not need to supply values for these parameters. Appropriate values are picked at the time of test run based on the Application Environment where the test is started on.

Supply Parameter value during test execution

There may be information which is sometimes not available until the time test is running. In our example Scenario, let's assume we want to use the same Passenger count for all test cases, but the actual code keeps changing from time to time. You can not give a specific value in the test cases and the value is time sensitive.

You can mark such parameters for Run Properties and supply the actual value of Passenger count at the time test is running.

Restricting Parameter Values

In the example above, each parameter can only accept a set of known values. In the case of Origin and Destination, it should be a valid Airport code and for the Service Class, it has to be one from the given list: {Economy, Business and First}.

Airport Code and Service Class list can be defined as a Data List.

Adding a Test Case

Now, with properly configured Parameters, a new Test Case will look something like this.

User Name and Password are fixed to Global Properties
No of Passengers is tied to Run Property
Origin, Destination are pointing to Airport Code Data List
Service Class is pointing to a Data List, Class of Service