What is the process for developing a test plan?

Question

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?

Answer 1

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.

Answer 2

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?

Answer 3

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"

Answer 4

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.

Answer 5

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.