Challenge 07 - Waiting for page to be ready before running tests

What is the objective?

Just like a stage needs to be ready before the actors can perform in a play, an application page needs to be fully loaded before an automated step can execute on it.

Consider a simple example. When you are trying to log in to an application that is usually slow to load, automated steps to enter the username/password may not succeed if the steps are attempted too early. When logging into the site manually, we are implicitly "synchronizing" our actions with the page's loading status. But Automation requires explicit logic for this "synchronization" to apply.

Synchronization is the test automation concept that is applied to ensure that the application page is in a ready state before performing any operations on it. Lack of synchronization is a very common cause for poor test execution reliability.

In this challenge, we will apply the concept of synchronization on an application functionality that may suffer due to loading time issues.

The Scenario will

1. Log in to QBank
2. Navigate to the Notifications Page by clicking the bell icon in the Account Summary Page
3. Verify that the Notifications Page is fully loaded (by including a wait time in the test logic for the Page to load)
4. Navigate back to the Account Summary Page by clicking the Close button
5. Logout of Qbank

Here is the Scenario described in the video:

<INSERT VIDEO>

Automation Steps

Let us login to ACCELQ and create the required Scenario for this challenge.

Scenario, Contexts & Actions

For this challenge, we will use the top-down approach and start creating the Scenario straight away. New Actions or Contexts required, will be introduced as part of Scenario creation.

Create the Scenario called "Verify Notifications Page".

After invoking the browser, login to QBank. Create following Actions as part of the test steps setup.

1. Navigate To Notifications Page: Performed in "Account Summary Page" and leads to "Notifications Page".
2. Verify Notifications Page: Performed in "Notifications Page" and does not change the application state (Destination is "Current Context")

Your Scenario will look something like this once it is created:

Test Logic

Click on each of the new Actions (as indicated by the alert icon in the Scenario steps) and complete the logic.

Navigate To Notifications Page: In the available view, hover on the Bell icon (top-right corner), right-click and choose the "click a web element" command. 

Verify Notifications Page: In this Action, we will verify that the Notifications title is displayed. This Action is part of a newly created Context, "Notifications Page". Open the Views section and proceed to recording the View for the page.

You may have noticed that this page loads slowly on the application. If we try to perform the verification step right away, the test may fail as the page is still loading. So, let's start by inserting a statement for "synchronizing" on one of the elements on the screen. In this case, let's wait for the "Close" button to load fully.

• Hover on the "Close" button in the View and select the "Wait for Web Element" command.
• Next, hover on the "Notifications" title in the View and select the "Verify web element exists" command.

The logic should look like this:

More about "Wait" commands

All the "synchronization" or "wait" commands follow certain common semantic as described below:

1. Wait time: This allows you to define the maximum amount of time the tool should wait for the element to appear. If the element loads before this specified time, execution will immediately resume and does not wait for the full time. In the worst case, if the element is not loaded within this time period, failure-action will be invoked (as defined below).
2. Name of the element: This is the target element that you are waiting for or synchronizing on.
3. Failure action: In case the element is not found in the specified amount of time, this argument helps you specify the appropriate failure action to be performed. You can choose to just ignore, report an error or abort the current test case (and move to the next).

Run the Test

Once you run the test, click on the Verbose mode (Filter icon in the top-right of test result details) to notice that the Close button element was waited on, prior to the execution of the verification step.

Design Considerations

Here are some best practices when considering the element for synchronizing on:

1. Pick the right element: It is critical to pick the right elements for synchronization. You can choose an element that may typically be the last to load, or the one with functional importance to the Action (e.g., login button on the login page). Also, make sure the element is always displayed on the screen without any dependencies on the test flow.
2. Determine the right amount of time: Always be generous with the wait time you include in your logic to account for factors such as application performance and network bandwidth. Remember this is only the worst-case wait time, and not a static wait.
3. You can also select certain attributes of the page such as page text, title etc.

Alternate Ideas

A ready state for your application may be reflected by many things, and not just limited to the appearance of an element on the screen. For example, you may synchronize on conditions such as

• Element disappears
• Element property acquiring a value
• Element enabled/disabled
• Element CSS property (such as color, background, etc.)
• Some text appearing on a page