Lesson 16 Topic 1 Features
This article is a part of the Self-paced Learning Series for the Course: First-Hand Experience of Worksoft SaaS.Please refer to the link for more details on the Course.
Introduction of Worksoft SaaS Feature/Concept :: Lesson 16 :: Topic 1
1. Test Cycles in Worksoft SaaS
A "Test Cycle" in Worksoft SaaS represents a collection of tests executed together to achieve your testing goal and 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 testing the word "Test Suite" is typically used for a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviors. In Worksoft SaaS "Test Cycle" is used for the same purpose i.e. a collection of tests cases executed to test the Application Under Test (AUT.) And "Test Cycle" in Worksoft SaaS has a significant role as various features like Analytics are designed around this.
Let's take a Use Case, where we want to schedule Regression/Functional Tests, a Test Cycle construct can be used to represent build verification tests, End-to-End integration tests, Cross-Browser/Device tests, etc within the Regression/Functional tests. A Company1 might use a Test Cycle to represent all testing across browsers for a build while Company 2 may have a Test Cycle defined for Sanity Tests and another for Regression tests etc. To drive this further another company, Company 3 may have different test cycles for Functional Testing & one Test Cycle for cross-browser testing.
Let's take another Use Case, where we want to schedule Performance Testing: Here, a Test Cycle construct can be used to represent tens of thousands of virtual users, (aka load testing), where each user represents a specific test within a small window of time OR it can also represent endurance testing, where all tests are done within a business day to cover all transactions that occur within your application(s).
In this way, when we use Test Cycles to organize our tests further, we can generate the analytical reports at a Test Cycle level which plays a critical role in analyzing the AUT behavior and responsiveness.
In the world of testing the word "Test Suite" is typically used for a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviors. In Worksoft SaaS "Test Cycle" is used for the same purpose i.e. a collection of tests cases executed to test the Application Under Test (AUT.) And "Test Cycle" in Worksoft SaaS has a significant role as various features like Analytics are designed around this.
Let's take a Use Case, where we want to schedule Regression/Functional Tests, a Test Cycle construct can be used to represent build verification tests, End-to-End integration tests, Cross-Browser/Device tests, etc within the Regression/Functional tests. A Company1 might use a Test Cycle to represent all testing across browsers for a build while Company 2 may have a Test Cycle defined for Sanity Tests and another for Regression tests etc. To drive this further another company, Company 3 may have different test cycles for Functional Testing & one Test Cycle for cross-browser testing.
Let's take another Use Case, where we want to schedule Performance Testing: Here, a Test Cycle construct can be used to represent tens of thousands of virtual users, (aka load testing), where each user represents a specific test within a small window of time OR it can also represent endurance testing, where all tests are done within a business day to cover all transactions that occur within your application(s).
In this way, when we use Test Cycles to organize our tests further, we can generate the analytical reports at a Test Cycle level which plays a critical role in analyzing the AUT behavior and responsiveness.
There are two ways in Worksoft SaaS to create a Test Cycle: -
- Manually using the Worksoft SaaS application
- Using QaCONNECT REST API (when you execute tests using Runner/Scheduler)
- Manually using the Worksoft SaaS application
- Using QaCONNECT REST API (when you execute tests using Runner/Scheduler)
Key attributes of the test cycle are:
a) Test Cycle Identifier b) Description c) Planned Start Time d) Planned End Time.
A data file is provided within the Test Scheduler to key in your inputs i.e. Test Cycle Identifier, Planned Start Time, etc.
Every Test Cycle needs a unique Identifier. Worksoft SaaS provides feasibility to decide the "Test Cycle Identifier" name. For Example, It can be named Smoke Testing, Functional/Regression Testing, Cross Browser testing, etc. If you are executing your smoke test after a "deployment/sprint release" you can also append the respective "sprint name or number" to the Test Cycle Identifier. Upon completion of the execution of tests, you can generate analytics for a test cycle to analyze and interpret results.
Every Test Cycle needs a unique Identifier. Worksoft SaaS provides feasibility to decide the "Test Cycle Identifier" name. For Example, It can be named Smoke Testing, Functional/Regression Testing, Cross Browser testing, etc. If you are executing your smoke test after a "deployment/sprint release" you can also append the respective "sprint name or number" to the Test Cycle Identifier. Upon completion of the execution of tests, you can generate analytics for a test cycle to analyze and interpret results.
In addition, you can get the following benefits by assigning the "Test Cycle Identifier":
- Email Notification with the statistics of all test runs executed. (It contains sum of all test runs executed, stats of test runs with statuses. Drill down from email notification to Worksoft SaaS Test Runs Home screen upon on clicking on the count of the Runs)
- Additional Search Parameter to search the test runs by "Test Cycle Identifier"
- Reports to executed test runs based on Test Cycle Identifier
Few additional points:
- Any number of automated Tests can be executed within a specific Test Cycle.
- A test run belongs at most to a single Test Cycle.
- You can concurrently have automated tests running in more than one Test Cycle if your project demands it.
- The Test Cycle Inputs datafile will have the following naming convention keyword: "Smoke Testing" appended by unique text: Timestamp in the format YYYYMMDDHHMM. For example, if you execute tests on 01-Jan-2020 05:05:05, then the test cycle identifier would be 2020010105050.
- Test Scheduler allows for scheduling tests to start executing immediately or at a specific time. If you want to schedule tests into the future, you can mention date & time in Test Cycle inputs datafile in planned start time and planned end time field.