Software Test Plan: What Should Be In It?

(Heather) #1

Test plans are something that come up a lot. People ask on different forums what a software test plan is, how do you write one, what should go into one, etc.

@rocketbootkid recently wrote an article for the Dojo “How To Write A Software Test Plan: Learning What’s Important And Where To Start”.

During our 30 Days of Agile Testing challenge, @jesper posted about what his test plans look like 30 days of Agile Testing, Day 26: What does your Test Plan look like? I think this ties in well with the article from Richard, test plans can take many different formats depending on your environment, audience, etc.

One question I often hear asked is “What should be in a software test plan?”. Again, this is something that will depend on your situation, audience and possibly even your tech stack but what advice would you give? What do you think should be in a software test plan?

(Robert) #2

One thing I put in wherever possible is what items, applications or functionalities are specifically excluded from the test plan. Defining the limits of testing, especially if upstream management are going to sign off on the plan, has been very useful to me in the past - more in terms of corporate politics than testing itself, I have to admit.

(Jacqueline Baker ) #3

A few of my favourite test plan items …

Software Constraints

Specific software constraints is something that we record for the applications that we use, the wider business are not always aware of the limitations and work abounds that we have to use in order to achieve adequate coverage of specific items from the Business Requirements.

Out Of Scope Items

Absolutely imperative, to ensure that we have outlined exactly what we will not be testing to prevent scope creep.

Testing Types Used

As varied as the project/team will allow, this displays the breadth of our skillset within a team and will inevitably capture more defects.

(Stefan) #4

I think of two different things when I hear a test plan:

  • the plan that you have in applying the strategies and resources to fulfill the mission.
  • the document you write containing some information about the plan you intend to do.

Planning is necessary, the plan document maybe not.
As in RST: Plan = strategy + logistics.
The plan should help fulfill a mission.
Missions can be entirely different in context.

In basic terms and according to my interpretation: a plan contains ideas about what/how/why/when you want to test & resources that you are going to use to achieve that.

(Simon) #5

I add ‘where’ to your nice list, as in where for resources - be that people or stuff. It could probably be covered under the ‘What/how/why/when’, but it can be important when you are planning - distributed testers, fixed location hardware that you need physical access to etc.

(Adam) #6

Oh, I have one of the missing ingredients. In one of my projects I would kill to have start, stop, suspend and resume conditions of the testing. The project was Scrum, but definitely not really, and we had absolutely zero automation, yet very distinct test phase by targeted test team. And the kind of bad builds that we had they delivered to us were mind boggling - yet unfortunately we never had defined this type of test plan (the plan was to wing it, as it unfortunately often is), so we had absolutely no recourse, and no way to signal this to the managers, other than informal - but then they asked for metrics, which we didn’t have because we couldn’t really measure it since it was that informal and not written down… You get the picture :frowning:

(Simon) #7

Yup - completely agree with this. I always have entry / exit / suspension / resumption criteria defined. I find the suspension / resumption are a little loose by definition because you can’t anticipate all the things which are going to stop you testing, and therefore when you can start testing again has a similar problem. I find the entry / exit criteria a bit easier to define as I generally understand when I get going on what, and at what point I have to stop (even if we would always want to spend ‘just one more day’ on things so the end never comes).

(Adam) #8

+1 It is never possible to anticipate all conditions for suspending testing, but in my opinion the test plan is a communication tool. It communicates to all interested parties, that it actually is possible for the testers to say: we cannot afford to spend more time on this artifact, because of its fundamental problems, and our full pipeline. If not included, there’s a risk that the stakeholders simply won’t get the message!