How to Create Releases - Timeline & Fields Guide
Creating releases allows you to define project versions or milestones and organize test executions around them. Releases act as containers for executions and help structure your testing lifecycle in a controlled and traceable way.
This guide walks you through creating a release and configuring its fields before execution begins.
Creating a New Release
To create a new release:
- Click the Create Release button in the header
- Fill in the release details:
Title
A concise and descriptive name for the release (required).
Best practices
- Clearly identify the version, sprint, or milestone
- Keep it short and unambiguous
Examples
v2.1.0 – Feature ReleaseSprint 15 – AuthenticationQ4 2024 – Performance Improvements
Description
Rich text editor for detailed release context. You can:
- Format text (headings, bold, lists)
- Add links to documentation or tickets
- Insert code blocks
- Upload images and files
Use the description to capture
- Scope of the release
- Included features or fixes
- Testing goals and constraints
- Notes for testers and stakeholders
Start Date (Optional)
Planned start date for the release.
Used for:
- Timeline tracking
- Sorting and filtering
- Planning and visibility
Best practices
- Set when testing is expected to begin
- Update if timelines change
End Date (Optional)
Planned completion date for the release.
Used for:
- Deadline tracking
- Schedule visibility
- Reporting
Date indicators
- Red → Date is in the past
- Blue → Today or future
- Gray → Not set
Custom Fields
If your project has custom fields configured for releases, they will appear here.
Common examples:
- Release Type (Feature, Hotfix, Patch)
- Priority
- Target Environment
- Owning Team
- External References
Fill values based on field type:
- Text
- Dropdown
- Checkbox
- Date
Fields marked as required must be completed before saving.
Attachments
Attach supporting material such as:
- Release notes
- Specifications
- Design documents
- Screenshots or diagrams
How to add
- Click the attachment area or drag & drop files
- Files upload automatically
- Add captions for images when needed
Making a Release Executable
To enable test executions:
- Open the release
- Click Change Status
- Select one of the executable statuses:
- Not Started – Executions allowed with warning
- In Progress – Executions fully allowed
Execution behavior depends entirely on release status.
👉 See Release Statuses & Execution Rules for full details.
Best Practices
Release Planning
- Create releases before executions begin
- Clearly define scope and objectives
- Keep timelines realistic
- Use descriptions as the single source of truth
Naming Conventions
- Use consistent naming patterns
- Include version numbers or sprint identifiers
- Avoid vague titles like “Test Release”
Timeline Management
- Treat dates as planning tools, not hard locks
- Update dates when plans shift
- Leave dates empty if unknown
Documentation
- Capture context in descriptions
- Attach key reference files
- Avoid relying on external-only documentation
Common Use Cases
Version-Based Release
- Create release with version number
- Add scope and changelog
- Set timeline
- Move to In Progress
- Execute multiple test runs
Sprint-Based Release
- Create release for sprint
- Set sprint dates
- Document sprint goals
- Execute sanity, regression, and smoke runs
- Complete or archive after sprint ends
Milestone Release
- Create milestone release
- Attach planning documents
- Track execution progress over time
- Use for reporting and audits
Next Steps
- Learn how to Manage Releases
- Understand Executions in Releases
- Learn about Reports & Export