QA in a Connected World
The devices we use and the websites we build have gotten more and more complex over the years, which makes information readily available from wherever a person may be on whatever device they may be using. This is a good thing – we’re more connected than ever (maybe even too connected, but that’s another conversation) and have richer experiences online because of this. Libraries have moved to Wikipedia and online journals, while TV has moved to Netflix and Hulu.
We can do everything online, and we expect to be able to do it quickly and easily. This presents great challenges for design, development, and QA of a project. People’s standards for online content are higher than ever, and we have to meet those standards every step of the way.
Quality Assurance is a process that should be ongoing as you complete elements of your website. Having a dedicated QA professional manage your quality assurance is a good way to make sure your website is released with as few bugs as possible. When you’re planning to build a responsive site, you have to account for your time spent on QA to increase significantly compared to that of a normal website depending on how many devices and browsers you plan on supporting. Every part of your site has to be checked on various browser sizes, tablets, and smartphones. It is an involved process and you should have a plan going into it.
What do I need to QA effectively?
1. Define the devices you plan on supporting.
If you plan on supporting Android 4.x, iOS 6+, retina desktops, and iPads, agree to it and document it. Every large update of an operating system brings new bugs and new workarounds you have to use correctly to make your site work. The difference between iOS and Android is larger than Android 4.1 to 4.2 considering both operating systems have their own way of doing things, and it’s still important to document which versions you plan on supporting. This can significantly change what sort of behaviour you can have on your site.
2. Have access to the devices you plan on supporting.
If possible, you should have a real, physical device for every operating system you plan on supporting in front of you to test on. Emulators are a fine fallback, but they can’t show you the real issues your site has because of that one bug you missed in iOS 7 that doesn’t exist in iOS 8. Send out a call to the people in your office for devices and ideally get company versions of every device so you can continually QA on those devices for all your projects. If you can’t get a hold of the devices you plan on supporting, use a device emulation service to test your site (BrowserStack is one of those services). The developer tools in your browser are fine for faking a user agent or screen size, but they can’t emulate the operating system of the device you’re supporting, don’t count on them to be the end all of QA.
3. A plan.
This one goes without saying, but you should have a list of pages as well as the expected functionality for those pages on each device or device category you plan on supporting. Without this, you’re just clicking through your website on a phone and will end up with incredibly inconsistent results and notes from your QA.
But how do I plan what I want to support? What about screen sizes? There’s so much out there!
Let’s take a page out of the Bootstrap handbook to come up with some basic breakpoints to use for a new site.
- Extra small: < 480px
- Small: < 768px
- Medium: < 992px
- Large: < 1200px
These will serve as a solid baseline for a responsive website. As far as actual devices you plan on supporting use a combination of the analytics for your current site (you do have analytics right?) and statistic sites like these — Stat Counter and Android Developer Dashboards — to paint a clear picture of your current user base and the users you plan on targeting with your new site. Make sure you’re accounting for both landscape and portrait views of your site. Don’t forget to take a look at desktop browsers as well! Do you want to support IE8 or worse, Safari on Windows? I hope for your sake you don’t but I more than understand, it happens. These will change what functionality, polyfills, and libraries you use on your site.
As far as when you perform QA, you should perform QA throughout your whole project. Obviously developers will do what they can to remove all the bugs from the site, but odds are once a section has reached a major update, they will want someone to take a look and QA that section. It doesn’t need to be a completed section, just a large change to it (going from 3 columns to 4 on a page layout for example) to call for some QA. Once a section has been deemed completed by the developers and QA people, you should run through it again once more with the designers, owners, and anyone else who has a stake in that section.
Performance metrics are a good thing to measure as well. This is more on the technical side of things, but know that on a mobile HTTP requests are the true killer of performance and keep an eye on this as your build your website. Use tools like Google PageSpeed and the Chrome Dev Tools to check the network performance of your website. Keep your performance high throughout the project and you won’t have to make a big rush at the end to make sure your site that looks good, performs well too.
Closing thoughts
You can see how QA on a responsive site can take up a very long time and use a lot of resources. It’s a lot more than just looking at a section of your site in Chrome, resizing your window a bit, and calling it a day. There are many steps to the process and while you can certainly skimp on some of them, skimping on them all will cause significant issues with your site down the road. It can cause your developers or designers to have to look at a section all over again, eating up valuable time they could be working on other projects. Testing on a phone brings with it a lot of issues, devices dying (seriously, make sure you have enough chargers), wifi going out, multiple people needing to test on a device. The list goes on, don’t underestimate the time and energy that goes into QAing and responsive website. The end result will be a bug free website that works on all devices and is set up to succeed in these modern times where everything needs to be fast and easy to use.
Source: Old Pop Art Site
