{{announcement.body}}
{{announcement.title}}

34 Ways to Save Time on Manual Cross Browser Testing, Part 2: Methods 11-20

DZone 's Guide to

34 Ways to Save Time on Manual Cross Browser Testing, Part 2: Methods 11-20

We continue our look into cross-browser testing efficiency, discussing topics such as compatibility matrixes and creating reusable components.

· Web Dev Zone ·
Free Resource

Welcome back! If you missed Part 1, you can check it out here.

11. Use Web Analytics to Figure Out the Most Preferred Browser

Based on the initial market research and the customer market-segment, your management, as well as the development team, would have information about the expected user-segmentation. They would also have information about the browsers on which more testing should be performed (since the majority user base using your product could be using that browser). You can also use web analytics tools to pinpoint the browsers that are responsible for majority of your traffic.

As a developer, you would want your code to work seamlessly across all browsers; but you cannot dedicate equal time to each browser (during development and testing). Hence, you'll need a detailed plan on how to test the functionalities on browsers that will be used by your customers.

12. Create a Cross-Browser Compatibility Matrix

Once you are done with analysis of the browsers responsible for bringing traffic to your website, then it is time to prioritize those browsers by classifying them as explained below:

  • Fully supported and loved browser.
  • Fully supported and not so loved browser.
  • Partially supported but loved browser.
  • Partially supported and not so loved browser.
  • Unsupported but loved browser.
  • Unsupported and non-loved browser.

Cross-browser compatibility matrixes will help you realize the browsers that should never skip ove while performing cross-browser testing. It will also help you reduce the testing effort by giving you some clarity about the browsers that aren’t providing results. With cross-browser compatibility matrixes you can plan a more effective cross browser testing strategy.

13. Focus on Tasks That Yield More Results

Browsers are a piece of software and, like any other software, they have bugs. Browser companies periodically fix the bugs and they are pushed to the users via an update. There could be a possibility that the bugs being fixed may not be of high severity/the changes might not have any impact on the functionalities that are being implemented by you.

Since there are many operating systems, you should make a conscious decision as to whether testing should be done on the same browser across different operating systems. If the browser changes across those operating systems are trivial, you can skip the test.

Hence, when performing manual cross-browser testing, you should focus on the tasks that yield better output, rather than focusing on tasks that are repetitive in nature.

14. Reusing Components

 From the beginning of the project, you should keep a track of the tools and components that are used for development and testing so that there is no duplication.

You can also use a tool in order to create a shared repository of elements that are being used by your project.

15. Testing Using a ‘Humane Approach’

Along with unit tests and regression tests, you will need to execute functional tests which more or less mimic the testing from an end user’s perspective. In order to get the best out of these tests, you should come up with an automated approach to testing.

Selenium is a popular software testing framework for web applications and there is extensive support for it. WebDriver and NightWatch are popular JavaScript wrappers around Selenium Webdriver. 

By writing test cases using Selenium, you can automate button clicks, scrolls, the filling-in of text fields, etc. These are some of the real-time scenarios that will occur during the web-development cycle. Another advantage of performing these tests is the ‘interaction’ that is involved with your fellow team members. These tests are not done in a vacuum and, hence, you as a developer get an opportunity to interact with and discuss issues with fellow testers and developers in your team.

16. Look for Professional Testers

White-box testing is a specialized skill and you need to think like a developer to test the product features. Though developers can do unit testing of their modules, they should never perform end-to-end testing since their mindset might be biased and they may not have complete clarity on the test specifications. Hence, any manual cross-browser testing should be done by a professional or qualified testers since they can unearth the bugs in your product.

17. Crowdsourced Testing

In case you are unable to find testers internally at your organization, you can make use of crowdsourced testing services. In the case of crowdsourced testing websites, you can choose the testers who suit your criteria. Depending on the nature of the product, you can get an NDA (Non-Disclosure Agreement) signed by the tester so that confidential information about the product is protected.

More and more companies (of a different scale) are making use of crowdsourced testing since it has good cost benefits.

18. Fallback Mechanism for Your Users

As a developer, you might be up-to-date with all the latest technologies, but there is a sizeable number of people who are still hung up on old technologies (or browsers). Based on your product market research and intended target audience, your product should incorporate a fallback mechanism for features that are not supported on old browsers. For example, have a fallback mechanism for video playback in case your web browser does not support Flash.

19. Use Breakpoints at Relevant Places

The definition of a breakpoint depends on whether it is being looked at from a developer’s perspective or from a designer’s perspective. For a developer, a breakpoint is a media-query; whereas, for a designer, a breakpoint is a point when there is a change in the presentation of the content. It is recommended that you follow the mobile-first approach for design, development, content, etc. The whole intent of breakpoints is to have a web-page whose content adapts to the screen resolution of the device from where the page is viewed. This is normally accomplished by adding browser widths in media query declarations.

When should you add a breakpoint? You should add a breakpoint when your content is difficult to read, e.g. when the screen is wider. There are no ideal number of breakpoints, but you should use them judiciously in order to adhere to responsive web-design principles.

20. Using Test Harness

In the point ‘Reusing components’ above, we discussed the importance of keeping track of the tools and resources that are used for development and testing. You can use that information to create a test harness setup. A test harness is an automated test framework that is used for testing software/code against various kinds of test data. The test is performed under varying conditions, such as variable CPU load. The test results are captured and compared.

A test harness should be designed in a modularized manner so that components are loosely coupled and can be re-used across different teams (and projects). JUnit is one popular unit-testing framework that can be used to create a test harness setup.

Topics:
web dev ,cross-browser compatability ,browser testing ,web application development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}