Master Test Plan


Back when we used to all work Waterfall or V or W Model, it was a standard part of the process to have a planning phase for each of your project stages.  And for the Testing stage or stages (if you were more into V than Waterfall) we had our own document describing all the testing we would do as part of our process.

We used to call this document “The MTP” or Master Test Plan.

Some organizations where I used to work went as far as having different MTPs for each of the testing substages or phases, and so we had and Integration MTP, a Feature MTP, a Regression MTP, even a load and stress MTP.

 

We would literally spend weeks, and put into these documents man-years from all our Test Leads and Managers making sure these 30 to 50 page documents were carefully written, reviewed, published and signed off by the different stakeholders of our teams.

 

Sounds scary?  It is 100% true!

As much as documentation is something not to “waste” too much time on, there was something else that was really good and even refreshing from working on these monumental books.  

And this was the exercise of sitting down to understand what we were about to test and plan how to approach these testing projects.

we had to put our heads together to fully understand all the aspects, plan all the types of testing, calculate the time it would take us (we were never right, but at least we tried), think about dependencies, risks, timelines, resources, etc; and finally present this in order to be reviewed by our peers in the Development, Product, and even support departments.

Looking at many teams today that are working their own special way of “agile” and their twisted approach to “DevOps”, where testing is an afterthought at best, it makes me sometimes miss the good old days where we at least approach testing in a professional manner 🙂  

In any case, the fact we moved to Agile and that we are working more on the UserStory level should not mean that we do not need to plan our testing.  It only means that we can scope our testing to the level of the UserStory.

And so, it stands to reason that we should be able to do a scale down version of our Test Planning, that matches this level of functionality and complexity.  And if so, the question now is how to do it, and what should we plan as part of this test planning exercise.

Master Test Planning:

  • What are we testing? User Story, Epic, etc & What problem are we trying to solve?
  • Additional information? – Personas, constraints, integrations, etc
  • Types of testing needed?
  • Risks
  • Environments / Devices / Hardware requirements
  • Automation who and when?
  • Load
  • Reporting who and what?

    Measures

    – Leading if possible
    – Against the purpose or goal of testing
    – Time series if possible
    – What are you not measuring? Who owns the measures and for what purpose?
    – Prediction is typically what execs and managers are looking for – how can you provide it for them?
    -Does this help us understand or improve performance?

    Audience

    – Who needs information and what do they want – provide it for them
    – Managers and Leaders pay attention to things which (rightly or wrongly) matter to them and what gets paid attention to ‘gets done’, whether or not it improves performance
No comments yet.

Leave a Reply