Skip to content

Lesson 10 Topic 7 Features

← Worksoft SaaS Self Paced Learning - FHE - Supporting Articles 
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 10 :: Topic 7

1. Executing Test in Local Browser
QaSCRIBE can be used to execute tests in your local browser - Chrome or Firefox. It comes in handy when you want to check if the functionality of the Test Script you built, is working as expected.   

For example, Let's say you have created/recorded a new Test Script and want to do a quick test using the playback button OR you made some changes to the Test Script as a part of Application changes. In this case, performing a Unit testing, which means, executing a single Test Script or a single instruction within a Test Script or selected instructions within a Test Script is not feasible in the cloud. 

QaSCRIBE provides advanced Toggle options that enable us to perform such Unit tests on the local browser. While most of the functionality that is available in Cloud execution, is available in the local browser execution, there are certain features that are not available. For example, assets like screenshots & videos and Analytics are not available.

Also, when executing tests using the local browser, Worksoft SaaS will not check for the "Concurrency" and "Capacity" and hence you don't have to wait for concurrency to free up or worry about the capacity.

2. Execute (play) this test script stand-alone
One of the execution options available in QaSCRIBE is executing a Test Script as standalone. This is useful in cases where you want to check if the functionality of the Test Script you built is working as expected.

For executing standalone test scripts, it's important to ensure that the state of the AUT corresponds to the state expected by the test script. For example: In an e-commerce application, If you want to execute a Test Script that has instructions to add items to the cart, it is important to ensure that you have manually logged in to the AUT and performed the prerequisite steps so that the Test Script can perform the action successfully.

After you assemble Test Scripts into Scenarios or Run Definitions, you can use the other execution options available in QaSCRIBE i.e. executing a test script along with other test scripts in the context of a scenario or run definition 

3. Adjusting the play speed
When performing local executions, there is a play speed available where you can adjust the speed of the executions based on your requirements, provided if your Project Lead has not restricted your access in the Project Settings.

For example: If you want to carefully monitor the execution of your tests or need to debug, then you can slow it down by dragging the play speed to 5 secs (or more) and if you want to speed up your execution, drag the play speed to 0 secs. Basically the play speed determines the lag between executing two consecutive instructions. Bigger the number, more the lag you see between the two instructions being executed. 

4. Execution Log of Local Execution
The Execution Results are similar to the Cloud Execution Results where the Execution Status and Time are displayed along with the no. of Instructions, Test Scripts and Scenarios executed. For local executions, we also have the ability to seamlessly switch between the 'design & build' and 'execute & debug' tabs.

If any of you have used Selenium IDE, you would have relied on the "Log" to view/review results. The same is available as "Execution Log" in Worksoft SaaS, but most or all of this information is available the in Results grid itself.

5. Difference between Cloud execution and Local execution
So far, we have experienced both Local executions using QaSCRIBE and Cloud executions. It's important to understand that these two features are built to address different needs.
  • Local executions are necessary and come handy when you perform test automation & maintenance and in some instances debugging of test failures
  • Cloud executions are used for performing regular testing (regression & sanity) on the AUT.
A note of caution here, while executing tests in the local browser is supported in Worksoft SaaS, the expectation is that it is used in the context of test automation, maintenance & debugging and not used for regular testing of AUT. For long-running tests, there is a tendency of browsers becoming unstable/unresponsive when you perform tests in the local browser. In addition to that, you would miss out on features like Assets (like Screenshots, videos, etc.) and more importantly Analytics. The Run ID that's generated in the instance of a local execution cannot be used for future reference as well given Worksoft SaaS DOES not retain the execution results. Hence you are discouraged from the practice of executing regular test cycles in a local browser.


Feedback and Knowledge Base

(thinking…)