Making web applications is fun. Well, it should be fun, but it’s often not. It’s not, because there’s so many browsers, operating systems, and devices to cater to. And who has the resources to cater to every device configuration and operating system setup which the average user is likely to have? Can anyone truly cover them all?
Yet despite this challenge, it’s our responsibility to deliver the best possible experience; and to do that, we need to find a way to do reliable browser testing.
So in this post, I’m going to show you how to get started by providing you a step-by-step guide to cross-browser testing packed with tips, metrics and tools. When you’re finished, you’ll have all you need to start.
What is Browser Testing?
So what is browser testing? Known by many names, including browser compatibility testing and user experience testing, it is testing to ensuring that a website or web-application works, as expected, in a given browser.
This is based on a range of metrics, including:
- Base Functionality: Are links, dialogs, menus available as required
- User Interface: Does the appearance match the specification
- Graceful Degradation: Does the experience adjust between desktop and mobile browsers
- Responsiveness: Does the site adjust in mobile browsers based on criteria such as resolution, rotation, and location
- Performance: Does the site load within a suitable time frame, whilst allowing for network connection speed
Automated vs. Manual Browser Testing
Now let’s look at the two basic types of testing: automated and manual. Automated testing is the ability to setup tests which can be run with little, or no, deliberate human intervention.
Manual testing, on the other hand, as the name implies, requires the deliberate involvement of a human tester to verify the functionality of an application or website.
Which One Should I Use?
That’s a good question, but not one necessarily easy to answer. To help you out though, here’s a list of questions to ask, either yourself or your team, to know which one would work best.
- Is your application/site new or legacy?
- How complex is your application/site?
- How many browsers does the application/site have to support?
- How many devices does the application/site have to support?
- How many operating systems does the application/site have to support?
- How many versions of each browser does the application/site have to support?
- Do you only have to support the latest versions?
- What are the performance criteria?
Do I Need Cross-Browser Testing?
This is something only you and your team can answer. But the simplest way to know is by referring to your design specification. If it only mandates that the application only has to work on your company’s intranet, then that’s all you need to care about.
However, if your specification mandates the latest version of every browser, across the desktop as well as iOS, Android, even Windows Phone, then you need cross-browser testing.
When to Start Cross-Browser Testing
If you need to do cross-browser testing, then the best time to start is as soon as possible. Whilst the need may not be present yet, it will likely come sooner or later.
Having at least made a start can only be of help; even if that’s only in Chrome and Firefox — which ensures a comparison of different rendering engines.
Like anything, don’t leave it till the last minute. Get started and in the process, make more robust sites.
Tools To Use For Browser Testing
Now that we’ve covered the groundwork, let’s look at 7 tools which can help you out with testing.
1. SauceLabs: Automated Browser Testing in the Cloud
2. BrowserStack: Cross-Browser Compatibility Testing
BrowserStack is definitely the biggest and well known of the browser testing tools available today, and for good reason. It offers the ability to test a site in nearly any version of any desktop or mobile browser, across a nearly ubiquitous array of hardware device configurations. What’s more, it also allows for testing of local or private setups.
Whilst not as sophisticated in appearance as the previous two, Browserling offers an impressive array of features for an impressive price. They offer support for testing across all of the latest browsers as well as good support for previous versions. SSH tunnels can be setup for local or private testing. And soon they’ll be offering take screenshots and record videos of sessions as well.
Browser shots is a little different from the previous options. Instead of providing the ability to view your site or application near natively, Browsershots creates screenshots of the url you provide across the range of browsers requested which you can later view.
Responsinator is a great tool for getting a good understanding of what your site will look like across some of the most popular devices. From the iPhone6 Plus in portrait mode to a first generation Android in landscape mode, it shows you what your site’s likely to look like.
Finally, there’s Usersnap. Once you identify issues in your design, make sure that you’re able to report them quickly and effectively. By integrating the Usersnap Feedback Widget with your site or application, you’ll be able to supply a wealth of information to your team as and when needed.
For example, as your QA team is testing your site, as they find issues they can log annotated screenshots, outlining the issues discovered. Along with screenshots, a host of system information, such as operating system, browser, screen resolution and so on, will also be stored. This information will be available, in the Usersnap dashboard, for your entire team to use.
And that’s the basics of cross-browser testing in the modern age. Whilst definitely a challenge, given all of the browser, hardware, and device options, the tips, metrics, and, tools we covered today provide an effective way to get started today.
If you’ve not done so already, check out the tools we’ve covered and see how the quality of your browser testing improves. But whilst you’re getting started, make sure you keep track of your situation.
What’s better for you, manual or automated testing? Do you need to actually do cross-browser testing? Or is your application able to just focus on one browser and a limited hardware selection? Make sure you do expend your efforts wisely.