#Test Executions in Releases – How They Work
Executions represent actual test execution sessions performed as part of a release. They allow teams to run, track, and analyze test cases multiple times throughout a release lifecycle.
Executions always belong to a release and cannot exist independently.
#What Are Executions?
Executions are release-scoped test execution sessions.
Key characteristics:
- Each execution belongs to exactly one release
- A release can have multiple executions
- Executions track:
- Test case status
- Assignee
- Execution progress
- Results history
Executions are used to validate the state of a release at different points in time.
#When Can Executions Be Created?
Execution creation and execution depend entirely on the release status.
#Executable Release States
| Release Status | Execution Allowed | Behavior |
|---|
| In Progress | ✅ Yes | Full access, no warnings |
| Not Started | ⚠️ Yes | Warning shown before execution |
#Non-Executable Release States
| Release Status | Execution Allowed |
|---|
| Draft | ❌ No |
| Paused | ❌ No |
| Completed | ❌ No |
| Archived | ❌ No |
⚠️ If a release status changes to a non-executable state, all execution actions are immediately blocked.
#Creating an Execution
- Open the release details page
- Click Add Execution
- Provide execution details:
- Title (required)
- Description (optional)
- Select test cases using one or more sources:
- Manual selection
- Requirements
- Test suites
- Click Create
#Selecting Test Cases for an Execution
Executions support multiple sources for test case selection.
-
Manual Selection
Select individual test cases explicitly.
-
Requirements
Include all test cases linked to a requirement.
-
Test Suites
Include all test cases defined in a test suite.
Multiple sources can be combined, and duplicate test cases are automatically deduplicated.
#Execution View & Progress
#Execution List
Each execution displays:
- Execution title and description
- Overall progress summary
- Status distribution
- Total test case count
#Test Case Statuses
Within an execution, each test case can be marked as:
- Passed
- Failed
- Blocked
- Skipped
- Not Executed
These statuses are execution-specific and do not affect the test case definition.
#Working Inside an Execution
Inside an execution, users can:
- Assign test cases
- Update execution status per test case
- Filter and search execution test cases
- Track progress in real time
Execution progress updates immediately as results are recorded.
#Multiple Executions per Release
Releases often require more than one execution.
Common scenarios:
- Sanity execution
- Regression execution
- Smoke execution
- Final validation execution
Each execution captures a snapshot of testing results at that moment in the release lifecycle.
#Execution Lifecycle
Typical execution flow:
- Create execution
- Select test cases
- Execute tests
- Record results
- Monitor progress
- Complete execution
- Analyze results
Executions remain available for historical analysis even after completion.
#Important Rules to Remember
- Executions cannot exist outside releases
- Executions cannot move between releases
- Execution availability changes immediately with release status
- Completed or archived releases permanently block executions
- Test executions are independent of standalone test runs
#Best Practices
- Use multiple executions instead of reusing one
- Name executions clearly (e.g., “Regression – Build 42”)
- Keep executions small and focused
- Pause releases instead of partially executing tests
- Archive releases to keep active views clean
#Next Steps