Watch this short project management video to see how to ensure testing is working in your project. Particularly useful for software development projects.

Tweet

Transcription

Hi, I’m Devin Deen, Content Director here at projectmanager.com. Hi. Thank you for joining me in today’s whiteboard session about how to get testing to work effectively on your projects. The thing you want to remember about testing activities, is they need to be planned in throughout the entire project life cycle.

You can’t hold up your testing activities to the end of the project and expect to have a good outcome in terms of high quality deliverable and hitting your deliverable due dates, your timelines. What I like to think about as a rule of thumb is using about 33% of your overall project budget, project schedule, project resources dedicated to testing activity. That’s a full third.

Those activities can’t occur just at the end of the project. They have to occur at the start of the project, at the middle, and also at the final end. That 33% is spread across the entire project, but on average it’s about a third of your project’s dedicated testing activities.

These activities go so far, as an example, coming up with your test plans, coming up with your test scenarios, actual execution of your test, a little bit of rework, and finally, updating your documentation as you have updated the software that you might be delivering. So, it’s all those sorts of activities related to testing. Overall it’s about a third of your project budget, schedule and resources.

You also want to agree your acceptance criteria at the start. If you’ve got a requirements document, maybe a design document handy, once you have those there, it’s really the time to start coming up with your test scenarios and your acceptance criteria for deliverables. Certainly, you don’t want to come up with those acceptance criteria whilst your project team is in the build phase of their project. You want to agree those up front.

Believe me, it’s much better to have a debate about whether a screen should be blue or green before you actually build it than at the end of that build cycle. Get that acceptance criteria agreed up front in terms of your functionality and your non-functionality, or your performance of whatever it is you’re building, be it software or be it a product such as a machine. Make sure you get those acceptance criteria agreed up front.

Also, get the right test resources. Testers approach a particular product or software that might be developed in a different way than a developer would be approaching it if they were doing the testing. Developers want the test to succeed. Testers actually want that test to fail. Their job is to ensure quality in the project, in the deliverable that you’re providing.

So they’re going to approach testing in terms of the scenario that they develop and actually how they execute the test, much differently than it would be if it was the developer who actually developed that software or that product for you. Make sure you get the right resources. If your project can afford it, get a test manager assigned to you.

Initially, they’ll have a lot of activity to do at the start of the project. Down the road, they can just direct the testers in doing an execution of the test scripts. Definitely make sure you get the right test resources on your project team.

Next, always allow for at least three cycles of testing on your project. You’ve got your own unit testing if you’re doing software development that your developers do. But beyond that, they’ve got systems testing, which is one cycle of testing. Next one would be integration testing, so that’s a separate activity and, once again, another set of testing outside of systems testing. So that’s your second cycle. Lastly, user acceptance testing, and that’s your third cycle of testing.

If you’ve got three cycles of testing built into your project schedule, built into your project budget, and allocated the right resources to execute and support that testing, then certainly you’re going to go a long way to ensure the good quality deliverable that your project has been asked to produce, and also hitting your deadline for delivery. Make sure you’ve got those three cycles.

Use a defect tracking tool. A spreadsheet is certainly not going to cut it in today’s software that’s being developed or products that are being developed with all the moving parts that you might have. Use a defect tracking tool. These are great online collaboration software that’s out there to help your developers and your testers put the defects into the tracking tool, update activities, update test results, and also it automatically tracks the open and closing of those defects that are in the tool.

By automatically tracking the metrics around those defects, you can also report on those and get a sense of where the health of your deliverable is in terms of quality, as well as your likelihood to deliver on time for that particular project that you’re delivering. When you’re tracking those defects in the tracking tool, the metrics automatically pop out. Quite often they’ve got reports that are pre-canned, then help you get a good sense of where you are in terms of quality of deliverables.

One last thing to say about planning and getting testing to work effectively for your project is, once again, planning in it from the start. I can’t hound that point in enough. If you planned in all the test activities in your project budget, in your schedule, and with the right resources from the start of the project, you’re certainly going to have a higher degree of likelihood for delivering that quality project on time for your clients.

For more project management whiteboard sessions and all your project manager needs, come see us at projectmanager.com.