Home Test Automation TestArchitect Corner: How To Perform Cross-Browser Automated Testing

TestArchitect Corner: How To Perform Cross-Browser Automated Testing

Cross-Browser Testing is an integral part of the Software Testing world today. When we need to test the functionality of a website or web application, we need to do so on multiple browsers for a multitude of reasons.

The most apparent reason is obviously the fact that end users may be using different operating systems to access the website or web application; at this point of the internet, it would be crass to assume that all users are using Internet Explorer or AOL. Not only could they be using different browsers entirely, but you also must take into account the different versions of browsers: one user could be using Chrome 6.3.5 while another could be using Chrome 1.1.1!

Another measure that Cross-Browser Testing takes into account is the performance of the website or web application on each individual browser as it relates to user experience. Performing a cross-browser load test would verify which browser is more efficient and take that information into account for code writing and edits.

Ultimately, there’s no getting around it: you’re most likely going to need to perform Cross-Browser Testing—so why not automate it? This installment of TestArchitect Corner explores an example user case in which you will learn how to utilize TestArchitect to implement automated Cross-Browser Testing.

User Case 

Suppose that you need to test on different web browsers: Internet Explorer, Mozilla Firefox, Google Chrome, Edge, and Safari. You may find yourself asking 2 questions:   

  • Do I need different interface definitions for Internet Explorer, Firefox, Chrome, Edge, and Safari?
  • Do I need to write different tests for each browser?

Solutions

  1. If the web pages have similar titles, and controls inside the web pages have property values that are the same or similar in different browsers, you can avoid the need to create a different interface definition for each browser:
    • For windows (web pages), capture the property doc title, because its value generally remains constant across browsers.  
    • For controls, capture properties that have the same or similar values across browsers, and which can uniquely identify the controls.
  2. Controls inside a given web page may have property values that vary from one browser to the next. In some cases, using Xpath locator to identify these web elements accurately and precisely may solve the problem. In others, you may find it too difficult to use a single interface to map all of the controls you need in a way that will apply to all possible browsers. For these situations, TestArchitect supports keyword variations and Systems & Platforms features to help users automate their tests across multiple browsers.

1. Capturing One Interface Definition for All Browsers 

1.1. Capture a Window (Web Page)

Open a web page that you want to capture the interface of, so that it may be tested on various browsers (e.g., https://www.logigear.com/company/company-overview/careers)

Figure 1: The web page being used in this example.

Create a new interface entity in TestArchitect:

  • Under the Interfaces subtree, right-click an interface node and then click New Interface Entity.
Figure 2: How to find the “New Interface Entity” feature.
  • Enter relevant information for the interface:
Figure 3: An example of how to use the New Interface Entity feature. 

+ Name: The interface name 

+ Description: Short description for the interface (this is optional)

+ Click Create. The new interface is added to the project under the selected interface node.  

Figure 4: You can capture the browser window by using the doc title property within the Interface Viewer.
 

Open the Interface Viewer (Press F7 or select Tools > Interface Viewer from the main menu; or click the Interface Viewer icon on the toolbar.)

Capture the browser window using TA property doc title.

1.2. Capture Controls

Identify the control (there are 2 options):

Option 1

  • Expand the tree node
Figure 5: An example of what the control will look like once it is identified and highlighted.
 
  • Select control
  • Select Turn on Auto Highlight on the toolbar to identify the control in the browser

Option 2

  • Click Identify icon on the toolbar.
  • Move the mouse to control that you want to identify on the browser, and then click it.
  • Control will be shown on the Interface Viewer’s tree.
Figure 6: The control will now be displayed in the interface viewer’s tree.
 

Choose a property to capture with the control. You should choose a property-value pair that (a) uniquely identifies the control, and (b) does not vary in value over time nor across browsers. Typically, the properties NameID, or Xpath are useful for identification.

Figure 7:  Property panels interface viewer.
Figure 8: This is what a completed interface entity will look like.
 
  • Map control 
  • Right-click the control to be mapped, and then select Rename
  • Type your choice of TA name for the item and hit Enter. The control is now mapped.  
  • Save your settings to the interface entity by clicking Save on the toolbar.

2. Using Keyword Variations

Use keyword variations to create high-level actions or interface entities tailored to a given browser. To demonstrate this, we will perform the following steps: 

  • Create a high-level action
  • Create keyword variations for the action
  • Update the keyword variations
  • Execute a test with variation

2.1. Create the High-Level Action

Create an action, name it config, and enter a single setting action line as follows:

Figure 9: An example of the default version of the config action.
 

This is your default version of config

2.2. Create a Keyword Variation of the Action

  • Copy a definition (of an action, or interface entity) of which you wish to create a variation: In the TestArchitect explorer tree.
  • Select the item and press Ctrl+C on your keyboard, or
  • Right-click the node and click Copy. (Figure 10)
  • Right-click a folder node where the variation is to reside and select Paste with Variations from the context menu. (Figure 11)
  • Select the Use keywords checkbox. In the text field, type the keyword(s) to be used to define this variation. (Figure 12)
  • The new variation appears as a node in the TestArchitect Explorer tree. (Figure 13)

2.3. Update the Action Variation

Figure 10: Copy the config action.
 

Figure 11:  Paste the action into the desired location with the “Paste with Variations” option.
 
Figure 12: This action variation will be used for the Firefox browser, as noted by the name.
 
Figure 13: You can see your action variation as a node within the tree, along with all other variations.
 

Modify your action to match the requirements of its target browser.

  • In this case, the target browser is Firefox. To have TestArchitect launch a Firefox browser window, specify it in the setting/use browser action line. (Figure 14)

2.4. Executing a Test with a Keyword Variation 

  • Select test modules that you want to execute against the Firefox browser.
  • Click the Execute button on the toolbar.
  • In the Execute Test dialog box, type the keyword name (“Firefox”) into the Keyword textbox, then
Figure 14: The ‘use browser’ setting will allow you to select a specific browser to be used in this action variation.
 
Figure 15: Using the keyword ‘firefox,’ TestArchitect will execute all-action variations for the Firefox browser as you have set them up.
 
  • Click Execute to start the test. (Figure 15)

3. Using Systems & Platforms

The Systems & Platforms feature makes creating cross-browser tests easier. Supported browsers are Internet Explorer, Mozilla FirefoxGoogle Chrome, and Edge. To do this, we follow these steps:

  • Create a platform and version
  • Link each variation to a version.
  • Execute a test with variations

3.1. Create a Platform 

To execute your tests across multiple browser types, you must create a new platform and name it. For example, we’ll name ours “Browser.” 

  • Right-click the Systems & Platforms node, and then select New Systems or Platform. The New System dialog box appears. 
  • Enter details for the new platform:  
    • Name: The name of the new platform (“Browser”). 
    • Description: A short description of the platform (this is optional). 
Figure 16: The browser platform will be a node on the Systems & Platforms tree.
 
  • Click Create
  • The Browser platform is added as a node beneath the Systems & Platforms node.

3.2. Create a Version 

You can now create 3 version nodes for the Browser system and platform. The 3 new version nodes you will create are Internet ExplorerMozilla FirefoxGoogle Chrome, and Edge.

  • Right-click the Browser node beneath the Systems & Platforms node, and then select Add Version
  • Enter the details for the new version:  
    • Name: the name of the new version, (e.g., “Internet Explorer”). 
    • Description: a short description of the new version (this is optional). 
  • Click Create. The new version Internet Explorer is added as a node beneath the Browser system node. 
  • Repeat the above steps to create the other 3 versions, ChromeFirefox, and Edge.
Figure 17: Here we have the 4 supported browsers for this feature, all with their own platform versions.
 
  • The 4 new versions–Internet Explorer, Chrome, Firefox, and Edge–are added as nodes beneath the Browser platform node.

3.3. Link Each Variation to a Version

Select the high-level action or interface entity for which you want to create a variation. The set of variations of a given item is used to execute cross-platform Automation tests.

Example: You have a high-level action called config that is used to create essential initial configurations for the browser. It is suggested that you have variations of the config action that set up web Automation tests for each of Internet Explorer, Edge, Google Chrome, and Mozilla Firefox.

  • In the TestArchitect explorer tree, navigate to the node for the config action you created earlier, right-click it, and then select Copy.
  • Right-click the Actions node in the explorer tree, and select Paste with Variations. You have now created a variation for the config action.
  • In the Variations dialog box, select the Link to version node checkbox.
Figure 18: Selecting browsers in Execute Test dialog.
 
  • From the Select system drop-down list, select Browser.
  • In the displayed system subtree under Browser, select Chrome to link this variation to Google Chrome.
  • Click OKYour new config variation for Google Chrome appears as a node in the TestArchitect explorer tree.
  • Repeat the above steps to create another variation linked to Mozilla Firefox and Edge respectively.

Important: You now have 3 variations of the default config action, but their contents are all identical. Obviously, you must edit them (well, 2 of them), to get them to have different behaviors – that is, to ensure that each is tailored for its respective target browser. That editing is fairly simple:

3.4. Executing a Test with Variation

Figure 19: Now you have 4 different action variations to use in your Cross-Browser Testing.
 

In TestArchitect explorer, select the test modules that you want to execute across multiple browsers. 

  • Click the Execute button on the toolbar. The Execute Test dialog box appears. 
  • Execute the test modules.  
    • In the Execute Test dialog box, click the Select Version button in the Variation Specification frame. The Select Version dialog box will appear.
    • Select a browser. 
      • Select the Internet Explorer checkbox to execute against Internet Explorer
      • Select the Chrome checkbox to execute against Google Chrome.
      • Select the Edge checkbox to execute against Edge.
      • Select the Firefox checkbox to execute against Mozilla Firefox.
    • Click OK. 
  • On the Execute Test dialog box, click Execute to start the test.

Conclusion

And there we have it: multiple ways for you to easily perform Cross-Browser Automated Testing! The fact of the matter is that consumers today have a plethora of options to choose from when it comes to web browsers, and you need to make sure that your product works on each and every one of them. There truly is no excuse to not do so—especially when Cross-Browser Automated Testing can be this easy using TestArchitect. If you’re still looking for more help with TestArchitect, head on over to www.testarchitect.com; we have tons of resources for you to use, including white papers, FAQs, and user stories just like this one. Happy testing!

Facebooktwitterredditpinterestlinkedinmail
TestArchitect Support Team
We are the TestArchitect Support team who will help you achieve Automation success. Creating a few dozen automated test cases is easy. Maintaining them overtime while scaling your test suite to thousands of tests is not. It needs the right mix of tools, methods, and expertise.

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe