Browser Keep-Alive

Feature Availability: Version 4.2

When you are running a test job in ACCELQ, a new browser instance is created for every test case by default. This will ensure that every test case is always starting with a known initial state.

However, there may be occasions where you might want to keep re-using the same browser instance for all test cases in a job. This could be due to a specific functional reason on your test application or sometimes to improve execution performance. You might save a few seconds when you don't have to open a fresh browser for every test case.

ACCELQ allows you to opt for Browser Keep-Alive during a test job, so that same browser instance is re-used for all test cases in the job.

In the Run modal, click on the checkbox to enable Browser Keep-Alive. When you do so, a warning message is displayed to caution about possible impact on Action logic (see section below). Once the flag is set, it is saved in current user's preferences, and retained for subsequent runs.

Once set, a red dot on the browser icon indicates the Keep-Alive is turned ON.

Note: Use this feature sparingly, when there is a specific reason to do so. Opening a fresh browser instance for every test case is recommended, as it provides a clean starting point for a test case.

Make sure Action logic is resilient to handle browser keep-alive

When you design a Scenario or test case, it is important to ensure that the Scenario or test case is independently runnable without any expectation of other test cases executed before/after it. In other words, steps in Scenario should be self-sufficient, end-to-end. You should be able to run any arbitrary Scenario or test case independently.

When you are re-using the same browser instance across multiple test cases, there is a slight contradiction to this design principle. Lets clarify this with an example:

This Scenario logs in as given user to QBank and verifies if the account balance is correct. There are two test cases in the example above, to verify balance for two different users.

In the first test case, a new browser is opened and navigated to QBank. Login step is performed in the Login Page. In the Account Summary Page, account balance is verified for a given Account type.

Now when the 2nd test case is executed with the same browser being re-used, user is directly navigated to the Account Summary Page when the QBank URL is entered in the browser. Login step is not applicable as the application maintains the current login session.

Your Action logic must accommodate for this discrepancy. Here are the two things you need to do, for this specific example:

Do not include a synch point for the Login Page Context. This is because the Synch will fail in the Step #2 for the 2nd test case. Application is NOT going to be in the Login page after the browser init step for the 2nd and subsequent test cases.
Insert logic in Login Action to exit gracefully if you are already logged in. This can be done in many ways depending on your requirement. Here is a sample.

It is also possible that the one of the test cases in a long Scenario flow could have left the application in an inconsistent state. Ensure your Action logic accommodates such issues and subsequent test cases are not impacted because of this.

Impact on Synch Element for Context

In ACCELQ, a Context synchronization is performed implicitly even before an Action is executed. In the above example with the Login Action, a synch on QB Login Page is attempted even before the Login action starts to execute. But for the second and subsequent test cases, since the application is not really in the Login page, this synch will fail. Be sure to remove synch for the Contexts which are bypassed due to re-use of browser instance.

Handling browser crashes

In case the browser is closed in the automation logic, or if it crashes during one of the test cases, ACCELQ automatically invokes a fresh instance of browser for the next test case. Re-use flag will not impact this behavior.