Introduction

You will find some actions listed in ~~strikethrough~~ text on the Test Cases and Tasks screens. We recommend not to use these actions when developing a new test case as there are better options available now for the same operation. While these actions will continue to work in this release, they might be taken away in future releases with appropriate migration methods.

In reports also, you will find these actions in the strike-through text.

Following is the complete list of deprecated actions:

AnswerForNextDialog

We recommend using the WaitForAlertAndSendText action instead of this action. In WaitForAlertAndSendText, Qualitia gives you provision to set and send the desired string in the next pop up being displayed. This action gives you more control by its ability to provide timeout and polling interval for the expected condition to be achieved.

ClickandchooseOkOnNextConfirmation

Instead of using this action, you can divide this into 2 steps for better maintenance and control;

Click (based on the object class) and
WaitForAlertAndSpecifyBehavior.

The WaitForAlertAndSpecifyBehavior allows you specifying the action to be taken on the next Alert Box as a first parameter (accept or dismiss). This action gives you more control by its ability to provide timeout and polling interval for the expected condition to be achieved.

ClickLinkAtCellandchooseOkOnConfirmation

Instead of using this action, you can divide this into 2 steps;

ClickLink AtCell and
WaitForAlertAndSpecifyBehavior.

The WaitForAlertAndSpecifyBehavior allows you specifying the action to be taken on the next pop up window as a first parameter (accept or dismiss). This action gives you more control by its ability to provide timeout and polling interval for the expected condition to be achieved.

StoreSubString

This action should be replaced with StoreSubStringNew. This new action does not have any change in the functionality but you will have better control and consistency during the test case execution.

ClickAndWait

We strongly recommend not to use this action. Instead of using this action, we recommend you dividing it into 2 steps;

Click and
WaitForExistence or WaitForVisibility (based on the object class).

These actions give you more control by its ability to provide timeout and polling interval for the expected condition to be fulfilled.

You can also configure maximum wait time for the page to load using Page timeout (under Configuration Settings) or using the SetPageLoadTimeOut action

SelectItemAndWait

We strongly recommend not to use this action. Instead of using this action, we recommend you dividing it into 2 steps;

This action can be divided into 2 different steps for better performance and consistency:

SelectItems and
WaitForExistence or WaitForVisibility based on the next object you are going to operate on.

These actions give you more control by its ability to provide timeout and polling interval for the expected condition to be fulfilled.

WaitForPageToLoad

We strongly recommend not to use this action. Instead of using this action, we recommend using WaitForExistence or WaitForVisibility based on the next object you are going to operate on. Developing the test case this way gives you better control over your test case and help you find defects more effectively saving your time when debugging the test case.

Note:

For the WaitFor actions to complete successfully, the specified object must exist.
Only for all the Wait actions, you can override the actual execution result with that of your choice using the statusIfConditionNotSatisfied parameter. For example, if you set the statusIfConditionNotSatisfied parameter to Pass, the action execution result will always be Pass, irrespective of whether the actual execution result was Fail or Defect.

WaitForObject

We strongly recommend not to use this action. Replace this action with W aitForExistence. Using W aitForExistence gives you better control over the test case resulting consistent test case execution.