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?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.Sign up to join this community
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!
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.
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:
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
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:
Dependencies a. Design complete b. Dev complete c. Test environment ready d. Test resources available
a. Test Prep Complete and signed off
b. Test Data Ready
c. Test Execution Start
d. Test Execution Complete
e. Test Closure
Go Live Dates
Go Live Support
Hope this will help.
A test plan details each step taken to achieve a certain result and states the objective of each action. Follow steps down here:
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 :