Software Testing: What is Test Planning
I broke this down in the video above. Below is the written version, expanded into a fuller guide to what software test planning is and how it changes between waterfall and agile.
Test planning is the most important element of the planning process, whether you are running agile or waterfall. If your testing keeps missing things that later show up in production, this one is for you. Good test planning comes down to spending enough time up front learning about the product before you write a single test case. In the video I explained why that matters and what a plan actually contains, and here I want to expand on it, including how the plan looks different in waterfall versus agile. Skip this step and testing struggles. Do it well and everything downstream gets easier.
Why planning is the most important step
Test planning requires the tester or test lead to spend enough time learning the product before writing any test cases.
The heart of test planning is preparation. The tester or test lead needs to spend real time reviewing documentation, story cards, or other material, and collaborating with the development organization to learn about the product being tested. The more you understand the product, the better your test cases and exploratory techniques will be.
I make this point in the video. Without planning, the tester and the whole QA organization will struggle. They will probably miss the mark or skip a specific testing activity, and that can turn into production defects. What I learned is simple: the more time you spend up front, the less time you spend on the back end, and everybody is happier for it.
Who to talk to
Gather information from the developers, the business analyst, and the business or UAT people before you plan.
Planning is a team sport. Collaborating with the development organization is the first source, since they know how the product was built. If the group has a business analyst, that is another excellent source of detail about how things are supposed to work.
Do not stop there. Reach out to the business person or the UAT tester, so the testing individual gathers as much information as possible. I found that the best test plans come from testers who treat this as active investigation, not a formality. Every conversation you have before you plan is a defect you are less likely to miss later.
The waterfall test plan
In waterfall, you build a full test plan that defines scope, process, data, environment, and stakeholder sign-off.
If you are using waterfall, you will probably develop a formal test plan. Most templates are fairly general, and you can find examples online and customize them to meet your needs. Anyone who has been in testing should be reasonably familiar with what one looks like.
A good plan identifies the essentials. What is the scope, and what exactly are you testing? What is the process if you find defects? What kind of data will you use, and where will you test it? Who is involved, both as testers and as stakeholders? I walk through this in the video. Crucially, you want every stakeholder to review the plan and sign off on the document before testing begins.
Planning in agile
In agile you usually skip the full test plan, using at most a short one or two page document per sprint.
Agile handles this very differently. You probably will not have a full test plan at all. At most you might keep a condensed version, a one to two page document that gives you insight into what you are testing during each sprint or iteration.
The detail is deliberately lighter. Agile trades heavy documentation for speed and collaboration, so you will not produce the exhaustive plan a waterfall project expects. What I learned is that the planning itself does not disappear in agile. It just moves out of a big document and into the conversations and the short per-sprint notes that keep the team aligned.
The takeaway
Test planning is the most important part of the planning process because it forces you to learn the product before you test it. Spend the time up front, and gather information from developers, the business analyst, and the business or UAT people. In waterfall, capture it all in a formal plan covering scope, process, data, environment, and stakeholder sign-off. In agile, keep it light with a short per-sprint document. Either way, the time you invest up front is the time you save chasing production defects later.
If this helped, the full explanation is in my video on software test planning. Here is my question for the comments: how much test planning does your team actually do before a sprint? Subscribe if you want more practical software testing guidance.
