Documentation
Pricing
Sign in
Sign up
 

Targets

Tesults helps you consolidate test results data from across your test jobs. A target maps one to one with a test job and is essentially a 'bucket' for you to upload results data to. A project can have one or many targets.

A target just like a test job corresponds to a set of test run properties, for example:

  • Build flavours - Debug, Profile, Release
  • Environments - Development, Staging, UAT, QA, Production
  • Branches - Main, Feature X, Demo
  • Platforms/OS - Windows, macOS, Linux, iOS, Android
  • Browsers - Chrome, Safari, Firefox, Edge
  • Devices - iPhone 11, Samsung Galaxy S9, Playstation 4, Xbox One
  • Types of tests - Unit, Integration, System, Performance, Load, End-to-end

In order to have test results history and comparisons between different test runs make sense it is important to upload test results to the right target. The name of your targets is entirely up to you and what makes sense for your project. You might create a target called 'Debug', or perhaps combine various properties together such as 'Debug-Windows-Main Branch', and perhaps another called 'Release-Windows-Main Branch' etc.

No matter what platforms, build flavors, or branches you have for your project, targets allow you to upload test results in groups that makes sense for your project and team.

Examples

Example 1

'Team A' is responsible for developing a web application that has a web front-end and a REST back-end. They run UI automated tests for the front-end and API tests for the back-end and run the tests in just one 'test' environment. They will need 2 targets:

  1. Front-end
  2. Back-end

Example 2

'Team B' works on a mobile app that runs on iOS and Android devices. They have dev and staging environments setup as part of their workflow and run automated tests against both environments and apps. They will require 4 targets:

  1. iOS-dev
  2. iOS-staging
  3. Android-dev
  4. Android-staging

Example 3

'Team C' works on a web app and two mobile apps for iOS and Android devices. These apps depend upon three services that provide APIs (A, B, C). They have dev and staging environments setup as part of their workflow and run automated tests against both environments and all apps and services. They will need 12 targets:

  1. iOS-dev
  2. iOS-staging
  3. Android-dev
  4. Android-staging
  5. Web-dev
  6. Web-staging
  7. API-Service-A-dev
  8. API-Service-A-staging
  9. API-Service-B-dev
  10. API-Service-B-staging
  11. API-Service-C-dev
  12. API-Service-C-staging

Example 4

'Team D' runs automated tests for their video app on web (browser), iOS, Android, Playstation 4 and Xbox One in 'dev' and 'staging' environments. These apps are supported by 5 services (A, B, C, D, E) that provide the APIs the clients use. All apps and services have automated tests setup and are tested in both environments as part of their continuous integration. They will need 20 targets:

  1. Web-dev
  2. Web-staging
  3. iOS-dev
  4. iOS-staging
  5. Android-dev
  6. Android-staging
  7. Playstation4-dev
  8. Playstation4-staging
  9. XboxOne-dev
  10. XboxOne-staging
  11. API-Service-A-dev
  12. API-Service-A-staging
  13. API-Service-B-dev
  14. API-Service-B-staging
  15. API-Service-C-dev
  16. API-Service-C-staging
  17. API-Service-D-dev
  18. API-Service-D-staging
  19. API-Service-E-dev
  20. API-Service-E-staging

In general, the number of the targets you need corresponds to the number of 'test jobs' or 'test pipelines' you have. Do not push all results data to just one or a lower number of targets than you need because you will not benefit from any of the analysis Tesults automatically does around historical trends, regression, failure task tracking, notifications, stats and supplemental analysis. In order for analysis to take place correctly on each test run the data must be comparable and this only makes sense within the context of appropriately utilized targets.

You can create an unlimited number of targets on Standard and Plus plans.