LambdaTest Community

Find answers, support, and inspiration from other users

LambdaTest Community

How can I test my website in different browsers as well different versions of the browsers?

Can anyone please tell me how can I test my website in different browsers as well different versions of the browsers.

Up Vote Down Vote 0 Votes
Posted 2 months ago


There is no specific way that is believed to be the fastest when we refer to performing cross browser testing. Cross-browser compatibility testing is a necessity in the face of modern web app development. At first, it would seem very baffling, but it really isn’t! You might have encountered an outage where your end users were not able to operate your product using a particular web browser. Flex, JavaScript, Applets, AJAX requests, Flash, and many more client-side components may behave differently on different web browsers. This happens due to rendering engines. The rendering engine is a part of a web browser which is responsible for presenting the content on various screens. This content could be text, images, or any other graphical representation. Every browser manufactured, be it Chrome, Mozilla Firefox, Safari, etc. has its own uniquely designed rendering engine. The process of checking that your web app stays compatible on various browsers is what we call cross-browser testing.

The major pain-point with manual cross-browser testing is that testers might need to spend a significant amount of time testing different web pages, cross-browser testing web apps across different breakpoints on a growing list of ‘complex’ combinations. Hence, it is recommended that one round of manual cross-browser testing is performed in the Staging environment before the changes are pushed to the Production environment. Since the development branch would involve changes from multiple developers, you can expect another round of cross-browser testing on these changes, before they make way to the ‘prod/production server’. Though you might be following a ‘model for software development’, there are many activities that become unplanned/ad-hoc and manual cross-browser testing is often considered one of them. The Turnaround Time (TAT) for the resolution of bugs could vary based on the synergy between teams. TAT could increase if the teams indulge in blame games and this behavior can result in an overall delay. You cannot change human tendencies, but you can definitely ensure that processes are kept in place to improve the speed at which tests are performed without compromising the Turnaround Time.

Here are 34 ways to save time on manual cross browser testing.

  1. Code Linters
  2. Cross-Browser Testing after a significant development milestone
  3. CSS Prefixes
  4. Parallel Testing
  5. CSS Profiling
  6. Perform Cross browser testing on the Cloud
  7. Test, Test and Test at each stage
  8. Create a detailed test-plan
  9. Unit Testing
  10. Test Scripts
  11. Use Web Analytics To Figure Out The Most Preferred Browser
  12. Create a Cross Browser Compatibility Matrix
  13. Focus on tasks that yield more output
  14. Reusing components
  15. Testing using a ‘Humane Approach’
  16. Look for professional testers
  17. Crowdsourced Testing
  18. Fallback Mechanism for your users
  19. Use Breakpoints at relevant places
  20. Using a test harness
  21. Study the browser landscape for the target markets
  22. Utilize Simulators & Emulators
  23. Deploy the Continuous integration model
  24. Testing against a specification
  25. Work hand-in-hand with the testers
  26. Keep interactions as simple as possible
  27. Use a Framework (wherever possible)
  28. Simplicity in Design
  29. Consistency in content
  30. Capturing Screenshots With Automation
  31. Comparing Screenshots With Automation
  32. In-House testing
  33. Focus on Accessibility Testing
  34. Early focus on features related to Localization & User-experience

1. Code Linters - Irrespective of the development language being used, it is important you lint your source code with static analysis tools. You may not be in a position to identify coding errors by just glancing through your code; hence it becomes necessary that you execute your source code against static code analyzers, also termed as Linters. Linters help in saving the manual effort for validating the cross browser compatibility of HTML, CSS, and JavaScript, plus you have the flexibility to either use online tools or linters installed in your local machine. Before using online linting tools, it is advisable that you discuss with your manager since you would be uploading the code on the server (where the online linter will statically analyze the source code).

Some of the popular Linters for CSS, JavaScript and HTML are

  • CSS – CSS Lint, Stylelint
  • JavaScript – JSHint, ESHint
  • HTML – W3C Markup Validation Service, HTML Lint, HTML Tidy

Along with the online option, you can also install plugins/add-ons of these linters to your code editors. Using an add-on option ensures that the linting is done in the premise of the development environment.

2. Cross-Browser Testing after a significant development milestone

Take a hypothetical situation – You have a module that comprises 50+ CSS, JavaScript, and HTML files and have come across a cross-browser compatibility issue with the module. Would identifying an issue in such an environment be different than finding an issue in the same module where you have changed 100+ LOC (Lines of Code)? Any developer would vouch for the second option since you are aware that the change (of 100+ LOC) has caused the breakage of functionality. Once you added the code changes, you should test the changes on browsers that your ‘intended customers’ might be using. Based on your internal research, you can test on the latest browser versions or test it on a version that is used by your target customer segment. Once you have fixed a lot of bugs, you should follow one complete round of cross-browser testing. Though, this approach depends a lot on the timeline of client deliverables and nature of the product; having cross-browser testing at an early phase of product development can reap rich dividends at later stages of testing & development.

3. CSS Prefixes

CSS Vendor Prefixes or CSS Prefixes are mechanisms through which browser vendors add new CSS features before these features become mainstream on all the browsers. If you want that your source code is supported on the latest browsers & older versions of those browsers, your CSS code should incorporate both, prefixed as well as unprefixed code. Using a tool like CSS Flexbox, you can generate new layout features. You have to provide the required prefixes and old syntax to the CSS Flexbox so that your code executes on browser versions where those prefixes are mandatory.

If you are adding the required vendor prefixes manually, there is a high possibility of manual error being introduced in the process. The best way to avoid such errors is by using tools/libraries that can add CSS prefixes automatically (wherever necessary). Some of the popular pre-processor libraries or tools are:

  • Sass
  • LESS
  • PostCSS
  • Autoprefixer

4. Parallel Testing

Irrespective of whether the testing strategy involves automated tests, it is a known fact that parallel module development/parallel testing will always be faster when compared to serial development/serial testing.

You can achieve parallel testing by developing test scripts that would allow cross browser testing of the source code across different browsers, operating systems, and devices. You can develop effective test scripts that can mimic human approach using Selenium WebDriver. We would have it covered in subsequent points.

5. CSS Profiling

We earlier discussed CSS Linting and why exactly you should use a Linting tool. Though Linting can help you identify mistakes in your CSS code, you should also use tools that do CSS Profiling. As a developer, you could be adding code to a CSS module that has a lot of legacy code. Larger the code size, the more difficult it becomes to identify the necessity of legacy code. The ideal way of handling this is by using !important CSS property which ensures that a rule would be applied irrespective of the location of a rule in the document.

There are a number of tools available for profiling the CSS code, but CSS Parker is the most widely used tool since it gives a lot of statistics about your CSS code.

6. Perform Cross Browser Testing on the Cloud

Setting up a testing infrastructure that can accommodate the combination of devices, browsers, and operating systems can be a costly affair and it might not be scalable as well. For example, if you have to test the website functionalities on different flavors of Android – Oreo, Pie, Nougat, etc.; you would need devices with these Android versions and you would also need to invest in procuring devices from different smartphone vendors. Hence, this approach is highly infeasible & non-scalable. An ideal approach would be to have the functionalities tested on Cloud testing services like LambdaTest, so that you can concentrate on the testing without being worried about the infrastructure. You can also write automated test scripts using Selenium by downloading the corresponding WebDriver for Selenium.

7. Test, Test And Test At Each Stage

Periodic Testing ensures that bugs are encountered at later stages of the development cycle. As a developer, you should test your functionalities against different combinations. Even though you are not comfortable testing your module, you should bring that mindset change and incorporate testing as a part of your routine.

If you are working on a complex functionality, you can divide your test plan into different stages so that there is no dependency. You can also make use of tools like CodePen – a social development platform for front-end developers. It can be used for prototyping your test cases.

8. Create A Detailed Test Plan

You would be cross browser testing your source code against various combinations of devices, Operating systems, browser types, screen sizes, etc. Hence the nature of issue you encounter on one version of Browser type (e.g. Chrome 59) can be significantly different from the ones you face on a different version of same Browser type (e.g. Chrome 60). Things can get complicated when you have the same browser type on different operating systems and devices. Hence, an ad hoc approach to testing might not be sufficient in this case.

You should come up with a detailed test plan so that the important functionalities of your code are tested on different combinations. You can formulate a test plan based on each device group so that you can easily segregate issues encountered on each device.

9. Unit Testing

The term unit testing needs no introduction, it is testing the changes that have been done by the developer at a ‘unit level’. Irrespective of the programming language being used, Unit Testing is used to verify code changes at a unit level. In order to bring that culture of ‘thorough testing’, the focus should be on Test Driven Development (TDD). By incorporating the TDD approach, developers & designers can come up with a beautifully crafted code. It also involves a mindset change. JavaScript has an exhaustive set of libraries that can aid unit testing, the popular ones are listed below:

  • Mocha
  • Jasmine

It is said the development & testing should go hand-in-hand so that bugs are unearthed at an early stage of product development.

10. Test Scripts

Unit Tests are performed at a ‘unit level’, whereas Regression Tests are performed keeping in mind the end-to-end functionality of the product. Regression tests are ideally done to ensure that the new code changes have no side effects on the existing functionalities.

There might be some cases where there is a visual element involved in the functionality e.g. Button click using JavaScript; whereas there could be cases where there is no update on the interface e.g. Updation of some field in the database once the Button is clicked. Hence, it is recommended that test scripts are developed & maintained on a timely basis and test scripts should be grouped as per priority.

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 the 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 & testing). Hence, you come up with a detailed plan on how to test the functionalities on browsers that would be used by your customer segment.

12. Create a Cross Browser Compatibility Matrix

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

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

Cross browser compatibility matrix will help you realize the browsers that should never miss out while performing cross browser testing. It will also help you reduce the testing effort by giving you the clarity about the browsers that aren’t providing results, as good as you expected them to be. With cross browser compatibility matrix you can plan a more effective cross browser testing strategy.

Up Vote Down Vote 0 Votes
Posted 2 months ago