When working at small organisation in a small IT team gaining maturity with a one person test team. Using Test Manager in VSTFS 2015, what are the best practices for test plan structure? The Team works with a Agile methodology in 2 week sprints.

What criteria should be used when formulating the test plan for each sprint or making the plans more product & feature focused.

It appears that a Product focus seems like the way to go, because then they can be re-used for Regression, etc. However I'm concerned how easy that would be to maintain?

Welcome all thoughts.

I personally find it useful in covering the whole project. Running through it once per release cycle is one of the best ways to make sure everything you absolutely need checked is working properly (exploritory testing helps to find anything else and should either be a part of the test plan or at least be noted elsewhere as an important part of each sprint).

The first and most obvious thing I add to a test plan is the expected process for the application/site. If your base process doesn't work as intended, it should be the first thing that's flagged since it would be the biggest issue preventing a release.

Covering your supported hardware/browsers is what I usually add next. While this (depending on the company) might not deter a release in some circumstances, it can be a big problem if multiple ports don't work properly and can be pointing to a much scarier, underlying issue that needs to be rectified ASAP.

Somewhere around here, I would begin to mention confirming the bugs that have been labeled as fixed during this (and maybe the last, if desired) sprint.

After that, I would most likely cover any common major bugs and uncommon critical errors. This step can get unweildy as a project ages, so discretion might be needed. This is mostly merging into regression territory, though.

Finally, I think an "if there's time" section is good and keeps people busy, especially during a slower sprint (maybe a "jog", in this case?). I'd consider things like checking copy or a set of common minor/trivial bugs.

I personally view a test plan as the QA team's signature of approval for a build to go live, so that explains why I add a lot of regression elements into my plans, but obviously do what works for your team.

Hope this helps.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.