It can be pretty daunting before you set out to test a web site because it is important to get it right and to have a smooth launch with no bitter aftertaste of experiencing bugs once the web site is live.
This short guide will hopefully give you an idea of where to start so you can successfully prepare for and carry out the testing of your web site.
The first thing to do when testing any form of web site or web application is to get organised, especially if testing is relatively new to you. There are a number of things to have in place before you start testing that will make your life a lot easier and help you to stay organised throughout the testing process.
Ensure You Have a Testing Process
If you have a small development team then the process to follow of finding bugs, fixing bugs, checking they are fixed is fairly straightforward. Larger teams may get a bit more complicated but let’s start at the basic process. This assumes that you are going to use or already use some form of bug tracking software, such as Bugzilla or Unfuddle.
The above process is about as simple as you get, just 4 steps to follow and the process assumes that you have just the one Developer and one Project Manager who is testing, assigning bugs and checking the Developer’s work.
Add in another Developer or several Developers to this process. All the Project Manager needs to do is when he or she finds bugs to assign them to the most relevant Developer. So you might have organised one Developer to work on a particular section of the site or quite often one Developer will work on the front end whilst another works on the back end admin system. This then makes life easier when assigning bugs to Developers so they do not step on each others toes when fixing bugs. Even with source control it can happen where code gets overwritten or mistakes creep in when Developers are working in the same section.
So now we have a Project Manager and several Developers in the testing process. What about if we add in more people testing? You might have several project stakeholders wishing to test and offer their feedback or you may let the designer review the site and offer feedback regarding how the finished site corresponds to the original designs that were completed.
The ideal situation is that all people testing use the same bug tracking software, enter any bugs they find but ensure that they assign the bugs to you, the Project Manager. All bugs from other sources need to go to one person to review them, weed out any duplications that are already being worked on, organise who the bugs are going to be assigned to and set priorities (see below about setting priorities).
If you cannot get people to use the bug tracking software, and let’s face it bugzilla’s interface is horrible so some people just refuse to learn it, then make sure they prepare a list and give that list to you, in an email if necessary. You then need to add those bugs into the bug tracking software yourself but it does give you a chance to review them along the way.
You will easily be able to see how many bugs are at each stage of the process, i.e. assigned to Developers (effectively in progress), resolved and assigned to you for checking and closed.
The final point to add with regards to the process is if the web site you are testing is for a client. It is up to you whether you update the client on all bugs found and being worked on and most bug tracking tools allow the export of all bugs so you can send a full update to the client. Some web based bug tracking tools even allow the client to login so they can see exactly what is happening.
Prepare a Testing Plan
Getting a testing plan down on paper helps to set your mind on what actually requires testing and allows you to think things through properly so you do not run the risk of missing anything out.
It can often happen when you are short of time with the deadline fast approaching that you just ‘start testing’. This is often a false economy because you launch yourself into the testing and miss important items because you did not take a step back to think it through properly.
Take a few minutes and start putting down the items that require testing. This should really consist of each expected outcome, for example, you click on a link and what do you expect to happen? If it is an add to basket link on a product page then the expected outcome would be that the product is added to the basket.
For large web sites this approach is time consuming and ends up being a very long list. If you are short of time then cut this down to list the main elements that you need to test or at least go through every page on the site.
For content managed web sites or sites that have an admin system it is often helpful to split the testing into the front end web site and then the functions within the content management system as a separate set of testing. By doing this you can concentrate first of the web site that the general public will see and make sure that is right and then focus on the CMS to make sure that works correctly for whoever will be maintaining the web site.
Your testing plan should also take the original specification for the web site project into account. I am assuming that this specification was updated during the project to incorporate any changes requested and so is up to date. If the specification is not up to date then it gets very confusing very quickly when you reach the testing stage.
You can run through the specification and list out the functionality stipulated into your testing plan with the expected outcomes being as the specification described. When you test each item you can then make sure that the web site works in the way that the specification envisaged. If the web site is different from the specification then you can go back to the developer to ask them why and either get it changed to how it was originally specified or retain the existing functionality whilst preparing your response to the stakeholders as to why it is different.
Another set of items that your testing plan should accommodate are any signed off designs that were completed. The site should be tested against these designs to ensure that the layout, style and specific design elements that your designers sweated over have been carried over correctly to the site build. It can often happen where developers have not been quite so careful on replicating the exact layout that the designer worked hard on and, even if there are only minor discrepancies throughout the site, these all add up to a web site that is not as good as it could be.
Finally, make sure your testing plan includes all the items outside of actually clicking around the web site. For instance, what emails does the web site send out? Make sure testing each of these emails is in your testing plan. Do you need to test that the HTML is standards compliant? Make sure this is in your testing plan. Have you listed the browsers you are going to support in your testing plan to make sure you test in each browser?
Get Your Testing Tools Together
In order to keep your momentum up once you start testing, prepare the tools you are going to use in advance. Browser testing can be completed in a number of ways, from having a set of machines available with each browser version installed or using a browser testing tool such as Xenocode or Browsercam.
If you have these tools ready before you start testing then you can easily hop onto another browser and carry on testing without having to stop, work out how you are going to continue, get it organised and then start again. Too many of these interruptions really adds time to the overall testing phase of the project.
That is a fairly quick run through of things you can get in place before you start testing that will help you save time and confusion whilst you are in the thick of things.
Let me know if there are any other items that help you to test that you can prepare for in advance.