Let’s catch bugs! A beginners’ guide to website testing
Website testing is a lot simpler than it seems. You don’t have to be a tester to do it. And you’ll get an insight into your product that will help you understand it in a whole new way.
I’m a tester on the Single Digital Presence (SDP) project. My job is to test SDP platformed websites on many browsers, screen sizes and devices to find bugs and ensure optimal user experience.
Testing helps you better understand your users
When I’m testing a website, I’m not just looking to find errors or bugs, but I’m trying to look at it through as many different lenses as possible. This means using a website on different devices, in different browsers and within different screen sizes. Some bugs only appear in 1 browser so testing in many different environments is necessary. It is also a great opportunity to see how different users might be interacting with the site too.
What we test on
For the vic.gov.au website, we test on multiple environments including Windows, Mac, Android and iOS. We test on desktop computers, tablets and phones, as well as multiple internet browsers for some devices.
We use the Victorian Government Digital Standards Test a product or service guide which includes commonly used browsers and user acceptance testing templates.
We never know how people will access our site, so we want to make sure that however they access it, their experience is consistent and it meets our quality standards. Of course, there are seemingly endless numbers of devices we can test our sites on, but using the devices we already have and can borrow from others is often enough to provide us with invaluable insight in how the public might perceive it.
After the vic.gov.au website was released, I happened to be at the Doncaster shopping centre. So I went to the Apple store to test the site on one of their iPhones, since I didn’t have one myself. I filled out one of the page feedback forms and signed it as ‘James from an Apple store’, and our content team appreciated the effort I went through to test the site.
If you do want accurate data on which devices, browsers and screen sizes people are using to access your site, you can always check Google Analytics if it has been set up with your site.
Testing checklist
Drag test
The first test I like to do when testing a website is the drag test. This allows me to gain a quick understanding of what the website might look like on different screen sizes and on different devices, all while staying in the same browser.
The drag test involves dragging the browser window from the largest size to the smallest size, in order to see what the site looks like at different breakpoints, which is the point at which the site morphs based on how large the viewport is.
Breakpoints are necessary because we want things to get bigger or smaller to accommodate for the different screen sizes we can view the site on, and dragging the window to be smaller or larger is an easy way to observe all of these changes. So let’s see an example with the vic.gov.au homepage.
These are not the only three screen size breakpoints on vic.gov.au and it will be different for every site, but it’s something to get you started.
I often look at the header to see which breakpoint I’m on as almost all of them have something changed in the header each time. And I’ve learned what each different header looks like by looking at the designs for the site. It helps a lot to have access to the designs so that you can know whether a feature is supposed to look the way it does at a certain screen size breakpoint. Given the number of differences between breakpoints, there are often a few errors in the implementation. So this is a very valuable test to be doing as the site is being developed.
Don’t forget to do the drag test for the header, the content and the footer of the site, as they all have unique content which could change between breakpoints. Also take note of where the sidebar content goes when the page gets small enough. It usually goes somewhere at the bottom.
Content type testing
Each website has different page content types. Be sure to become familiar with each individual content type as you will be testing for different attributes on each page. Some pages vary more than others. On vic.gov.au, our content types are:
- Alert
- Event
- Grant
- Landing Page
- News
- Page
- Profile
To learn more about content types, visit: https://www.vic.gov.au/what-single-digital-presence-offers#page-templates-available-on-sdp
Device and browser testing
And finally, once you have tested the site thoroughly on your favourite browser, it’s always good to see what it looks like on other devices and browsers too — especially the popular ones — as the touch experience isn’t something you can always anticipate, and you can always find bugs that are specific to a certain browser on a particular device too. Which seem to come out of nowhere and are completely unexpected.
Handy testing links
- Most popular browsers (Australia) — http://gs.statcounter.com/browser-market-share/all/australia
- Most popular browsers (World) — http://gs.statcounter.com/browser-market-share
- iPhone simulator (Mac only) — https://developer.apple.com/xcode/
- If you’d like to do device-specific testing instead of just screen resolution testing, then Google Chrome Developer Tools has a Device Toolbar that can simulate how a real device behaves, but it’s not perfect.
There are many website testing techniques not discussed in this article, but this is a great place to start. The next thing I would test is that data entered in forms appears correctly in the backend and that invalid data cannot be entered.
Have fun testing and I look forward to hearing what people learn from this article. Let’s all do web better together!
