Thursday, October 24, 2013

6 Tips for Website Pre Launch Testing

You've spent months (if not years) building that gorgeous new website. You are thisclose to launching it in all its glory, and you just. can't. wait.


But you should.

As the recent Affordable Care Act (ACA) website's technical snags have shown, thorough pre-launch testing is critical to the success of your project. But because you have been mired in the minutiae of the site for so long, it is easy to overlook even the most obvious tests.

I recently launched a Drupal-based website, and thought I'd share some of the testing protocol we followed:

Design Testing

Now, for this one I don't mean the design testing that happens earlier in the process, when you are getting feedback on the usability of your design (Paul Boag has loads of great stuff to say about this). I am talking about the review you undertake after you've done all your usability and design testing and made the necessary adjustments based upon the results. Among other things, it is a final review to ensure conformity with your design decisions.

Look at the main areas of your site to ensure they conform to your brand identity. Do your colors match your brand palette? Are accent colors and iconography used consistently across the site? Do all logos used meet guidelines for placement?  Have you secured the necessary usage rights for your imagery?

Content Testing

Your website should have a style guide. (It does, right?) Something that identifies style sheets for main pages. On our site, for example, we have attorney biographies. The content style guide for these pages includes guidelines for name use ("Use full name once, then refer to attorney by first name thereafter"); introductory paragraphs ("Single declaratory statement that calls out legal focus area"); and a taxonomy for practice naming.

On this topic, I strongly recommend rethinking how you write for the web. It is not just a digital version of your written materials, and if you keep treating web as just an extension of print you are going to lose your audience to someone who recognizes and adjusts to this fact. There are loads of great articles out there on writing for the web. Jakob Nielsen & co have a few here.

Content testing is also about:
  • Content that shouldn't be there. Are your empty tabs rolling up the way they are supposed to? 
  • Formatting: are Latin terms such as cum laude italicized?

You might also divide your content testing into static content vs dynamic content. If you are rolling out a brand new content management system, dynamic content needs an extra-keen eye. Transferring a database of thousands of records will always turn up weird little glitches, so you should set aside time for deeper testing. Run multiple searches on your dynamic content; are the correct records being returned? 

Functionality Testing

The objective of functionality testing is to verify the functionality of interactive elements and
hyperlinks. This area is probably the most time intensive. Every page needs to be reviewed for link testing and functionality testing. Some can be tested once and fixed globally. For example, if your logo doesn't take the user back to the home page, that is a global fix that doesn't need to be tested on every single page. Other testing, such as process testing, will require you test many pages. Process testing includes things like your calls to action. They typically involve a multi-step flow made up of if/then logic.

Other considerations of functionality testing:
  • Should your links open up in a new window?
  • If you use Contact Us forms, does the form get directed to the right person(s)?
  • 404 error pages - what will happen should a user stumble upon a non-existent page?  Here are BusinessInsider's 20 Best 404 Error Pages of all time; why not get creative with yours?

Performance Testing

How quickly your website loads, and how it behaves throughout the visitor's stay on your site, is what performance is all about. Typical performance tests are load tests (how many concurrent users can your website handle?), stress tests, and endurance tests. I'm not going to pretend to be well-versed in what it takes to optimize performance of a website- that's why I hired a fantastic agency to worry about this stuff for me -- and here is an article they wrote about testing CSS performance, and an even geekier write up on load testing is found in this Load Impact Blog post.
 
What I did worry about was general site performance. How long will it take my pages to load? Here's a handy tool I found:
  • Pingdom tests the load time of the page, and analyzes it to find bottlenecks (no surprise - imagery took up 58% of our home page load time).

 Browser Testing

I'm going to assume you've been tracking your browser visitors using your Google Webmaster Tools, and you know how users are arriving at your site. I also encourage you to be cognizant of what the environment is that your organization uses. Let's say, according to your analytics,  your site visitors overwhelmingly use Safari and Chrome, but your own organization (the folks who will visit the site on launch day and provide you with your first bits of feedback) all use IE7. Well, then I encourage you to be aware of what the site will look like (and how it will perform) on IE7. It matters.

I found browser testing to be the beast of all the testing. You can never - and I mean never - assume that because something works in Chrome (or Firefox, or IE, etc) it will work in Safari (or Firefox, or IE, etc). The  statement of work that you signed with your web design agency should have defined what browsers the site would be designed to work in. Even so, there may be elements of the design that your site will have issues with depending upon the browser. For example, our site was designed to work in IE, Safari, Chrome, and Firefox. And it does. But the parallax on our home page doesn't work in IE8. Should we have designed the site differently because of this? No; but we needed to be aware of what these issues were before we launched the site.

So we tested in all the aforementioned browsers, and fixed the issues we encountered. Areas to note:
  • PDFs may open differently depending on your browser, so be sure and test your PDF content
  • Print this page - we encountered similar issues as with PDF downloads; each browser rendered somewhat differently
  • Image alignment - there were tweaks needed with imagery on different browsers

Device Testing

What devices will your users be on when they attempt to access your website? You can start by looking at your Google Analytics for mobile % (I'd advise you look at trended numbers, because the % when we began the website redesign were much different than when we finished), but that won't tell you everything. Anyway, we all know we are screaming toward mobile, so what you really need to know is: what will my site look like on an iPhone? iPad? Galaxy? Kindle Fire? etc.

QuirkTools ScreenflyQuirkTools has a nifty little (free) tester called Screenfly. Just enter your url and it will show you
what your site looks like on a desktop (through 24" screen); tablet (Kindle, Galaxy, Nexus, iPad mini); mobile (Razr, Blackberry, iPhone, Optimus, Galaxy); custom screen size (you enter px, e.g. 1024x600); even television (480p, 720p, 1080p).

Your launch day should be a festive occasion. If you've done it right, it will be a day of exhausted smiles, shared congrats, and general revelry. BUT...even if you've tested the heck out of your site, trust me when I say you will be finding little issues for days after your launch. This is to be expected, and is totally manageable. Good luck!