Why You Shouldn’t Write Test Plans

Four years ago in a previous role, I blogged about why I don’t like the term “Test Plan”. I made the point that a Test Plan was something a test team wrote so they could measure quality and report back to the team, whereas a “Quality Plan” describes how the whole team will work together to achieve the necessary level of quality before shipping. You cannot “test in” quality; quality starts with the specs, then the code, and then the test and stabilization processes. As the old tester adage goes, “Testers don’t break code. It’s already broken when we get it.” Quality Plans recognize this and focus on helping the team, not just the testers, drive quality.

In addition to those points (which I still believe are valid), I’d also like to point out that “testing” is an activity, but “quality” is a result. Which would you rather have your team focused on? Using the term “Quality Plan” helps put a team in the mindset of working to reach a destination as opposed to just “doing testing”. It is still a subtle difference in verbage, but it can be a massive (positive) pivot in thinking. 

Testers who focus on activities are less likely to question whether those activities are appropriate for the situation at hand, and they are more likely to just keep doing what they’ve always done. Testers who focus on achieving specific goals are more likely to identify and change activities that don’t help them reach those goals. now, I don’t have scientific data to back this up, but you can find at countless studies about the success of people who write down goals vs. those who don’t, and they all reach similar conclusions. 

Quality goals can take many forms, and obviously you will have to experiment to find the form that best fits your needs. How can you tell if you have well-written quality goals? The SMART goal format offers some hints. Your quality goals should be specific, measurable, achievable, relevant, and time-bound. I will also add that it should be clear who is accountable for reaching those goals. They should clearly describe what you need to see in order to know you are ready to release. Some examples include which tests must pass, a certain volume of positive beta user feedback, target values for performance and stress tests, etc.

Including activities in your Quality Plan is fine too, but they should always be listed as supporting specific goals. After all, this is a plan of action as well as a plan of destination. You wouldn’t make a travel plan that only describes how you will get in the car, drive to the airport, fly, get off the plane, and hail a cab, would you? Why would you do the same with a plan for reaching quality?

Will you make the switch from Test Plans to Quality Plans?