I'm an experienced tester but I don't have much experience with test planning, and no experience with organized test planning. When trying to create a test plan, I get tripped up by trying to cover every detail and having no idea how to organize it all. How do I start writing a test plan that is designed for decent coverage without getting bogged down attempting to covering every nuance? How do I organize the test cases? How do I analyze a product to guide how a test plan should be organized?

  • 1
    It depends on business needs and what you are testing. The process will be different if it's a small phone app vs. an enterprise client/server product. Many people/teams have different philosophies around the definition of "decent coverage" and how much documentation is required as a result. This is a difficult question to answer concisely in its current form.
    – user9054
    Jan 24, 2015 at 22:18

5 Answers 5


Frankly speaking, too many test plans are a lot of boilerplate without substantive information. Over the years, I've tried to strip out rote process information entirely or place it in a separate process document and focus on these key items in the test plan document.

(I'll mention here that documenting a test plan is the final step. Most of test planning is the work leading up to the documentation--understanding the requirements and technology and thinking through the topics below with the other members of the development team and the project stakeholders.)

Overview - A general description of the new functionality, the intended user, etc. Trying to provide a context for determining success and asking good questions throughout the process.

Scope - What are you testing and what are you not testing? Again, these topics should be prompts to a good analysis/discussion. What environments must be tested? What are the priorities of those environments? Are you doing load testing? Are you doing security testing? This is high level stuff-not each use case or user story, but the big chunks of functionality.

Background Documents/resources - links to specs, relevant technical white papers, etc.

Test Environment/Setup - What will be automated and what will be manual? In which environment(s) will you be testing the code? Identify needs for test data, test user accounts, etc.

Test scenarios/cases - For us, we keep all our actual test cases in a separate tool -- we use Rally--but this is where you can capture all the scenarios you will be going through as one or two-liners. It is well-nigh impossible to get everyone to go through all of the step-by-step test cases for even a small project. But you can get all the stakeholders to sign off on this list. Be sure to challenge them to think of ways this could fail because if it isn't on this list, it isn't getting tested. Thoughtful input from the team and sign off on this list is very important.

You should have test scenarios to cover every requirement for the software. If you are in a project with specs and itemized requirements, you should document a traceability between requirements and test case. If your requirements are drawn up in the dirt, your test plan may be the place where your team has the discussion around the itemized requirements for the project. That isn't ideal, but it happens a lot.

Test Entry/Exit Criteria - This can get a little boilerplate, but it's important to define what it takes to get into and out of QA.

Assumptions - If you have any uncertainties or things you are assuming will be the case for the project, foreground them here so you can discuss them in review.


To answer this you have to ask a lot of questions. I would start with the following questions.

What is changing?

How significant of a change is it?

How large of an impact will the change have?

How much risk of a defect is in the change?

What is the consequences of a defect in this piece of the code?

Will people be fired if you miss something?


Before you prepare a test plan, first understand the requirements thoroughly and make up your mindset to see the software in end-user perspective.Then jot down all your requirements to chunks of use cases. With the help of use cases try to create test suites. each test suite having logical value of use cases(The logic will help you strategic the testing).

Think your self how to certify that particular software is having good quality(Objective)? for this prepare list of exit/acceptance criteria. Now to meet those exit criteria what are all required to test gives you entry criteria.

Factorize the end user perspective to design/plan the way you test the software.

If you are able to do all the points said above then We can say Testing is planned.

"The more you understand, more can be measured and more is quality"


The way test planning is done at Google might be insightful for you as it directly attempts to tackle the issues you're facing.

There's a book that goes into more detail that I personally recommend called How Google Tests Software.

Mostly they focus on describing the three most important dimensions of the product (in the book they further describe how they quickly rank and prioritize the specific the descriptions).

  1. Attributes the adverbs and adjectives that describe the high level concepts testing is meant to ensure. Attributes such as fast, usable, secure, accessible and so forth.

  2. Components the nouns that define the major code chunks that comprise the product. These are classes, module names and features of the application.

  3. Capabilities the verbs that describe user actions and activities.


I think most people start by looking at the ISO standard documents for inspiration on how they might implement their own test plan. Thankfully, such documents exist, otherwise there would be an even wider range of answers to this question.

  • I think you have set wrong link. It redirect to some non-useful. Please update link. Jan 24, 2015 at 5:19
  • okay..great.... Jan 27, 2015 at 3:26
  • without going into the discussion of are "software testing standards good or evil" they are not a good starting point for developing a test plan, especially for inexperienced test planner. He will not find there the answer to "How do I start writing a test plan that is designed for decent coverage without getting bogged down attempting to covering every nuance?"
    – Rsf
    Feb 24, 2015 at 13:42
  • @djangofan What evidence do you have that /most/ people use an ISO standard? Do you have /any/ evidence or observations that even a few people or testers use it? Feb 25, 2015 at 6:28
  • @ Chris Kenst I bought and used "ISO/IEC/IEEE 29119-3: Test Documentation" once to get some test ideas, but never heard of anyone else doing it
    – Rsf
    Feb 25, 2015 at 14:31

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.