What does your browser testing process look like?

  • 8 September 2016
  • 5 replies
  • 2 views

Userlevel 7
Badge +4

Today I was chatting with a few folks about the process we use to check out a finalized Unbounce page and make sure it looks great in different browsers and on different screen sizes. Thankfully, since Unbounce already does the heavy lifting for us and optimizes so much on the backend, we very rarely have any display issues (if any at all).

But just to be safe, we always check before handing a page over to a client. My personal favorite tool for doing this is BrowserStack. It’s bascially a cloud-based tool that lets you see what your page will look like on all different types of devices and in all different types of browsers. (I’m not affiliated with them. Just a user/fan of the product).

But obviously, there are other ways to go about this testing process. You don’t have to use a tool such as BrowserStack. You can simply check out your page on different devices for instance, if you have access to them.

So, what does your browser testing process look like? Do you use a different tool? Or do you do it manually, or maybe not at all? I’d love to hear some different workflows, tips, and tricks regarding this. 👊


5 replies

Userlevel 7
Badge +1

Once again, @Nicholas, knocking it out of the park!

Userlevel 6
Badge +1

This is a question I’ve been asked many a time 🙂 and to your point there are many ways to do this. BrowserStack is cool, I have used it before. But, honestly for us it is mostly about using client data or industry data to see what devices/browsers/os etc their users are on. This way we can build for those first. Once more data rolls in we can start optimizing the browser experience. But, yeah, typically Unbounce has it covered unless you’re using custom scripts, embeded stuff, and from my experience FONTS are the biggest trouble maker of them all!

Hey,

I work on the builder tool at unbounce so I thought I’d share a little of our own process. The two major aspects of our tool is the builder itself and the published pages.

The builder only supports the latest browsers. In particular chrome, firefox, safari and edge. Most users of the builder are bit more savvy and tend to use these latest browsers. This allows us to take advantage of the latest technologies, like writing the builder refresh entirely with flexbox and put themeable skins on the roadmap. We all use macs / linux here at unbounce so we have access to all these browsers, with the exception of Edge… and hats off to Microsoft, they’ve been killing it with Edge. Most of the staff here uses Chrome, Firefox to a lesser degree and a couple on Safari so we usually catch any inconsistencies pretty quickly. We can also allow for small variations between browsers and OS’s as long as they’re non disruptive.

Published pages tend to be a different beast. Since it has to look as close as possible across all systems, every change has to be tested. We often have to use different tools and processes but the most often it’s manual testing with BrowserStack or visual diffing with tools like Phantom with Casper.

Userlevel 7
Badge +4

It’s awesome to hear behind-the-scenes stuff like this. Nice to hear that Unbounce is so Mac-friendly too. 🙂 Thanks for sharing, Matt!

Userlevel 6
Badge +1

@Matt_Coady That’s AWESOME to here!

To add to your point, I think it is essential/necessary for us (industry) to lead the way and ensure that the end-user moves forward with new browsers. We all still have clients that use legacy and it;s tough trying to get them to adapt on. 🙂

Reply