Best practices to handle multiple build versions in UiPath Test Manager and differentiate execution results

Hi Community,

I’m working on setting up an automation testing framework using UiPath Test Manager, and I would like guidance on handling multiple application build versions during testing.

Specifically, I’m looking to understand:

  1. What is the recommended approach to manage and track multiple build versions in Test Manager?
  2. How can we differentiate test executions and reports for each build (for example, Build v1.2 vs v1.3)?
  3. In a large or complex project, how can this be designed so that build handling remains simple, scalable, and easy to maintain?

Any best practices, real-world examples, or documentation references would be greatly appreciated.

Thanks

hi @Trisha_Manivannan,

Recommended approach for multiple build versions in Test Manager:

  1. Create separate Test Sets per build (e.g., “Build_v1.2_Smoke”, “Build_v1.3_Regression”)​

  2. Link test cases to specific package versions:

When creating test sets, manually select package version (v1.2.*) instead of “Autoselect packages”
Execution results automatically show package version + test set name​

  1. Differentiate reports:
Test Results → Filter by Test Set Name
Shows: Build v1.2 vs v1.3 pass rates side-by-side
  1. Scale for large projects:
Orchestrator Folders per build → 
Publish tagged packages → 
Test Sets per folder → 
CI/CD pipeline triggers

Key: Test Sets = your build version boundary. Results auto-group by test set + package version.

This gives clean v1.2 vs v1.3 comparison without overlap.

Hi @Trisha_Manivannan

In Test Manager, create a separate release or build version for each application version (like v1.2, v1.3). When executing tests, select the correct build so results and reports are linked. Use consistent naming, keep build-specific test data separate, and always create a new build entry before running tests to maintain traceability.