Selecting a Build When Creating a Test Plan
When you create a new test plan (or edit an existing one), you see a Build field:
Click the Build dropdown to see all available builds in your project
Builds are shown with their version and environment, e.g., "v2.14.1 (Production)"
Select one, or leave it blank to not link a build
Click elsewhere or tab to the next field
The build field is optional; not all test plans need to be linked to a build.
Release Auto-Population
When Releases are enabled in your project, there's also a Release field below the Build field. Here's the smart part:
If you select a build that belongs to a release, the Release field automatically fills in with that release.
For example:
You select Build v2.14.1
v2.14.1 belongs to Release 2.14 (via pattern matching)
The Release field automatically populates with "Release 2.14"
You can change or clear it before saving if you want a different release
This saves you from selecting the build and then having to manually find and select the matching release. It's automatic.
When Build and Release Disagree
If you:
Select Build v2.14.1 (which belongs to Release 2.14)
Then manually change the Release field to Release 2.15
Editing a Test Plan
When you edit a test plan, the Build and Release fields work the same way:
The form pre-fills with the current build and release
You can change the build
If you do, the release auto-populates (if the new build has one)
You can override the auto-populated release if needed
Viewing the Build on a Test Plan's Summary Page
After creating or editing a test plan with a build, open the test plan and click the Summary tab. You'll see a blue chip showing the build's version, e.g., "v2.14.1". Click the chip to jump to the build's detail page.
This provides quick navigation from testing back to the software version.
Build Column in Execution History
The Execution History tab shows every time the test plan has been run. A new column shows which Build the plan was linked to at the time each run happened.
The build shown for each execution is whatever the test plan's build was at the time the run happened. If you later change the test plan's build to a newer version, the execution history still shows the original build each run was against.
Important: One Plan, One Build
Unlike execution history (which shows many runs), a test plan can be linked to only one build at a time. If you need to test the same test plan against multiple builds (for example, testing v2.14.0 and then v2.14.1), you have options:
Create new RUN and update the plan - after a new RUN is added and tests executed the logs will show the relevant build for the RUN
Create separate plans - duplicate the test plan for each build
Update the plan - change the plan's build to the new version before running it again
When you update an existing plan's build and run it again, the execution history captures both runs with their respective builds.
Related Articles
Creating Test Plans - Complete guide to creating and managing test plans
Understanding Builds and Releases - Overview of builds and releases and how they work together
Grouping Builds Under a Release - How builds are grouped into releases via version patterns