3 Reasons Why You Should Plan Your Testing Phase

Hands up who has ever had the testing time on a project squashed until getting everything done is a rush?

Yes, thought so.

Experienced project managers know that testing is one of the project phases that gets squeezed at the last minute, especially on projects being managed in a waterfall environment. Sometimes the lack of testing time is out of your hands. Sometimes it is down to poor planning and not being able to say no to stakeholders who want to pack more into the weeks before the delivery date.

However, if the testing can’t be completed effectively, you may not get the solution you were hoping for. So how do you get around this? You have to plan your testing activity and protect it, so that the test team gets the time they need.

You may have to convince vocal stakeholders that you can’t do more on the project right now as the testing time has to take priority. Here are 3 reasons that you can use in your conversations, to help explain the importance of testing.

Reason #1: Testing is how you spot errors

It’s not rocket science: testing is the way you find out what doesn’t work!

While we’d all like to think our development colleagues get everything right the first time, in reality, that’s not always the case. You need to test your deliverables to make sure that you are getting the results you are expecting. Whether that’s website response times, the quality of bricks off a manufacturing line or something else, your stakeholders deserve to have confidence in what you are providing for them.

Testing is how you spot the errors. A structured approach to testing, as managed through a test phase, is the way to do it. Methodically working through the various processes and deliverables gives you a solid base for being able to say you are delivering what you said you would.

Reason #2: Testing demonstrates what is being delivered

It’s common practice to involve stakeholders from the relevant areas of the business in the testing activities. Ultimately, they are the people who will be using the end result day to day. They know what it is supposed to do and how it is supposed to work.

Testing shows the users what you have done and lets a wider group of people see the product. You don’t want to be opening the floodgates to any and all kinds of feedback at this point. But there might be some feedback that you want to take on board.

It’s far better to receive this feedback now – about the end product and also the user manuals, guidance notes etc – than to deliver something and find out that it isn’t what the team wanted.

Reason #3: Testing shows you how the system will be used

Testers haven’t been involved in the development, especially if they are business users. The testing phase is a great way to check that you have listened appropriately all the way through the project. You should have been regularly involving business users to ensure you are delivering what they want, in a way that works for them.

Testing is the point where you can check that you have got it right.

While you might know exactly what button to press on the new software, a tester won’t. These are people who can seriously road test your product. They’ll tell you if they understand the instructions. They’ll input the wrong data just to see what happens. They’ll try to break your deliverables because they know one day someone will do exactly that inadvertently.

Testing shouldn’t replace a deep engagement with business users throughout the development phase of your project, but it can be a good sense check to make sure your deliverables are fit for purpose.

How to Plan the Testing Phase

The ‘normal’ way to manage testing on a non-Agile project is to build in some time after the project design and build is complete to do the testing. Project managers commonly plan several test cycles. A test cycle allows you to do the testing, fix the errors, and test again to check they were fixed. Running several test cycles allows you to test everything multiple times. This is helpful to check that a fix to one area hasn’t thrown up a problem elsewhere.

At the end of the testing phase, you should have a product that is good to be released to the end users. Here are some tips for planning your testing work.

Make testing as structured as possible

Write up test scripts that document what actions need to be done to test a function. Then you can use the scripts each time that functionality is tested. This gives you standardization and structure, and guarantees repeatability if someone else needs to carry out the test for the second time.

Give everyone access to the test results

Get team members to share their results with each other. An extra pair of eyes can spot something new. Sharing your work also means less need to start from scratch. It’s quite likely that a colleague has created a document that you can use for your own testing.

Leave enough time

Testing is detailed work. It can be time-consuming. Many features impact on other features, and changing something small may have ramifications for other functions somewhere else in the product. Software projects especially suffer from this. So plan enough time to go through everything carefully. Then add some contingency time on top!

Use software testing tools

If you have access to software testing tools, use them. Test software can automate the routine tests for you. It can capture and store test results. It is such a time saver once it is set up effectively.

Don’t leave it all to the end

You don’t have to wait until the end of the build phase to start testing. Where you can, test components as you go. Run testing activities in parallel to other work. This can help you spot errors more quickly in the development cycle and fix them before you get too far into the project.

Project testing is such an important part of your work as a project manager. You might not be doing the testing yourself (or you might be – project managers tend to pitch in when needed!) but you can definitely help your team by protecting their testing time.

Testing might look like a big chunk of time on your project schedule, and it’s tempting to cut into that if you hit other problems on your projects. However, that’s not going to save you time in the long run. All it means is that errors will still be there at the point you go live, because you haven’t spent enough time hunting for them and fixing them. Then you’ll have to fix the bugs later. Submitting changes late in the project, especially after the build work is finished, can be costly.