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.

2 Answers 2


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.


Test Planning is having different components which combinedly provide a Robust Test Plan. Below are the details:

Test Strategy: This is a document that communicates the test approach. The test strategy can be developed very early in a project and requires only initial information. Whenever a new type of project is being QAed, the test strategy is one of the most important early test deliverables.

High-level Test Planning: This is a document that describes the who, what, when, where, and how of the test.

Detailed Tests: The high-level test plan will show which areas of the application are to be tested.

Major Test Planning Tasks are: a. Write Test Scripts b. Define Test Cases c. Design Test Data d. Build Test Matrix e. Determine Test Schedules f. Assemble Information g. Finalize Plan

Software testing companies follow the test planning process in-order to release a robust product.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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