Browser compatibility or cross-browser testing is a process of evaluating whether the functionality of a web application remains consistent when the end-user visits your web-application from a different browser. It is also used to validate browser compatibility for desktop and web applications.
In cross-browser testing, you will validate the style, font, and other UI elements of your website. All these things should look similar in each browser.
The Importance of Testing in Different Browser Versions
Well, first, not all people are using the same browser.
You can check the latest stats on Wikipedia for usage share of all browsers, desktop browsers, mobile browsers, and tablet browsers.
Now let’s look at the other scenarios…
You hear about some sales on a product that your parents wanted. You call them and recommend checking the online store so that they find some stuff they were looking for a long time. In some time, they call you back and say that it’s hard to navigate. After several questions, you understand that they are using a different browser and it begins a whole new question of how to download another browser — the one that you are using.
In this case, the business is just risking losing clients because of one browser version looking awful. In the 21st century, when you open some web app and it looks bad, you just go back to Google and open another one until you find a good-looking web app.
What Features Are Analyzed in a Browser Test?
When the testing phase is coming, the product team (most of the time it is QA related work) creates a test specification document in which they specify a list of features to be tested, and in what browsers/versions/platforms in order to meet test scenarios. We can divide this into the sections given below.
1. Basic functionality: To ensure that simple stuff is working on most browser-OS combinations
- All input fields and their validation
- Dialog boxes and menus are working as expected
- Input touch on mobile devices
2. Design: To make sure fonts, styles, images, and layouts are matching requirements that were sent by designers
3. Responsiveness: Verify that design is solid and not broken in some layers after you change the resolution/orientation of a browser
How To Choose Browsers?
There are two easy ways to choose from all the variety of browsers
1. Based on popularity: Choose browsers that can overcome the 5% barrier in global statistics. So, for example, in 2020 you would choose Google Chrome, Safari, Mozilla Firefox, Microsoft Edge, and IE. Regarding IE, it is a bit tricky because there are a lot of versions of this browser. Our recommendation is to support only IE 10, the reason being that IE 8 and 9 are too old and hard to support.
2. Based on the analysis: If you have some analytics tools (Google Analytics, etc.) that are tracking all traffic stats, you will have a full understanding of what your customers are using, and it will be an easy decision to make. If not, you may try to know your customer better by creating some polls, etc. Would it be worth to support all the versions of different browsers? It depends on if you agree that development and testing time will be higher every time. Either way, in the long run, you will have to sacrifice supporting old versions.
The decision on which browsers and platforms to choose depends on the business team and the marketing team.
How To Plan & Run Tests?
Before planning when and what tests will be executed, you should make sure that these conditions are met:
- Your test cases are up to date.
- Design and mockups are according to requirements.
- You have all the tools and devices that you need for testing.
- You should run regression testing at least one time in each browser. This will give you knowledge about the product and its bottlenecks.
When you are planning, don’t forget to mention who will be responsible for what browser/platform combination and assign test cases to be executed to the person responsible.
Tools To Use For Browser Compatibility Testing
- If you don’t have an opportunity to have physical devices on your project, you can use some kind of emulator/simulator/virtual machine. For mobile devices consider these options:
- You can simulate devices using developer tools that are default in Google Chrome or Mozilla Firefox.
- Fiddler/Android studio/Xcode if you need to debug or reproduce an issue with your mobile device.
- As an example of a VM, you can use a virtual box or anything related that you prefer.
- For different browsers, you can use some paid cloud services that will provide you with a whole variety of browser/platform combinations.
However, don’t forget that simulation/emulation is great when you have a limited budget, but nothing will compare to testing on a real physical device.
Manual vs Automated Cross-Browser Testing
Let’s talk about manual vs automated execution.
Manual testing needs human testers to execute scenarios, and it means that there is room for human error. From the beginning of the project, the amount of work for manual testers will only increase, which will, in turn, increase recourses and time.
When there is a scope of tests that are being executed every time, it’s better to just automate it. Setting up a full process of automation that would cover most of the tests takes a long time. So, it’s good for a long-term project.
In the modern world, most projects have both manual and automation testers in one project. Manual testers are doing exploratory testing to find the pain points in the UX (that is if we are talking only about the FE testing part) and automation guys automate scenarios that are running every time.
Common Issues While Performing Cross-Browser Testing
1. Internet Explorer: Yes, you read it right! As a separate category, I’ve put IE. This is the most painful browser to test. Every QA tester knows that when he opens Internet Explorer, he will find a couple of bugs. Everything related to the front end can be broken here. You need to keep this in mind and don’t forget to check your application in IE.
2. Layout: This is the most visible issue that you can find. Basically, it’s all related to CSS, Canvas, or DOM. Various bugs ranges from wrong text or image position to a small issue like a wrong-looking font. Do not forget about negative testing here as well, like closing a pop-out form by clicking somewhere outside the form.
3. Touches and Clicks: It’s not easy to juggle the various types of input, especially now that tablets and phones generate touches that may or may not act as a mouse click.
4. Hovering: If you have a menu that opens by hovering a mouse over it, don’t forget to check it as well. Sometimes the hovering never ends, sometimes the hover event links to the wrong item, sometimes it doesn’t open at all.
- Identify what browsers and platforms you will be testing on.
- Make sure that your test cases and designs are up to date.
- Set up devices/browsers you’ll test on.
- Assign test cases to the responsible person. Try not to assign the same person to test the same platform/browser combination a few times in a row.
- Share the document with the test results to people that will be fixing the bugs.