Cross-browser Testing

Cross-browser testing means executing the same test across multiple browsers. This can reduce maintenance and improve coverage, but it also requires extra care with browser-specific UI differences, dynamic identifiers, timing, and input behaviors. This tutorial walks through an end-to-end example.

Use Ranorex Studio to automate the same Dropbox sign-in flow on three browsers (using a single test):

• Microsoft Internet Explorer
• Google Chrome
• Mozilla Firefox

To demonstrate the workflow, this example uses a free Dropbox account. Dropbox is a registered trademark of Dropbox, Inc. and Dropbox International Unlimited Company. Their terms of service and privacy policy apply. Ranorex GmbH, Ranorex, Inc., and Dropbox, Inc. are not affiliated in any way.

Note: You must create and use your own free Dropbox account for this tutorial.

What the test does

Start

1. Start the browser and go to the URL www.dropbox.com
2. Click Sign in to reach the sign-in page.
3. Enter your e-mail address and password.
4. Uncheck the option Remember me.
5. Click Sign in.
   

Check account 

1. Click the account picture to open the account menu.
2. Check if the displayed account name is the same as that of our fictional person (John Public, in our case).
   

Log out

1. Click the account picture to open the account menu (if it isn’t still open).
2. Click Sign out.
   

To get started, first, create a new web test as explained in Build a web test and keep the following in mind:

1. Name the solution something meaningful (for example, CrossBrowserTest).

2. Use www.dropbox.com as the start URL.

3. In the wizard, you can select only one browser and choose Firefox for the initial recording. You’ll add the other browsers later.

4. For recording behavior, select Add browsers to whitelist.

5. Click Finish.

Record your test on a single browser first, then adapt it for cross-browser runs.

If you didn’t configure the wizard to start browsers automatically:

1. Start Firefox.

2. Go to www.dropbox.com.

1. Open the Recording1 module and click RECORD.

2. Click Sign in.

3. Enter your email address and password.

4. Clear Remember me.

5. Click Sign in.

6. Wait for the page to load, then click the account picture.

Validation

Validate that the account name matches the expected user.

1. In the Recorder control panel, click Validate.

2. Hover over the account name in the account menu until the purple highlight appears, then click to select it.
   

3. Confirm the correct UI element is selected and click Next.

4. In the validation settings:

   • Ensure Exists is checked.

   • Ensure InnerText (with the account name) is checked.

5. Click OK
   

Finish the recording

1. In the open account menu, click Sign out.

2. Click Stop in the Recorder control panel.

Result

After stopping the recording, you’ll be returned to Ranorex Studio, with the resulting recording being displayed. Let’s take a look at this initial version of our cross-browser test.

1. Action table showing 11 actions (your recording may differ slightly in the number of actions).
2. A repository with 8 repository items organized into two folders.

Before we start turning the test into a cross-browser test, you should optimize it.

Combine key sequences

Sometimes Ranorex Studio will split key sequences. This can happen because the sequence wasn’t entered fast enough, for example. You should combine key sequences wherever it makes sense.

1. Select the key sequences you want to combine and open the context menu.
2. Click Merge selected keyboard items.
   

Optimize key sequence content

Special characters sometimes produce messy key sequences. Replace them with the correct literal characters (for example, replacing extra keypresses with @ where appropriate).

1. Unoptimized
2. Optimized

Find and replace dynamic identifiers

Many applications contain so-called dynamic UI elements. These change whenever a particular event happens, e.g. when you reload a web page. It’s often harder for automated testing tools to find these UI elements reliably. This is because identifiers that are robust for static UI elements (like the element ID) change all the time for dynamic UI elements. This is why you need to fall back on other identifiers for dynamic UI elements.

For web elements, Ranorex Studio uses an intelligent algorithm that recognizes when a UI element is dynamic. It ignores dynamic identifiers and uses a robust, static identifier instead. This means you should normally not need to find and replace dynamic identifiers from your repository items. However, in some cases, a dynamic identifier may be missed and you’ll have to replace it by hand.

Dynamic identifiers usually appear in the RanoreXPath with a name prefix and a long character string that changes whenever the element is loaded (see paths marked in red in the image).

Reference: Replacing dynamic identifiers with more robust ones is explained in Mapping dynamic UI-Elements.

In this example, the improved repository looks like this:

Empty text fields

In automated testing, it’s a good idea to make sure text fields are empty before something is entered in them.

The four actions in the image represent entering the e-mail address into the text field represented by the repository item LoginEmail.

1. Click into the text field.
2. Press Ctrl + A to select any existing text in the field.
3. Press Delete to delete the text.
4. Enter the e-mail address.

If the text field is already empty, actions 2 and 3 won’t have any effect. The test will continue without issue. Alternatively, you can also use the Set value action to replace all of these four actions or just the actions for emptying the text field.

Structure your test

Your tests should always be well-structured. This is why you should organize your actions into various recording modules and structure them in the test suite.

Reference: Organizing recording modules is described in Manage recording modules. Structuring test suites is explained in Test suite structure.

In this example, organize the recorded actions into the following modules and structure the test suite as seen below:

1. Setup region containing the module for starting the browser and opening the URL.
2. Four recording modules to go to the sign-in page, sign in to Dropbox, check the account, and log out.
3. Teardown region containing the module for closing the browser.

Cross-browser execution in Ranorex is typically implemented with variables + data binding.

Make the browser type a variable

As a first step, you need to replace the fixed browser in our OpenBrowser.rxrec module with a variable. This variable takes on the different browsers as values during the test run.

1. Open your OpenBrowser.rxrec module (or equivalent).
2. In the action where the browser is selected, open the Browser property drop-down.
3. Click As new variable…
4. Name it (for example, selectBrowser) and click OK.
   

Create the data source containing the browsers

In this step, we’ll create a data source to provide values to the browser type variable.

1. Open the context menu of the test case in the test suite view.
2. Click Data source…
   
    
3. Name it (for example, BrowserList)
4. Create a column (for example, Browser)
5. Add one row per browser, for example:
   • Firefox
   • Chrome
   • Internet Explorer
6. Click OK.
   

Reference: Creating data sources is explained in Data and data management.

Binding the data to the variable

1. Open the context menu of the test case in the test suite view.
2. Click Data binding…
   
3. Under Variable binding > Module variable, select OpenBrowser.selectBrowser
4. Bind it to the Browser column in BrowserList
5. Click OK.
   

The final cross-browser tests should look as follows in the test suite:

1. Test suite structure with a test case containing setup/teardown regions and modules.
2. The test case contains a data source called BrowserList with 3 rows of data.
3. The module OpenBrowser contains one variable that is bound to a data source.

Results

After the test run, the report should look as follows:

1. Three test cases were completed successfully.
2. Our single test case was iterated three times, once for each row in the data source, i.e. once for each browser. Hence, three successful test cases.

Bringing up the details of the OpenBrowser module for an iteration shows the value passed to the variable: