We deliver new websites to clients pretty much every day, with PSD to WordPress being by far our most popular service. Making sure that they work correctly is paramount to the perceived quality of the delivery, and therefore we have developed a methodology for how to run website quality assurance before we show them to our clients.
Having a website quality assurance process is useful for anyone who just built a website and wants to make sure it works correctly. For a better web, and less headache.
Website Quality Assurance done right
We refer to our review as the Quality Assurance (QA) process, and its main purposes are to make sure that the site works correctly across different browsers and devices, and that all functionality is free from bugs. Here is a the checklist our QA specialists use:
1. Pixel-perfect compared to PSD files
Almost all the work we do is converting Photoshop files (or other formats, such as Sketch) into custom-coded WordPress sites. The first thing for our QAs to check is therefore that the finished sites match the designs. In order to do so, there’s a smart Chrome extension called PerfectPixel that allows you to overlay an image file in the browser to compare.
Here are a handful of other useful extensions we may use:
2. Functionality
Checking the functionality of a site can be a quick task or take several hours depending on the complexity of the website. By functionality, we mean checking specifically how the following features work:
- Forms
- Sliders
- Menus
- Buttons
- Links
Does the form accept the right file upload formats? Are the footer links leading to the right pages? Do external links open correctly? Will the slider slide as it should in different browsers? Etc.
3. Cross-browser functionality
Cross-browser issues are some of the most common issues we encounter with websites right after our developers are done with their coding. You can see in Google Analytics what browsers people use when they visit your site to determine which ones are the most important to you. Especially Internet Explorer and Edge require extra efforts to support. By default, we have chosen to support the following browsers:
- Chrome
- Firefox
- Safari
- Internet Explorer (10-11)
- Microsoft Edge
We also check the sites on different devices, where the Apple branded ones tend to be the first to interpret sites differently. Included in our tests are always a big separate screen, the Macbook retina display, smartphones (iOS and Android), and tablets. Besides physical devices, we use Browserstack to emulate the ones we don’t have in the office.
4. Responsiveness
The second most common issues we find during website quality assurance have to do with responsiveness. The grids of the css frameworks we use take care of most of the responsiveness, but adjustments are always needed. The content sometimes fits poorly on a mobile device, with paddings, margins and alignment making little sense in the new proportions. Also, text may suddenly appear on top of a background image where you can hardly read it.
It’s also possible to create custom mobile designs, and in this case the responsive testing will be done mostly as part of the pixel-perfect test by comparing the result to the design files.
5. Admin page
The user-friendliness of the WordPress admin page is one of its key features. Therefore, the admin page needs to be checked as well to make sure that a user can understand where to update the front-end via the panels there. Hopefully the developer already made it easy, but sometimes it’s difficult for someone else to understand the logic applied.
Another check that should be done on the admin page is to review the dummy content and form submissions that were added during development and testing. You don’t want to deliver a site without “emptying the trash” first.
We also make sure there are no out-of-date or inactive plugins that shouldn’t be there, but only the ones we implement as default and those approved or requested by the client.
6. Code validation
In order to make sure the HTML markup is correct, we use the W3C Markup Validation Service. The errors here are not always visible from the front end, but they should still be fixed. Common issues are <div> and <p> tags that are lacking closing tags, or images without alt tags.
How to submit feedback to the developer
Now we have outlined how to look for bugs and issues on the site, but how do we report them to the developer? We have two different methods that have worked well for us.
The first one is our old friend “the spreadsheet”. We set up a template with tabs for different types of issues, and add screenshots in the first column, comment in the second, and developer’s response in the third.
The second method is to use UserBack, a screenshot plugin that we install on the site during testing. A visitor can then take screenshot, make annotations and submit their feedback. This ends up as a ticket, or card, on a Trello board for the project together with the browser and resolution data that the visitor used when reporting the issue. From there, the developer can move the card through the Trello “Kanban” board with stages such as “Check by QA”, “Ready for client review”, and “Done”.
Conclusion
Checking a site with a structured method can greatly help detect any issues before launch. As a reference, we spend around 3h to go through the process for a typical business site (or 5-10% of the time it took to develop), and it helps increase both the perceived quality and the total turnaround time of our projects by detecting issues as early as possible.
We are continuously improving the way we conduct our reviews, since no process is ever perfect. As soon as something slips through, we go back and review if the mistake could have been prevented.
The method outlined in this blog post should help you hit the ground running if you’re setting up a new process, or close some gaps in the process you already have. But don’t forget to take every opportunity to improve it.
