You have a new website! Congratulations.
You spent all that time choosing designs and colors – remember those back-and-forths with your team?
"Why do we need that in the footer”, “what about a hamburger?”, “does that flow make sense on the homepage?”
Maybe the work is over. Maybe you can kick back, relax, stop trying to find what’s wrong with that one CSS class or Wordpress plug-in that’s driving you crazy. Maybe, but probably not.
You wouldn’t label any creative work completed before a review period, so why you do the same with a website? If you're following the reformative website redesign process known as Growth Driven Design (GDD), then you are already taking steps towards continuous improvement and data-driven success strategies. So before you go ahead and launch that improved site, you need Quality Assurance (QA) – and not only a cursory “this seems good to me” look, but a deep and committed test period. There might be more than one QA Period. It might take a while. You will thank yourself for it.
There are a number of problems that inevitably turn up in QA. As someone that’s looked over many, many websites, here are the most influential mistakes that you should always look for in your site:
Major QA Mistakes
1. Mobile First Optimized Response Last
It’s easy to think that a browser might carry over features between its desktop and mobile versions. However, mobile and desktop versions of the same browser are often completely different browsers with the same name.
We don’t have to hit you with statistics of why thinking mobile-last is a problem (okay, here are one or two). Your website needs to be as polished and smooth in mobile as on desktop.
A common problem is recreating the site module-by-module on mobile. Luckily, you don’t have to worry about stripping down your mobile site to barebones anymore. According to Chrome’s User Experience Report, more than 80 percent of US mobile users today are on 4G. However, it is helpful to determine if each element belongs on mobile as much as desktop.
Are there any differences in use cases for your mobile vs. desktop site? Is it possible that you don’t need certain interactive features on mobile? Can you limit what kinds of elements are available?
Thinking through what’s truly necessary could save you hours of dev time during the QA process.
2. Browser Rendering
Each browser (especially the infamous and somehow deathless Internet Explorer) has different needs. If you develop in Chrome, there are bound to issues in IE.
Often, it’s as simple as a browser skewing a modules padding or margins. Sometimes, a page is entirely unintelligible. This largely depends on what type of CMS you plan on using.
The most effective way to determine if a page is rendering correctly across browsers is to display the page in every browser. Simple enough, right?
Tools like Browserstack, Cross Browser Testing, or End Test are all great codeless tools to test page rendering between browsers. Chrome’s Web Developer Tools also has a selection of emulators that can come in handy.
A note on CMS Types:
Typically, the more out-of-the box the solution, the less browser-to-browser problems you’ll encounter. However, out-of-the-box CMS solutions can also saddled you with low site loading speed, SEO issues, or few customization options.
If your website is a major element of your company’s revenue stream, investing in the web development hours to build and test your website makes sense. A customizable CMS will pay back dividends in enhanced performance and features
3. Not testing interactive elements and links
When revamping a site, there will inevitably be a temporary drop in Google rankings.The easiest way to ensure that the SEO drop is temporary is to look for broken links before launching.
For Google, 404s are like inviting someone to your party and locking them in the bathroom. It’s a bit of a – web and social – hosting faux pas.
When redesigning your website, it’s essential to manually test as many links as possible before handing it over to Google to be crawled. Once it’s crawled you can get an error report in your webmaster tools, but it’s best to let Google know you’re a great host off the bat.
Steps for Successful Testing Before a Website Launch
- Create a spreadsheet with a column of pages that needs to be tested.
- Create a header row of each browser popular with your visitors (check out the “Audience” tab in Google Analytics for more information on this).
- Look at each web page in each browser.
- On every page, test all links, elements, and modules. Determine if anything looks visibly off. It could be helpful to compare browsers to one another.
- If there’s something that looks off, take a screenshot and mark it in the spreadsheet.
- Rank the list of issues by their effect on site experience. Is the issue global across all browsers or only affect one? Is it a minor brand standard error or a serious usability issue? Is it a quick fix or a larger problem?
- Take each issue and create tasks for developers (or yourself). In each task, add as much detail as your level of expertise lets you feel comfortable with. Try to write out exactly how the current rendering differs from how the element should look.
Want to make this process easier? Here’s our QA template in an excel sheet. It’s easy to use, self-explanatory, and will save you some time.
Steps for Successful Testing After a Website Launch
- After a launch, the first step is for Google to crawl the website. It’s essential that you log into Webmaster, submit a sitemap to Google, and initiate a crawl as soon as the new website is online. If you don’t submit your site early enough, Google could mis-index pages and lower your rankings.
- Using Google Webmaster Tools, double-check there are no 404 errors on your site. If there are any errors, fix them asap.
- Each issue from pre-launch should be retested in the same browser to ensure no new problems emerged when the page was edited.
- Promote your website to draw in as many visitors as possible to create the most in-depth pool of data.
- Keep optimizing your website for continuous growth based on data and iterative changes.