Let’s level up our QA skills together by learning how to use Sizzy. Anyone can leverage Sizzy to optimize their QA process as we take on larger and more projects.
Project Managers, Account Managers, Designers, Developers, and anyone else that does QA on websites.
First we’ll discuss why and how we do browser testing. Then we will delve into the problems we currently face with browser testing. Then we can discuss the solution and how it solves the problems. Next we will do a short demo to show how easy it is to use. Then we will talk about the next steps, pros and cons, and about any extra information and where you can find it. We will finish off with a quick little Q&A.
In this day and age, people have access to a wide range of devices with an equally wide range of display sizes. It’s expected then that many of our clients’ customers will view their site on more than one device.
All of those devices are not the same, whether it’s physical size, model, make, or manufacturing company. These devices will all display a website differently even if they are using the same browser or even browser version.
One of the worst things we can do is say that because we don’t see the bug we will not address it for the client.
The goal is to provide a similar if not the same experience on all devices for everyone.
The browser testing process usually happens in levels of increasing complexity.
The important thing as well is to try to ensure we are performing the same tests across all the methods of testing.
Even if you have Chrome, Safari, Firefox, Opera, etc. on your own Mac you will not likely be switching between the various versions of the browser to check compatibility.
Macs have different browser settings than PCs and phones even if they are using the same browser. An example is the font smoothing that the Mac performs that PCs do not. This can cause a font styling to look correct on a Mac but not a PC.
Another issue is that you had better hope the other device you planned on testing with is charged when you want to use it.
A more current issue during this apocalypse is the fact that many of us don’t have these extra devices just lying around at home waiting to be tested on.
Even when you’re in the office, you’d better hope that no one else had planned to do QA with the device at the same time as you.
The same goes for Browserstack. I’m sure I’m not the only one who has ever been kicked off while in the middle of a session because someone else logged in. Our license only allows for 1 user at a time for Browserstack.
Browserstack is also really slow. It takes 10 seconds sometimes for the inspector to open when I’m testing in IE.
As some may know, our Orpheum PC just ran into a bit of an issue that brings up the topic of how we do not actively maintain Windows devices in the office since they are used less.
Finally, it can be difficult and time consuming to guarantee you are performing the same actions in the same order across all devices, even if you make a list of everything that is to be done.
Sizzy is a browser built to solve many of the problems we deal with regularly in the QA process. Its purpose is to simulate how a website would look across a range of devices and it does this all in one place.
It is built using Google Chrome so you will see many similarities in things like the inspector. This is helpful because it means there is less of a learning curve when it comes to adopting this solution.
Sizzy allows for the use of several devices all at once or you can use them one by one. You can reorder them, duplicate them, and make new ones with various device sizes and features as needed.
You can simulate a touch cursor and use all the gestures you would use on a real device like touch screen scrolling.
You can take screenshots of all the devices at once and it will automatically save to a zip folder. You can also screenshot single devices as needed.
We can use Chrome’s dev tools either as a universal inspector function for all the devices or each device one by one.
You can synchronize the scrolling, clicking, or URL navigation so that you can see the same actions being performed across all the screens simultaneously or one at a time.
You can easily clear cache and cookies or disable them completely on all the devices without the need for any Chrome plugins.
These are just a few of the companies that use Sizzy in their QA processes, pulled from Sizzy website. Some of these are products that we use in the workplace or some of us at home.
Here we are going to imagine we are working on the Independent Review Inc. website and we need to make a JIRA ticket with a screenshot of the issue.
We will go into focus mode and navigate to the Macbook Air device in the top bar.
Next we will enable the inspector mode and take a look at the big blue bar labeled “Best Practice, Defined.”.
When we click on it we can see that the inspector loads and we can use it just like we would with the Google Chrome inspector.
Here we are going to imagine that the font is too large and we want to change it from 40px to 39px.
I am going to go ahead and close the inspector and take a screenshot by clicking on the top right corner camera button.
This will take the screenshot, so I am then going to head over to JIRA and begin the ticket making process.
I will then add an image to the ticket just like I normally would do when creating a ticket. My Sizzy images save in the default folder.
Once I have added it I finish creating the ticket and I am done. It’s that simple, which is the whole goal of using Sizzy, to make things simpler.
It is a really good idea to share the config file of all the devices you are using to do your testing with anyone else who is doing testing on the same site. This is because if you have added any custom devices the other person will have it as well.
Device sizes should be ordered based on priority for the viewing experience.
When testing, it is really easy to clear any cache and cookies to eliminate the problems with cache we have had in the past. You can go ahead and turn caching off altogether, save everyone some time.
Be specific when naming your devices. If you are making a device the same size as an iPhone 6, call it an iPhone 6 instead of just iPhone. Or if you are making a custom device let the title explain what the purpose of it is. Just like designers know the importance of naming your layers or developers know the importance of naming variables and methods to convey purpose, we should be similarly naming our devices.
Only have the devices that you need visible on the main screen and use the single device view when you can. The more devices you are viewing simultaneously the harder your computer has to work. Why have 10 devices open in the multi-device view mode when you just need one little iPhone.
User-Agent strings are really useful when it comes to trying to emulate a specific browser or a specific browser version. Hit the custom option when making a new device and enter your User String.
Deleting a device will remove it entirely, hiding it will just make it not visible on the main screen anymore. Make sure you don’t delete a device when you mean to hide it because when you want to use it again you will have to make a whole new device.
Take full-screen screenshots by clicking the 3 vertical dot menu item at the top right corner of the device screen and click on “Full Screenshot”. This can be useful when you want to see a larger portion of the screen than is visible in the window. This way you don’t have to make a whole new device with the full-screen dimensions.
Save the Sizzy screenshot folder to your list of favourite folders in the sidebar of Finder for ease of access.
Customize the colours of your Sizzy. Jenn can show you how to do that.
Will I get the same result as I would on a real device?
Sizzy simulates the viewport and user agent of each device, so the results should be the same as what you would see on a real device. However, Sizzy cannot simulate different browser rendering engines, so there’s a chance that there might be some minor differences when testing on a real device.
Does it run Internet Explorer?
It can run a Microsoft Edge User-Agent as well as an Internet Explorer User Agent but as was just mentioned it is a simulation of the rendering engine so there may be minor differences when testing on a real device.
As we can see here, Sizzy is the most robust solution available. Other platforms may still be necessary in certain use cases but those tend to be more experimental. For example, we could not properly use Sizzy to test the functionality of the Orpheum web experience iPhone issue just because it was a limitation of the actual browser technology implemented by Apple.
We discussed the current state of browser and device testing at Art & Science and we outlined some of the drawbacks of the current method. I then introduced Sizzy as a solution to many of the drawbacks we face in the QA process and discussed some of the features available. We went through a demo to show the ease of use of Sizzy and discussed some of the best practices and tips when using it. We then looked at some of the limitations of Sizzy but also outlined how Sizzy can beat out the other methods of testing when we looked at the Pros and Cons of all the testing methods. Finally, I have shared some extra resources in case you would like to find out more about Sizzy and its features.