Photo by David Clode on Unsplash

How Do I Implement A Test Plan Successfully On My Software Project?

31 Steps To Ensure Successful Testing From Start To Finish

Test Planning — It’s Never Too Early

1. On a software implementation project testing is a critical activity prior to cutting over to production.
2. This is very late in a project after analysis, design and implementation.
3. Despite this you should start test planning as soon as the project starts.
4. If you wait until the testing phase to create a test plan you are introducing unnecessary risk to your project.
5. Testing relies on many things. And many of these can be predetermined before testing starts.
6. You should know what is going to be tested. Is it the whole application? Is it just the core use-cases? What are the core use-cases?
7. Your tests should be written down, preferably as test scripts specifying the expected outcome for each test and the steps to get there.
8. You should know who the testers are going to be. More importantly, they should know what role they are going to play in testing. Are you testing infrastructure? Performance? Application functionality? Interfaces? Generally different people are responsible for these things.
9. You should set an expectation for when testing is going to occur. Business analysts are often responsible for testing on projects. The rest of the time they’re responsible for their actual job. Testing on your project is on top of their actual job. Expect them to be at capacity before you even ask them to test and do your best to be reasonable and accommodate them.
10. How are you going to track issues that are uncovered by testing?
11. The goal of testing is to uncover issues. It’s much better to find them now than later when the application is in production.
12. You should be prepared to encounter any number of issues. You’re method for tracking issues doesn’t have to be fancy, but it does need to be able to track one issue or one hundred with ease.
13. Included with each issue should be a priority. Critical, high, medium, low. The priority should be specified according to the issue’s impact after production cutover.
14. Know what done looks like. Is the goal to clear every issue or is it to clear enough issues? (“Enough” is usually measured by clearing a certain number of issues based on priority). A common threshold is to clear all critical issues and have a clear path to resolution for highs and mediums post cutover.
15. If you’re not clear on the plan, the rest of the team probably isn’t either.

Start Testing — Executing On The Plan (And Tracking Progress)

1. Recognize that the people who are testing don’t do software projects all the time like you do. They may need your guidance to understand the “why” behind the testing. Many consumers assume the software should just “work.” I put my CD-ROM into my computer and Microsoft Word works so why doesn’t this software?
2. Once you know who is testing, what they’re testing and when it’s time to start. It’s a game of staying within those parameters.
3. Users test, log issues and you resolve the issues. Pay attention to your rate of issue resolution.
4. Meet to review the issue list regularly. Focus on highest priority items first. Review each one. What’s changed since last review? What’s expected to change by next review? Are there new issues to track?
5. Tight testing window? Better meet and review even more regularly. You’d better make progress easily measurable.
6. When reviewing the issue list ask what percent complete is testing? If you do not get a clear answer testing is very likely to not be occurring or occurring at the rate it needs to in order to finish in time.
7. If zero issues are reported, testing is likely not occurring. Consider this a risk and socialize it.
8. Testing generally occurs at a flat rate. Don’t believe people who say they can get 80% of the testing done in the last 20% of the schedule. They’re wishful thinkers. Besides, back loading your testing adds a ton of risk.
9. Front load testing in the schedule as much as possible. If it’s determined to be “not possible,” question what’s possible. Don’t take it at face value.
10. Include a buffer week (or more) in your testing schedule. Something always comes up.

Wrapping Up Testing — Landing The Plane

1. As you near the end of your test cases, if you’re within the necessary schedule, that’s great. If you’re not, it’s worth discussing the consequences of moving forward without completing testing.
2. At the end of testing, everyone should be bought-in on the path forward. Proceed without completing all test cases? Proceed with known issues and make it work after cutover? Or, delay cutover and fix it now? It’s a trade-off without an obvious answer. This is why buy-in is so important.
3. In a constraint-less world every issue would be addressed. Reality has constraints.
4. The most troublesome issues to align on will be the high and mediums. The ones at the interface of what’s “included” and what’s “not.” Anticipate some give and take here.
5. A smooth and successful testing phase consists of clear progress with a steady stream of issues reported for you to resolve. As you wind down you feel comfortable, like an airplane gradually coming to the ground. If during testing you had a high velocity of issues, or if you have several issues “left over” for after cutover, you’re landing a plane at a sharper angle of approach. Better set expectations for the landing to be rough and prepared for it when it is.
6. Testing is done with sign off. Its completion should be a formal approval. This is how you ensure that everyone is aligned.

Best of luck with your testing and thanks for reading.

✌️ & ❤️.

-Michael

P.S. — If you found this valuable please consider subscribing (it’s free).

** Batman had his utility belt. Steve had his handy dandy notebook. Project managers have tools too. Part of the Project Manager Toolbox Series.**

🦈 The Jaws Of Defeat | Project Management