Execution Parameters for tagging test runs and defining test operating environment

Execution Parameters allow you to provide arbitrary configuration information when running tests. A Project Admin can define parameters relevant to the Project. User will supply this information when the test is kicked off.

You can use this information to build custom test logic or to categorize/tag your test runs. Examples could include "Target DB Instance" (which could indicate some kind of an application setup information used in writing test logic), "Release Number" etc. Manual test runs can benefit by the ability to filter runs based on these flags.

Creating Execution Parameters

• Login as Project Admin to the admin portal and navigate to Execution Parameters section
• You can create an Execution Parameter of various types:
  • Text
  • Date
  • Text Area
  • List
  • Boolean
  • User List
• You can also mark a parameter as mandatory or not.

Running a Test

When you are running tests in a Project with defined Execution Parameters, you will be required to furnish values for the parameters which are mandatory. These parameter values are then registered against the run to help with further downstream analysis.

Here is how the Run modal will appear.

Filter Results based on Execution Parameters

Test Results grid (both manual and automation) allows you to filter based on Execution parameter values. For example, you can filter all executions of Sanity Suite for Release 1.3.

Filter from Jira Plugin

When you are analyzing ACCELQ test coverage from Jira-Connect dashboard, you can filter the results based on Execution Parameters, so that only relevant set of results are displayed. You can target your analysis for test coverage and pass/fail against user stories for a specific release or sprint.

Building conditional test logic

You may use the value of an Execution Parameter to conditionalize Action logic. For example, consider an Execution Parameter called "Operating Brand". Logic in the screenshot builds different verifications based on the Operating Brand. This allows you to write portable test logic across multiple Operating Brands that your application supports, while providing for minor differences through conditional logic.