QMetry defines a Build as a specific iteration of the product/domain to be tested. The feature allows the tester to assign a "build" (aka patch, drop, or increment) to test suites/test cases that indicate the version of product being tested. It helps users track multiple builds of software more dynamically without having to add separate test suites with every new build.
Note: The build should be already added and associated to Release and Cycle, which are associated with the test execution. Read more about Managing Builds.
Build assignments are done at two levels:
Build can be assigned for the entire test suite. All the test cases in the test suite are executed on the build assigned at the test suite level. This option is available for customers having a Base package.
Different Builds can be assigned to the test cases in a single test suite. This option is available for customers who have opted for the customization package.
Users will have the following options:
Set Build selection mandatory in the project.
Set a Default Build for a release cycle combination.
Assign Build to the entire test suite.
Assign Build to individual test cases in the test suite.
These points are explained as below.
Note: Mandatory Build features will be visible only if you have purchased Customization package.
Note: Mandatory Build features will be visible only if you have purchased Customization package.
You can make the build selection mandatory for a given project. Make build mandatory works in accordance with Project Create and Modify rights. You can set the Make Build Selection Mandatory settings while creating a new project or while editing an existing project.
Use Case: The organization has hundreds of builds in multiple projects. If a tester does not mention the build number, it becomes difficult to track on which build the test was executed against after a few days. In such cases, QA Manager has the option to make the build selection mandatory while executing a test case.
Make Build selection mandatory during execution: This option is available on the Project create and edit screen (Projects > Project/Release/Cycle.). This will enforce Build selection on the Test Suite Execution Screen. Select the check box to make Build selection mandatory when test cases are being executed on the Execution Screen. The test execution will not be carried out without build selection.
Read here to make Build Selection mandatory for a project.
If you have enabled the Make Build selection mandatory during execution option in the Projects module, you can see the tip “Build is set as Mandatory during execution” on the Build grid (Projects > Builds).
If the Build Selection is mandatory in the project and no build is selected on the execution screen, the tester will see the following message.
QA Mangers can set a default build for a release & cycle combination so that test executions are auto assigned an intended build and testers do not have to set them manually. The tester will still have an option to set another build other than the Default Build for the execution.
When a Default Build is set for a release cycle
All new executions will be assigned to the Default Build. Default Build will override already set builds, but will not change any existing test executions.
If a new build is set using “Set Your Build“ option, which is different from the Default Build, the selected build would be valid only for that session. If you leave the execution screen or refresh, the selected build will be reset to Default Build.
When no Default Build is set for a release cycle
When executing test cases, if the tester sets a build, then the test case execution sets the executed build as the selected build.
The last build that was set for the test case always gets set as the executed build, if going forward build is not selected during execution.
When executing test cases, if the tester does not set a build then the test execution sets the executed build as None.
Set a Build as Default Build
Note: The Set Default option for default build configuration on Build Create and Edit screen will be visible only if you have purchased Customization package.
Note: The Set Default option for default build configuration on Build Create and Edit screen will be visible only if you have purchased Customization package.
With a customization package enabled,
For a given release cycle combination, only one build can be set as a default build.
Users can set default build for a release cycle combination while creating a new build or while editing an existing build.
Users having roles with the “Modify” build permissions, can set builds to default.
Refer to the following screenshot to understand the Current set build and last execution build.
When the Default Build is set, the Current Executed Build is auto-set as the default build.
When Default Build is Archived - the last execution build for the test suite will be set.
When Last Execution Build is Archived, with a default build present - Current Set Build and Last Execution Build changes to Default Build
When Default Build and Last Execution build are Archived - Current Set Build and Last Execution Build will be set to None.
The set default build for a release and cycle will be displayed at the test suite run level on the execution screen every time.
Build information: You can view the Set Default Build and last executed build to know which product/software version has been tested. Click on the information icon to expand the information of -
Current set build (i.e. set default build): The build set as default in the Build module. This is a test suite level build. You can change the build at the test suite level and the same is displayed as the Current set build until you refresh the execution screen.
Last execution build: The build set for test cases on the execution screen and on which the test case(s) are executed.
Use Case: QA Manager wants a default build for a combination of release/cycle, so that when test cases are executed against a release cycle combination and if the tester does not choose a build, they get executed against a default build. Tester is prompted for a confirmation that the execution will be done against a default build.
User can set only one default build for a single combination of Release & Cycle.
For example,
Build B1 is set as default build for release R1 and cycle C1.
Build B2 is also created in R1 and C1.
If the user tries to set build B2 as the default build, in that case, the earlier selection of default build (B1) will reset and the new build (B2) will be set as a default build for that Release & Cycle.
If the default build is set for particular release/cycle then this default build is set automatically at the time of adding the test run. A confirmation message pops up asking whether to continue the execution on the given default build.
Note: Bulk Execution performed on the Bulk Execute screen (Test Suite > Test Execution tab > Bulk Execute) is exempted from the application of default build. All the bulk executions from this screen will be performed on None build.
Create Build and Set it as Default
While creating a new build, the Set Default drop-down with Yes/No options is available to mark the build as default.
Set Default - Yes : The build will be set as a default build on the execution screen for the selected Release Cycle combination.
Testers do not need to remember and set the build manually every time. This also helps them to reduce build association errors.
QA Manager can always set the current build as a Default Build to ensure the executions are always associated to the current build.
Only one default build can be set for a given combination of a Release Cycle.
Set Default - No : Makes the Build as non-default. When some other build is set to default, this flag will be set to “No” for the previously default build.
Edit Build and Set it as Default
On the Edit Build screen, users can edit existing build data and also add new release and cycle with default build value in edit build screen.
While editing an existing build, the Set Default toggle option is available. Turn the toggle ‘On’ to mark the build as default for the Release and Cycle combination.
You can mark the build as default either while adding new Release(s) & Cycle(s) to the build. You can mark the build as default build for multiple combinations of Release(s) & Cycle(s) at a time.
You can mark the build as default after adding new Release & Cycle to the build.
You can view the Release(s) & Cycle(s) that are associated with the default build on the Build grid in Projects > Builds.
On Execution Screen -
When a Build is set as default and the user tries to change the execution status of the test case on the Execution Screen, the confirmation message pops up showing the default build on which the test case will be executed. To proceed with the default build click Yes. You can see the build on which the test case is executed in the Build Name column.
To execute the test case on other build, click No and change the build using the “Set Your Build” option for that test case.
When the customization package is not purchased, users can not set a build as default.
When executing test cases, if the tester sets a build, then the test case execution sets the executed build as the selected build.
The last build that was set for the test case always gets set as the executed build, if going forward build is not selected during execution.
When executing test cases, if the tester does not set a build then the test execution sets the execution build as None.
Below are the steps to assign the build to a test suite. Build assigned to a test suite will be applied to all the test cases under that test suite.
Steps
Click on the Set Your Build button at the right corner of the screen.
Open the Select Build drop-down and select the build you want the test cases to be executed against. This list contains all the builds that are linked to release and cycle, which are associated with the test execution that is being carried out.
Build will be assigned to the entire test suite if
All Test Cases are selected while selecting build OR
No Test Cases are selected while setting the build.
Users can assign build to a test cases irrespective of the build set for the test suite or other test cases in the test suite. Testers want to assign builds to individual test cases within a test suite so that they can associate different test cases with different builds.
If the execution status of a test case is changed, the change will be applied to the test suite run build (i.e. set as default). It will override the set test case run build.
Steps
Below are the steps to assign build to a test cases.
Click on the Set Your Build button at the right corner of the screen.
You can see that all the test cases are selected by default. Unselect the test cases to which you do not want to apply the build.
Open the Select Build drop-down and select the build you want the selected test cases to be executed against. This list contains all the builds that are linked to release and cycle, which are associated with the test execution that is being carried out.
The Build is set for those test cases that are selected while choosing the build.
After setting the build at Test Suite Level/Test Case Level, the confirmation pop-up opens as soon as you select the Build to link, confirming -
"Do you wish to reset execution status to "Not Run" for all Test Case(s)?"
Change without Resetting: It will assign the selected Build to test cases without changing their execution status.
Yes Reset: It will assign the selected Build to test cases and will reset the execution status of all the test cases to "Not Run".
You can opt either for resetting or not resetting the test case execution status.
The selected build will be set for the test run/for the selected test cases under it.
If you do not want to apply Build for the execution, then open the Build drop-down and just remove the Build selection. The Build selection will be removed after confirmation.
Build information: You can view the Set Default Build and last executed build to know which product/software version has been tested. Click on the information icon to expand the information of -
Current set build (i.e. set default build): The build set as default in the Build module. This is a test suite level build. You can change the build at test suite level and the same is displayed as Current set build until you refresh the execution screen.
Last executed build: The build set for test cases on the execution screen and on which the test case(s) are executed.
