It is often said that no web project is the same and when applied to the testing of web sites the truth remains.
With respect to the above statement, I have put a general testing process together that I normally look to follow, which looks something like this:
Plan testing at the start of the project – allocate the right amount of time for testing, if you are not sure how much time you need then make your best guess and double it. Always allocate more time than you think you need. If you have the time now then write a basic testing plan at the start of the project because this will give you an idea of how much time you will need to carry out all of your testing.
Testing plan – when we prepare to start projects we don’t always have time to complete all the supporting documentation and the testing plan is one item often put off to later. Try to write your testing plan early on but definitely before you start testing because then you know all the items that you are going to test and do not head into the actual testing without really knowing what you are testing.
Development – as the development of the web site comes to an end, I start to casually check it over, not really testing this point but just seeing if there are any big gaps in the development and asking the developer questions to make sure he/she is aware of items they have left to complete. This is really used to find out how far off finished I think the site is versus how far off the developer believes it to be. If this exercise sets off any alarm bells because of any huge holes or missing functionality then hopefully there is enough time to put things right.
Once the developer has completed the web site I make sure that they have tested their work first, including browser compatibility so that they are comfortable before they hand it over to me to test. This is important, as I believe that developers should make sure they test their work in the first instance and do not waste my time with anything that they have not tested. If I hit too many problems in my first round of testing I normally stop and hand it straight back to the developer with what I have noticed so far. I ask them to finish the web site and give it to me when they have tested properly and not waste my time any further.
It really depends on your relationship with the developer or development company on how you go about this. With some developers I will be blunt and others I will be more diplomatic and tactful. The way I approach this also depends on the timescales that we are running to and how the project has been going to date. If we are really up against the deadline and/or it has been a difficult project then I will be a lot more accommodating with the developer and go through problems with him/her so that they feel that we are all together trying to get this web site finished on time.
If the work is below par and time is not so much of an issue then I will be blunt and ask them to only give it back once they have properly tested and not waste my time testing sub-standard work.
Carry out testing – I often complete my testing in rounds so that I go through my testing once, find a load of bugs, get those fixed and then carry out a second round of testing. This second round is used to not only check that the bugs from the first round have been fixed satisfactorily but also to delve a bit deeper into areas that perhaps I was not able to test fully the first time around (usually because the presence of bugs preventing me from doing do).
This can be time consuming to carry out testing in rounds, especially if you have to wait for bugs to be fixed before you can complete the next round of testing. However, I believe that it ensures that the majority of the bugs are picked up. If the web site is more complex then generally you will need more rounds of testing before you can be confident that you have found everything.
Once you are happy that the web site has been fully tested and all bugs have been captured (or as many as possible) then it is case of getting as many fixed before the deadline and you will probably have to prioritise.
Prioritise – If you are running out of time then you will need to decide which bugs absolutely have to be fixed ahead of launch and which can wait until after launch or be fixed at a later date. This is crunch time and the worse case scenario here is to move the launch date back so that any showstopping items can be fixed.
This is where using a bug tracking system can be hugely beneficial, as you can set priorities for each bug and then understand how many bugs you have at each priority level. It gives you a much better understanding of how many bugs you have to fix before you can launch and calculate how long you expect that process to take.
Launch Checklist – So you have fixed all the bugs that you are going to fix before launch and now the launch of the web site is upon you. I find it hugely beneficial to prepare a checklist of all the steps that we need to go through in order to launch the web site or final checks that need to be completed so that I can be confident that all is well when launching.
The length of this checklist will be greatly dependent on the complexity of the project, for some projects it may only be half a dozen to a dozen points and for others it could run into a lot more. A series of projects I managed had launch checklists of over 50 items with pre-launch, launch and post-launch sections.
You can have a standard checklist that you adapt for each project you make live such as whether the site you are launching is new or replacing a current site and if it is replacing a current site whether it is launching on a new domain name or not.
What are you going to do with current subscribers, have you checked that your Google Analytics code is in place, do you need a holding page to go up and, if so, has this been readied and signed off by the client for use? There are a lot of final items such as these they need to be checked over and should not be missed because, during the pressure of making your web site live, missing one of these items out could make all the difference.
Post Launch – The checklist that I maintain has a number of items on it with regards to post launch. There are some checks that I carry out a day or so after launch to ensure that the site is running smoothly and all is well. There may also be a few bugs or improvements to finish off that you could not squeeze in before you made the site live.
Ongoing – There may also be some ongoing tests that you wish to carry out from time to time to ensure that the continued operation of the web site is successful. Just because you launched successfully does not mean that the web site will sit there happily letting visitors browse and register and login and do whatever without throwing a wobbly from time to time.
The busier your web site gets (and I hope it does get busier) the more issues could be made apparent by the site slowing down or not being able to cope with the visitor levels hitting the site. Reviewing your web site analytics and server logs can give you a good picture for what is happening and also some regular site monitoring can give you an indication of when your site hits problems.
If you carry out any updates to your web site then these will need to be retested each time before going live and could potentially introduce further problems so ongoing and continued testing can be important.
Client Acceptance Testing – of course, throughout the above process you have to consider the client. I have specifically left the client out of my description of typical events above because it depends on who the client is in your situation, whether the web site is for you, for the organisation that you work for or a traditional agency/client relationship. Whoever the client is they will need to review and approve the web site before it is launched.
Please let me know if you have any feedback on this typical web testing process, if you would add anything or if you disagree with any items above, all comments are welcome.