• Triage Efficiency: Supporting for Viewing Groups of Failed Tests while Triaging failed tests within a Test Cycle
  

  When you execute test cycles, many a time there are specific patterns for the failed tests, if any. The pattern usually involves the same error description, position of the failure (say at the same test instruction within the same test script), etc.To complete the triaging of the failed tests efficiently, this release offers you a new feature that lets us easily see the patterns or groups of failures within your test cycle's failed test runs.

  To make use of this powerful feature, just open the last accordion "Group and Sort Results By" and within the field "Group by", choose one of the following three options using which you can specify how you want the grouping to be done:

  • Same description and position for the first point of failure
  • Same description, script and instruction for the first point of failure
  • Same description but different position for the first point of failure
  
  Once you are done with specifying this and any other search criteria, perform your search.
  
  
  

  The search results will visually indicate the group number for each of the test runs.

  
  
  
  

  If you want you can also filter the tests to see only test runs from a subset of those groups. You can select one or more groups using the filter.

  
  
  
  

• Scheduling Feature: Support within Worksoft SaaS app for Configuration based Re-execution of Failed Tests
  

  This is a powerful feature that will allow you to specify a configuration based on which Worksoft SaaS will auto-determine the scope of tests for the re-execution. So far, you were able to do this using the QaCONNECT scheduling service. Now, you will be able to accomplish this efficiently from within the Worksoft SaaS application as well.

  To benefit from this feature for any test cycle within which you want to schedule the re-execution of some or all of the failed tests by specifying your configuration, just click on the actions menu for that test cycle, and click on the menu item "Re-execute Runs by Specifying a Configuration".




You can include some or all of the following criteria when specifying your configuration:

• Execution Statuses for Failed Tests: You can optionally remove from the configuration you are specifying a subset of the statuses with which the test runs that needed to be re-executed ended with. At least one status is required. By default all failure related statuses are included.


• Labels Attached to Failed Tests: You can optionally include in the configuration you are specifying a list of labels that can be used to determine the failed test runs that you want to be re-executed. For example, if you want all failed tests associated with specific labels within the root label “Application Modules”,  you can choose modules like "Shopping Cart", "Product Detail Page" for a storefront app in the eCommerce industry. You can include in your configuration child labels that are from more than one root label. For example, you can specify some child labels of ‘Application Modules’ and some child labels of ‘Root Cause of Failure” root label.


• Issues Linked to Failed Tests: You can optionally include in the configuration you are specifying a list of local Issues or issues in the external Issue Tracking System (if you have integrated your project with an external system like Atlassian Jira) that can be used to determine the failed test runs that you want to be re-executed. You can search for Jira issue keys or local store issue keys or issue descriptions and build your configuration.


• First Point of Failure Error Descriptions Linked to Failed Tests: You can optionally include in the configuration you are specifying a list of error descriptions for the first failed Instruction within your failed tests that can be used to determine the failed test runs that you want to be re-executed. Please note that you can specify more than one error description. If your error description is in the JSON format, you can use the premium editor to view the contents of the JSON properly formatted. After entering the error text, you must click on the green checkmark before you add another error description.


• Special Configurations: Optionally, you can also make use of these parameters as well.
  
  • Consider for re-execution only the originally scheduled runs in the test cycles. If you don’t check this off, both the tests auto re-executed by Worksoft SaaS ML as well as the manually re-executed tests will be considered for re-execution.
  • Consider for re-execution only the reportable runs in the test cycle. If you don’t check this off, both reportable and non-reportable failed runs are considered for re-execution.






Once you have completed building your configuration, click on the ‘Preview’ button. Worksoft SaaS will fetch the test runs that meet the configuration you specified and show you a count of the test runs that match your configuration. You will also have an option to view the test runs in a new tab by clicking on the 'open in a new tab' icon. You are strongly encouraged to review the test runs and ensure that your configuration is correct.





Once you are satisfied that your configuration is correct, you should checkoff the checkbox captioned “Using 'Preview Tests', I validated that my configuration yields correct tests for re-execution” which will enable the “Re-execute Tests” button for you. Click on that button and the failed tests that match the configuration you specified will be re-executed in bulk. It’s that easy!



• Delinking an Issue directly from the Issues Summary popover in the Test Runs Home screen
  

  You will now be able to delink an issue from the Issue Summary popover in the Test Runs home screen. This will allow users to quickly check the issues assigned to a test run and also give an option to delink from there itself.

  A delink icon is added to the top left of the cell in issue listing popup. Please note that If there’s a single issue key linked to a test run and you delink that issue you will be auto redirected to the test runs home screen.

  
  
  
  
• Worksoft SaaS Functional Cloud supports Video capture with Automatic enablement of Video Capture for Manual and Worksoft SaaS ML based Re-executions
  

  So far, video capture was not supported for tests that you execute on the headless and headful browsers on the Worksoft SaaS cloud for functional regression testing.

  With this release you will be able to optionally enable the capture of videos for tests executed on this cloud as well.

  
  
  

  The best practice, however, is not to enable video capture for all the tests in your test cycle that gets executed on the Worksoft SaaS cloud for functional regression testing because capturing video increases the test execution time by approximately 25%. Be selective on which tests you want video capture enabled.

  To support you in keeping your test execution windows small while giving you the power of being able to access the videos for faster debugging og failed tests, Worksoft SaaS will automatically enable the video capture for any test that is re-executed manually by a user or automatically by Worksoft SaaS ML, even if the testing context for those tests did NOT have the video enabled. Therefore, our strong recommendation is for you to not enable the video capture by default for all test runs at the time of scheduling your test cycles.

• Support for Microsoft Edge browsers in Functional Cloud
  

  In the Worksoft SaaS Functional Testing Cloud, so far, only Chrome and Firefox have been supported. Now, you can also execute tests on Microsoft Edge.

  When creating a testing context, you can select either version 100 or 99 of Edge and execute tests on those browsers.

  
  
  

Share your ideas – Help us improve Worksoft SaaS!

We could not have gotten Worksoft SaaS to where it is without some brilliant ideas from all of you. Keep the suggestions and ideas for improvement flowing!

To submit an idea or vote on some of the features requested by other customers, click here