This week, I downloaded a new app for my iPad. It looked great, but I should have taken more notice of the online reviews. Several users had reported that the application crashed often, and sure enough, it does. That’s because it hasn’t been tested properly.
I’m sure that you have had a similar experience – a website that didn’t perform as you expected, or a product that didn’t do what you thought it would. You don’t need a product to make testing to be important; it can even happen with processes. If you have ever tried to get something done through a government or regulatory body you will know that many of their processes are not customer friendly, so perhaps they didn’t get as much testing as people using them would like.
Testing is a really important part of any project, so you should routinely make sure that a testing (controlling & monitoring) phase is included in your project plan. Here are some more reasons why testing should appear on your project schedule, and some tips on how best to incorporate it.
Testing Uncovers Errors
It sounds obvious, but if you don’t test the deliverables from your project, you won’t find out if they work or not! Too often we take it for granted that our wonderful project has produced something fantastic, without bothering to check if it really works.
The purpose of a testing phase is to uncover all the errors and bugs. Taking a structured approach to testing means that you can methodically work through every area of the project ensuring that it is as good as possible, and that the end product will be top quality.
Testing Shows the Customer What They are Getting
The best way to do testing is to involve the key stakeholders. These are the customers of the end product and as they will be the ones mostly using whatever your project is delivering, they will be the ones who will decide if it is fit for purpose.
Carrying out tests shows these users what they will be getting. This is a great opportunity for you to get some feedback. Typically, when users ask for something, such as a new website, they don’t know exactly what they want it to do until they start using it, which is why prototypes are often used in the early stages of product design. By the time you come to testing, you should have a product that is near enough complete, but not so polished that you can’t make changes to it. Finding out what the users want changed at this point is much better than delivering something complete and then finding out that it doesn’t meet their needs.
Ideally, your project team members who represent the key stakeholder groups will help with testing, but you might want to involve a few extra people on a short term basis as well.
Testing Can be Routine
Testing can be laborious, and it is certainly detailed work. If you are testing a website, for example, you’ll want to check every link works as it should. Every time you change something on the website, you’ll have to check that the change hasn’t broken anything else – and that means testing everything again, not just the bit you changed.
You can make testing more routine by making it as structured as possible. Have ‘standing orders’ for testing in the form of task lists or mini project plans. Create test scripts that you can use time and time again. Ideally, you want to make all your test activities as standard as possible so that you can repeat the same tests later in the project if you need to.
Creating standard documents and templates for testing tasks will be a real time-saver. If you store them in a central document repository everyone on the team will have access to them, which means that everyone will not only be able to see the latest test results, but also use them to carry out their own tests. Get team members to share their project test documents so that others don’t have to create their own.
The easier you can make the administrative overhead of testing – documenting what is to be done and capturing the results – the more likely it is that you will complete more tests in a structured way, and the better the product at the end.
Testing Can be Continuous
A testing phase normally comes after the product design and build. At this point you have something concrete for someone to test. You then have a period of refinement, bug fixing and final build before the product is complete.
Unfortunately, testing is normally the thing that gets cut if a project is running late. If your project dashboard shows that you are taking more time than you anticipated, you’ll be looking to make savings later in the project. Project teams often choose to shorten the testing phase as this can be quite a substantial period of time. However, this is a false time saving, as if you don’t uncover the bugs now, you’ll only have to fix them later which will probably take longer and cost more.
An alternative to a fixed period of time on the project schedule for testing is continuous testing. This is where each component is tested as you go. If you can get someone on the project team dedicated to testing then they can focus on testing each area and how it integrates to other areas, as well as co-ordinating ongoing testing activities for the business users. Running testing in parallel to other project activities can save you time and help you identify errors earlier, so it is worth considering if you think it will suit your project.
Testing is a critical part of any project, and how you incorporate it into your project schedule is up to you. However, the key thing is that you do it! Ignoring testing will put the success of your project at risk and you are likely to end up delivering something that doesn’t do what your stakeholders want it to.