Skip to content

What is a Test Cycle?

← Managing Test Cycles

Before you read this you may want to see:

Main Article


A "Test Cycle" in Worksoft SaaS represents a collection of tests that are executed to achieve a testing goal that you have to assure the quality (in functional/regression testing) or the scalability/reliability under stress/load (in performance testing) of your application(s).

In the world of manual testing, “Test Suite” is a term that is typically used to categorize your manual test cases in such a way that they match your planning and analysis needs. The Worksoft SaaS construct ’Test Cycle’ can be used to map to the ‘Test Suites’ that you may have defined in the context of your manual test cases. However, that is not the only context in which you can use the Worksoft SaaS construct of the Test Cycle.

In Worksoft SaaS, a 'Test Cycle' is identified with the graphical icon: 

Use Case #1 - Functional/Regression Testing


In this context, a Test Cycle construct can be used to represent any/all of the following types of tests:

  • Build verification tests: A collection of tests that perform basic validation of the critical functional areas of your application(s)/product(s). The tests are executed after each application build and before the build is promoted for use by a larger audience.

  • Smoke tests: A collection of tests that ensure basic/core application/product functionality. Typically, smoke tests are the first level of testing that is performed after changes are made to the system under test.

  • End-to-End integration tests: A collection of tests that cross-application/product/module boundaries and ensure that the integration points between applications/products/modules are exercised and validated.

  • Functional verification tests: A collection of tests that focus on a specific application/product function. Executing this type of test with a test suite ensures that several aspects of a specific feature are tested.

  • Regression tests: A collection of tests that are used to assess if there are any regression bugs introduced within critical functional product/application areas.

  • Cross-Browser/-Device tests: A collection of tests that are used to assess (usually) if a subset of your functional/regression tests works well across combinations of browsers, operating systems, and devices/device types.

Some use a Test Cycle to represent all tests that get performed in the context of assessing the quality of a single build for their applications. For some others, a Test Cycle represents all tests executed to assess the quality of their application for a specific release/sprint/iteration across builds of their application. For some others, a Test Cycle could represent all tests executed to assess the quality of a subset of functionality/features within their application(s) (for example, Release Sanity or Smoke Tests) to determine if additional test cycles can be executed at a later time.

Reporting considerations play a critical role:

In Worksoft SaaS, Test Cycle plays a critical role in determining the level at which analytical reports are generated. While Worksoft SaaS does not impose any restrictions on how you should or should not use its Test Cycle construct within your automation projects, you should take reporting into consideration in determining if you have to create a separate Test Cycle for a collection of tests that you execute within your project.


Build Identifier from your CI Tool can be your Test Cycle Identifier in Worksoft SaaS:

If you use a separate test cycle for each 'build' of your application, then you can set the Test Cycle name to be the unique identifier for your build. If your test cycle is at an application build level, depending on the CI tool you are using, you can pass as "Test Cycle Identifier" one (or combination) of the following CI tool environmental variables (Or for that matter any value that uniquely identifies a build for your Project).

  • Bamboo: buildNumber, buildkey, jobName, jobKey, buildDatetime.

  • Jenkins: BUILD_NUMBER, BUILD_ID, BUILD_TAG, JOB_NAME

Use Case #2 - Performance Testing


In this context, a Test Cycle represents tens of thousands of virtual users each of whom represents a specific test within a small window of time (aka load testing) OR all tests were done within a business day to cover all transactions that occur within your application(s) (aka endurance testing).


After you read this article you may want to see:

Feedback and Knowledge Base

(thinking…)