I am new to "Test Plan Writing" and I want to learn how to write test plan.

As a beginner, what do I need to understand and learn first to write quality/effective test plan?

What would you suggest?

9 Answers 9


To know how to write a test plan one must first learn to plan a test.

Planning test is a real thinker task. You should be asking a hell lot of question to learn about the domain of the project. You should learn about the stakeholders of the project.

One part of planning consists of test estimation. Here is something that might get you started with it - https://www.patelmilin.com/blog/testing/points-consider-test-estimation.html

And here is a small list of questions you should be asking before starting the task - https://www.patelmilin.com/blog/testing/questions-before-testing-software.html

Now don't consider these 2 lists a Bible. They can be right or wrong or insufficient for your context. Go through them and improvise. Add your thoughts and try to find out as much information as you can about the project. Then list out your findings and do a cost vs value analysis. This will start generating test ideas withing you. Then see how you would like to go about it. Make a mindmap for it and viola your test plan is ready!

Oh I almost forgot, go check out http://apps.testinsane.com/mindmaps/ its like candy land!

  • You have linked to the same 2 lists Commented Sep 18, 2014 at 8:15
  • 6
    Sorry for the error buddy. I have updated the link! Commented Sep 18, 2014 at 9:09
  • @TESTasy 404 for both links
    – sventevit
    Commented Nov 3, 2016 at 14:31
  • I'm changing the host and also redoing the website. It'll be up and available soon Commented Nov 4, 2016 at 1:25
  • Two of the three links are dead :( Commented Jan 24, 2019 at 15:03

Let me give some advice I got from James Bach. He likes to make the distinction between a test plan and the test plan document.

A test plan document is the written form of the test plan. This can vary quite a bit depending on the company you work for and in my experience can range from lean or minimal to bloated (I’ve seen so many bloated test plan documents in large companies based on templates designed to make the team “look good” or "cover everything").

Most “testing standards” like IEEE829 seem to care more about the document of the test plan and it’s structure then they care about the context of what’s good or useful to the team or testers.

A test plan typically contains the logistics of the testing project and your test strategy.

  • Logistics can include who does what testing, when (estimates) and end dates.
  • Test strategy will be how you the things you want to test, or the things you have time to test or the ideas that guide your choice of tests. Bach’s Heuristics Test Strategy Model (HTSM) is designed to help testers determine what your test strategy should be.

Regardless of if you write it down (I can think of a few examples of where you wouldn’t) and the format you follow (build one on your own for a lean / minimal product or use a bloated template) the most important part is understanding the purpose of the plan and that's to guide your testing.


I agree with milinpatel17' above answer about Test Plan. Test Plan is a detailed layout and strategy to test a product or application. Before you start writing a test plan, consider these points first:

  1. Why to test -- objective
  2. What to test -- scope
  3. How to achieve objective -- required time and money (with number of resources)
  4. What approach -- Automation, Manual, Functional or Non Functional etc...
  5. Which Methodology -- Agile, waterfall etc... if required.
  6. What Condition -- May be test condition.. etc.. etc.. etc ...

This will be really helpful to achieve a perfect test plan.


In addition to the above mentioned headers, a test plan should include following sections too along with their description

  1. Entry and Exit criteria: for starting the testing phase and calling it out
  2. Suspension and Resumption criteria: during testing there may be several instances when you need to suspend your testing because of single or multiple reasons. This section contains those conditions that when you/team need to suspend testing and when to resume the same.
  3. System Acceptance Criteria
  4. Bug/Defect Management process
  5. Team composition with Roles and Responsibilities
  6. Milestones and Deliverable (with planned start and end dates)

Again as said above by others, don't consider this as hard and fast list as a 'Line drawn on a rock'.

Your test plan should be in accordance to your project plan and SDLC model being followed in your project.

Don't add too much of stuff in your plan, just keep it concise and to the point. I have seen that many people create test plan just to add another document to their project repository and with due course of time it gets outdated, team starts testing in a different way mentioned in the test plan. Using new strategy or approach is not bad, rather its a good thing to keep yourself and your strategies updated, but at the same time you should keep your test plan/related documents updated too. So the process should be that first you update your plan and then implement it, instead of doing it otherwise.


A Test Plan must have the minimum skeleton as specified below. It is very important to remember and know the difference. We are not referring to test approach or strategy documents here. I have always used Microsoft project to create and track a plan as it is such a powerful tool and provides such a wide variety of views that suits everyone i.e. if you want to look at each detailed items/tasks and its progress in percentage Or want to track milestones and even resources. Also bear in mind in the overall lifecycle of the project it is almost impossible where you will see the dates have not changed, therefore maintenance becomes easier too if the test plan is well thought/constructed. Now coming back to the specific question.

It must contain:

  1. Dependencies a. Design complete b. Dev complete c. Test environment ready d. Test resources available

  2. Test activities a. Test Prep Complete and signed off
    b. Test Data Ready
    c. Test Execution Start
    d. Test Execution Complete
    e. Test Closure

  3. Go Live Dates

  4. Go Live Support

See an exampleSample Test Plan -

Hope this will help.

Best Regards


A test plan details each step taken to achieve a certain result and states the objective of each action. Follow steps down here:


  • Write an introduction -An introduction includes a general description and schedule of a test, as well as any related documents
  • Required resources. This section describes all of the resources needed to complete the testing, including hardware, software, testing tools
  • what you are going to test. List what new aspects you will be testing and what old aspects you will be re-testing.
  • what you will not be testing. List any features that will not be tested during the current project.
  • list of documents that will be produced during testing.
  • risks and dependencies. Detail all the factors that your project depends on and the risks involved in each step.
  • the results of your project. Outline all the goals that you hope to achieve during the testing process. Detail the parameters for which success and failure can be measured
  • If you're affiliated with Indiumsoft, you need to state this, otherwise you risk your post being deleted as spam.
    – Kate Paulk
    Commented Jan 12, 2015 at 12:09

A test plan details what, when, how, who, and more of a testing project. It should outline the general strategy and provide someone with enough information to allow them to get started whit the testing.

After commonly being asked what details should be included in a test plan here at TestLodge, we have put together an example test plan based on the IEEE 829 format which has been mentioned in previous posts here.

We generally believe that documents like this should be lightweight and not span on for pages and pages, but this will depend on what you are actually testing and the scope.

To find out a little more about this example along with viewing it in alternative formats please take a look at our recent test plan blog post.


"Planning is everything, the plan is nothing."-Dwight Eisenhower

I think learning to write test plan document is less important than going through the process of making the plan. It helps to capture the critical information at the beginning by asking the right questions at the right time. By doing it correctly focus on testing is placed on the business critical items by utilizing the testing resources efficiently.

I would suggest learning how to formulate the test strategy for a given project considering all the business goals and the risks and constraints associated with it. In the end, it is not the document but the right communication it fosters between the team, matters.


According to IEEE 829 format : These are the main points :

  1. Test Plan Identifier
  2. References
  3. Introduction
  4. Test Items
  5. Software Risk Issues
  6. Features to be Tested
  7. Features not to be Tested
  8. Approach
  9. Item Pass/Fail Criteria
  10. Suspension Criteria and Resumption Requirements
  11. Test Deliverables
  12. Remaining Test Tasks
  13. Environmental Needs
  14. Staffing and Training Needs
  15. Responsibilities
  16. Schedule
  17. Planning Risks and Contingencies
  18. Approvals
  19. Glossary
  • 2
    Thank you for the list. It would be helpful if you could add some notes to each item of the list which shows what conent should be provided in each part of the document.
    – bish
    Commented Jan 8, 2015 at 6:06
  • @Piyush What does this response have to do with the question that was asked? Commented Jan 8, 2015 at 6:14
  • @ChrisKenst : That is the term we use to write test plan.
    – Piyush
    Commented Jan 8, 2015 at 6:25
  • @bish : I will provide more documents for each part.
    – Piyush
    Commented Jan 8, 2015 at 6:26
  • 1
    @amazpyel : Yes you are right !! I will post !
    – Piyush
    Commented Jan 23, 2015 at 8:59

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