How to write a test plan

Question

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?

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 example -

Hope this will help.

Best Regards

Answer 6

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

Steps:

• 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

Answer 7

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.

Answer 8

"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.

Answer 9

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