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?

Help from Test Managers
(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!

(Vishal Dutt) #9

Test-Plan is strategy that needs to be follow during any regression testing for release. We create Test-plan before start of regression testing. In order to create test plan, following points should be kept in mind:

  1. Firstly we should mention the purpose of testing, what all features are introduced in the product to be tested.
  2. We should mention the list of documents used, where information to test the feature is obtained (These include wire-frames, wiki pages and developer use cases).
  3. Hardware: Which type of hardware should be used for testing.
  4. Software: This include feature version, OS, Browsers, builds of the product and etc.
  5. Staffing: Its better to mention the number of engineers who will work on that feature.
  6. Details of testing: What all areas will be covered should be mentioned in detail.
  7. Regression Testing: If testing is to be performed for next version of an existing feature than few areas of regression tests should be mentioned.
  8. Feature that are not going to be tested should be mentioned.
  9. Limitations of the feature (if any) should be mentioned.
  10. Dependencies and risks involved should be explained.
  11. Information about testing effort should be mentioned.
  12. An entrance and exit criteria should be defined covering the important points that needs to be fulfilled before giving a go-ahead for the feature.
  13. We can also include some additional testing like Unit testing, DB testing, Performance testing in Test-Plan.

In order to deliver best QA services, we always mention complete details in Test Plan which will give better picture of the testing approach. Hope this information is helpful for you.

(Rosie) #10

There’s also the approach of the one page test plan.

Plans are so often overated, which is why I like the one page approach to test planning, or planning for anything really!

(Simon) #11

I struggle a little with this.

I find that if I cut down on documentation too drastically I end up having to explain, or spend time creating and delivering a presentation, to different stakeholders to explain several things. Usually where their money is being spent (I usually work on large multi-year projects, the minimum length being releases being six months supporting a team of currently four testers with expensive hardware), why that spending it in those areas is right, and why the level of testing we are adopting is fitting for the project.

I appreciate a lot of the reasons for not producing a plan with lots of detail that is subject to change, but change is real life. I do go back and update the plan to match new thinking when necessary and that is why I think it is a fine line between not enough and too much detail. In some ways it makes it easier for me come ISO and internal audit time too. What did I plan to do? Its in the plan. Where is the evidence I did what the plan detailed? Have a look in the plan - it will tell you where to find the artefacts. There is a maintenance burden, but as long as you pitch the plan right you retain the flexibility required whilst allowing others to check that you’ve got a coherent and appropriate course of action for your project.

Typically I may find myself spending a couple of hours every few months revising my plan as we’ve come up with a better idea. My test plans typically run to about 20 pages or so, unless its a new platform which may double that.

I know I’m probably a dinosaur in this respect (please don’t hurl any asteroids at me).