The email arrives in your inbox. The one you’ve been waiting for patiently for months. It says:
You’ll be pleased to know we have completed build of your website. Please find below the link to your demo site. We will now move into the content population and testing phase of the project.
Or something similar.
After the oohs and aahs of the initial viewing of your shiny new toy have abated a cold, hard realisation sets in. You pull your crumpled, dusty, out of date project plan from the bottom of your filing tray (or bin). Hang on, it says here client to populate content. Then client to complete user acceptance testing. Then client to fully approve for launch. Then client to pay final invoice. You realise you’re reluctant to do any of those things.
That fear is the same fear we have for anything, it’s the unknown. To try and help combat that fear here are some things you can do to ensure you’ve tested your new website as well as possible.
Take content population seriously
The first part of the process is getting the content in and it often falls to the client to do this. Make sure the responsibility is clearly defined at the outset of the project so it doesn’t come as a shock! If you, the client, are undertaking it then your agency will usually train you on how to use the CMS. Make sure the right people (and enough people) attend that training. I’ve seen web projects falter many times because clients didn’t make the most of CMS training and then struggled later. It’s important you get on with population as soon as possible after that training, you should not have waited till this point to write or assemble your content. If you have then weeks will go by until you are ready to populate, by which time you will have forgotten your training and everything will be that much harder.
Make sure you have a content matrix
You probably created a sitemap at the beginning of the project. The document was probably not much more than a spreadsheet grouping page titles into sections so it’s a great idea to take that initial website architecture and layer onto it information about the content set for each template. This typically describes the different content areas that make up the template with word counts, image quantity and sizes plus any other information such as where links should be made and where they should point to. This makes content population much faster because you have a shareable document and it also makes testing faster because you can see at a glance if something doesn’t match the description.
Populate by template, not by page
It will save you a lot of time to populate one page of each template type first, not many pages of the same template. It makes it easier to spot errors or discrepancies without having to go back and make the changes many times. Once you know you have a perfect example of each template you can continue populating other pages with that template in confidence. Many CMS also allow you to duplicate pages so if you follow this method you can copy that initial page to give you a base and speed up your workflow. Remember also that as you test your templates you should do so in multiple browsers, you be surprised how many little bugs occur in one of Chrome, Firefox or Edge but not the others!
Use your designs as a reference
Assuming you’ve had designs created for your main website templates, they are the best reference you can use to guide you visually in testing the front end of the site. Viewing a live website as opposed to an image of a website does create some differences of scale, but otherwise everything you see in the design should be there and should match. If it doesn’t, make sure it’s raised as an issue.
Get your best detail-oriented person on the task
It might seem obvious but I’ve often seen clients really struggle with testing because the task has fallen to the wrong person and no one is prepared to just be honest and say that person shouldn’t be doing it. Your agency will probably spot this is the case, but they may think they’ll upset someone if they raise it as an issue. Get the person who is best at proofing copy and has an eye for visual detail to be your main tester and be aware of signs that testing by your own people might not be getting done right.
Testing on mobile devices
If a specification was created at the outself of the project then it should have contained information about how the agency were building the site for mobile devices and the parameters around testing for it. This is one of the most difficult areas of testing, new devices are constantly being released and mobile operating systems and browsers are constantly being updated. It’s sensible to apply a bit of an 80/20 rule to this. If the site displays correctly on the latest versions of iOS and Android then you’ll have covered the vast majority of your audience. If you are re-developing an existing site then Google Analytics data can be used to benchmark this, rather than guessing. Is Blackberry or Windows Phone important to you? If you know important clients of yours use Blackberrys then maybe it is, in which case it’s worth you paying for specific testing on those devices if it wasn’t included in your original specification. It’s unlikely your site will look horrendous on any modern device, so ask yourself where the value is in raising many bug requests on obscure devices just because you can. You’ll just be using up time and energy that could be spent on more valuable tests elsewhere.
Functional testing is often the most laborious task, because it can’t be done just by sight, some errors are not visual. So it requires enough knowledge of what is supposed to happen to allow you to work through a process checking every stage. For something as simple as a website form, this still needs to be done thoroughly, checking things like the validation (error msgs) for each field as well as that the form submits correctly, displays the correct success message, emails the form data correctly and is also being saved in a database. For more complex processes like e-commerce this is far more time-consuming. One thing you can do is work with your agency early in the project to create test scripts. These are simple descriptions of processes which cover the detail of what should happen at each stage. It makes testing much faster and means you don’t miss things because you didn’t realise they were supposed to happen. There are often a lot of variables with these processes (and/or scenarios that change the outcome) for example different types of discount be applied to a checkout process so having a script which tells you what those variables are is a huge timesaver.
Performance testing is an area that clients can’t achieve on their own, but that doesn’t mean you can just ignore. Factors like page load speed, accessibility compliance, or the load being place on the webserver by making requests to APIs or other external data sources all impact your site’s ultimate success. A lot of these items will need to be tested by the agency using software tools, but if you notice poor performance, don’t assume it’s your internet connection having a funny five minutes, make a note of it and test again the next day, or try it on a different computer which you know has a reliable connection. If it persists, ask for it to be looked at. There are no hard and fast rules about performance, if you have an image-heavy site it is going to perform worse for load speed than one which doesn’t have full-width images, the most important thing is to measure this ongoing and make sure the trend is at least stable.
Every agency works differently in terms of their process for managing your lists of amends to the site. These are usually referred to as “bugs” and the whole process is often called “snagging”. Hopefully common sense will tell you that it’s more efficient to provide complete lists of amends rather than emailing them one at a time. It’s a frustrating but inevitable result of web development that fixing one bug sometimes creates another somewhere else. You shouldn’t blame your agency for this unless you see the same bugs recurring time and again when you have been told they’ve been fixed. If you do then it suggests something is awry with the way it’s been coded. Many agencies will operate a ticket system to log your amends via a software platform such as Basecamp, JIRA or Workfront (others are available, I’m not endorsing these ones!). These can be very useful, but even if you’re just using an Excel spreadsheet make sure you and the agency have agreed a method by which you can see the status of each item. There is nothing worse than getting in a muddle about what is ready to be tested and what is not. Wasting time doing unnecessary tasks is the biggest danger to successful testing. It’s boring anyway, but if you find yourself re-testing constantly your brain will switch off and you’ll start to miss things you should be picking up on.
Final checklist for launch
The final process for launch of your site will be handled by your agency. But you should still have a level of oversight and it’s actually a lot more complex than you think. It isn’t as simple as just “switching it live”. Here’s a handy list of the key things to make sure have been done before you give that final approval.
The key items that tend to get forgotten are making sure that all tracking and reporting is in place. That should be more than just making sure the Google Analytics code snippet is in place, are you properly tracking goals? Does everyone know that all your digital publicity should be using proper tracking links so you can measure where you’re getting conversions from.
There is a key tie-up between your website and your marketing effort to be preserved at this point. Often you’re running short of time and under pressure to go live, but make sure you have got these details right or you’ll regret it in the long run.
This is especially true if you are re-developing an existing site that has considerable equity with search engines. If you lose that equity through launching a site which has issues with how it is viewed by Google then you could have a disastrous drop in visitor numbers which could take a long time to recover from. It’s also true if you’re running successful PPC campaigns and spending a significant media budget. You need to know the new website isn’t going to harm your conversions, when it should be improving them.
Giving that final approval
When the time comes to give the instruction to launch, my final piece of advice is not to sweat about it! If you’ve followed all the advice above then you’ve covered the important stuff and you won’t be in bad shape. There will so much that’s shiny and new for your customers to look at that they’ll forgive you the odd tiny blemish for the first few weeks. What is important is that you don’t rest on your laurels. The minute the site launches and you start changing content or adding pages you are altering the site and that means testing it again. Make ongoing website testing a part of your marketing culture, make sure learnings are being taken from your analytics and small improvements are being made as a result. A healthy website is all about continuous improvement. Launch was only the beginning.
At Agency Interface we help brands work effectively with digital agencies.
We do this by helping our clients understand the fundamentals of modern digital web design and marketing and helping them work with the creative community who can make it happen. Our success is measured in the time and money that our clients save in getting the right people doing the right work and taking away guesswork, frustration, miscommunication and wasted time. Chat to us today to find out more about how we can help your brand.