How to Test a New Website

How to Test a New Website

In theory, testing should be extensive, thorough and iterative. However, the reality can be far from the theory unless testing is properly planned for and understood.

Testing is so critical it can be the making or breaking of a project and is something which needs to be completed using solid ‘formal’ processes.

Ok, so what do we mean by formal?  Well, firstly both you and your web designers will test the new website independently of each one another.   (This is known as Alpha testing when done by your developers and Beta testing when it is done by you). In both cases, you will test every piece of functionality making sure it is behaving itself.

Some design agencies, like ourselves, will provide you with online systems to enable you to track any issues (we use Basecamp externally and Atlassian’s JIRA internally).  However, you can track it manually: We recommend that you create yourself a table which tracks any issues and enables you to share your findings with your web designers). Here’s one to start you off:

Beta Test Issue Capture List

Alpha Testing

We conduct Alpha testing as part of our development process and is factored into the timescales.  We do this just to make sure we’ve ironed out any obvious omissions or bugs. Typically, this is done by a developer who has had nothing to do with the project as a fresh pair of eyes often spots things that have been missed.

It might be useful for you to request a copy of your web developers Beta test results just to cross-check any functionality you (or they) may have missed. (Be prepared for them not to have extensive records listing every aspect of the system – they may have tested the same elements many times before.) Although, if one is being pedantic, it should be tested again but the likelihood of something failing which has worked in ten other projects is probably quite remote. You may end up with just a list of elements that were tested but which differed from the standard or core CMS.

A quick note on Browser Compatibility

Browser Share 2016 Pie Chart

Current browser market share (2016)

There are many different browsers on the market today; Internet Explorer, Chrome, Firefox, Opera, and Safari to name but a few. Each interprets HTML slightly differently which results in your web page looking slightly different in each one. To complicate matters further there are various versions of each of these browsers still out there in the market. Most web designers have a standard set of browsers that they will check your website in, but you may, however, need your site to work in others including; Blackberry and old versions of web browsers. (The need for any non-standard browser choices should have been picked up in the specification phase.)

Beta Testing

Once the site has been Alpha tested it’s ready for you to get your hands on it!  This will be in the form of a web address to the front-end and a separate one for the Content Management System (usually the same but ending in /admin or /logon, etc.). It is unlikely that it will be your actual domain name as it’s more likely to be a link to your web designers’ development server.  (At digitalROAR we have three sets of servers; a “development” server which is used to build the website, a “staging” server which replicates the live environment (ensuring that the site will work perfectly once it goes live) and the “live” environment which the finished website is moved to when live.)

before you begin the process of testing you’ll probably need some training on the system first

However, before you begin the process of testing you’ll probably need some training on the system first. It’s possible that there will already be documentation (especially if it’s an off-the-peg system) but it is more typical to find that training is either face-to-face or over the phone. Whichever way it’s done it’s good to get some training under your belt as it will accelerate your testing and content entering.

Here are a few of the things you might be checking for:

  • Can I add/edit/delete a page?
  • Can I reorder pages?
  • What happens to the front-end if I put too much text in?
  • Do specific functions work (sorting data, wrapping pictures around text, etc.)?
  • Does the video look right on the page when I upload a movie?
  • Do the forms work and send their data to the right email address/external system, etc.?
  • And so on…

As you progress through your testing you’ll find that your observations fall into 3 categories:

  • Bugs (failure of the system to work as intended).
    • Don’t expect to pay for these.
  • Interpretation of specification (sometimes, no matter how clear you think you’ve been someone interprets what you’ve said differently).
    • This can be a grey area with respect to charges. You’ll probably need to clarify whether you’re going to be charged before getting your web designers to make any changes.
  • Change Request (even the best-laid plans of mice and men can sometimes end up changing!).
    • If you’re making a request outside the parameters of the specification, expect to pay more but do make sure you get a quote in writing first.

Use the table we provided above (or your web designer’s online project management tool) to enter your results and feedback to your web designers. However, it helps if you can get the testing done all in one go as this enables the bugs/issues resolved much faster.

Remember that although you may have given yourself time to test you also need to allow for some time to fix any bugs and make any change requests. 


NEXT: Entering Content: Your Website Content Hero

Published by digitalROAR