A Scenario comprises a sequence of Steps, with some steps containing input parameters. These parameters act as placeholders for information necessary for the logic in the Action. Now, the Scenario has the responsibility to provide concrete values for these parameters.
By default, parameter values are supplied in test cases tagged for the given Scenario.
Data-driven testing with Test Cases
If the Scenario has at least one step parameter which is not overridden (described below), it is necessary to a create Test Case for the Scenario. A test case is just a collection of data necessary to fully execute the Scenario. You may create multiple test cases for a given Scenario to achieve data-driven testing.
You may create test cases in 3 different ways:
- Manually, by providing values for parameters
- Importing from an excel sheet.
- Generating test cases automatically, depending on the parameter types
When you run the Scenario, you are actually executing its test cases. In case a Scenario does not have any parameters, then by default, there is only one test case tagged for that Scenario.
You can find more information about test cases here.
Providing values for parameters through Test Cases is the most common approach. When you provide value for a parameter in a test case, you are data-driving that parameter. Each test case may specify a different value for this parameter. But for certain parameters in a Scenario, you may want to use a fixed value across all test cases. This is achieved using parameter overriding.
For example, consider the Scenario here for verifying employee records on an HRMS system. Here, the functionality of this test requires a login as an admin and verify records for multiple employees (defined in test cases). It is not necessary to change the admin user/password for every test case. You can simply override username and password parameters with fixed values.
To override a parameter, click on the parameter in the Scenario step. Multiple options are available to override a parameter.
Override with a static value
You can specify a fixed, literal value for the parameter. The example illustrated above uses a literal override for the username and password parameters for Step #2.
You may specify a Global Property for the parameter value. Remember Global Properties allow you to centrally manage test data while also permitting variable values across different application environments. Learn more about Global Properties.
The most common example for a Global Property override is for the application URL in the browser invoke step. You can find this in the example above for Step #1.
When you override a parameter with a Run Property, you can supply its value when the test is kicked off.
In some instances, you may not know a parameter's value until the test is actually kicked off. For example, if the application password is regularly updated and requires a password-of-the-day, you may override it with a Run Property so that this value can be conveniently supplied when the test is executed. Learn more about managing Run Properties here.
Another use case for Run Property overriding involves passing information across test cases when you are running a job that contains multiple test cases. This is described in the following section.
Link with another Parameter
It is a common occurrence that parameters in different steps of a Scenario may be interlinked. An output parameter from a step may be what you need to supply as an input parameter in a subsequent step. Similarly, input parameters required for multiple steps may be the same. You can conveniently link a parameter in a step with one of the input/output parameters of a preceding step.
For example, in the Scenario snippet below Employee ID is output from Step #3 and the same is linked as input for Step #4.
You can link with either an input or output parameter belonging to any step ahead of the current step.
Please sign in to leave a comment.