Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Get agile with your test plan: How to streamline

Amy Reichert QA Engineer, RxMxUSA

Test plans have a history of not being read, and for good reason: The typical plan includes 10 to 40 pages of dry technical information, requirements, details on test execution, platforms, test coverage, risk, and test execution calendars and assignments. No wonder people refer to test plans as doorstops. 

And people outside of the quality assurance (QA) team rarely review test plans in any detail. Just try to get a developer or project manager to review your test plan. You might as well be offering them a root canal. The only way you're going to get input is by writing a brief outline of what your test plan covers.

Include only the information that's absolutely necessary. And present it in a quick, easy-to-read format, preferably of one page or less. When your test plan is short and simple, it will become essential reading—even on agile teams.

Here's how to get your test plan started by reviewing what's essential.

What's the purpose of a test plan?

A test plan is a work agreement between QA, the developer, and the product manager. A single page of succinct information allows team members to review fully and provide necessary input for QA testing. The single-page test plan includes specific details on who, what, where, when, and how software development code is tested. It must be in a readable format and include only the most necessary information on what you’re testing, where, when, and how.

The purpose of your test plan is to provide developer input to QA and historical documentation for reference as needed. You can reuse previous test plans as a source for reference documentation, training, or evidence of traceability, as needed.

If you want to have your test plan used and stored within your software development tool, embed it in your story or epic. Most tools have sections for comments and even test execution information. Use those to help create, manage, and store test plans where people can easily find and access them.   

The value of a test plan in agile development

Agile teams can still benefit from test plans—if those plans are limited to one page and contain only the essential information. An easily readable, concise test plan offers both historical testing information and traceability. That's an advantage when team members change or the team grows and needs to have documentation of application functions, as well as past release information. A test plan also gives you legal documentation of what you tested, how, and when.

The test plan isn't just a plan; it's a work agreement between QA, product management, and development on what a story means and how it functions. The work agreement describes what the story means and how it’s tested between development and QA. It verifies understanding and provides application documentation.

The elements of a concise feature/project test plan

So what sections should you include in a feature/project test plan?  There are five elements: 


Include a brief description of what features are in the release, in either a list or a paragraph. For many applications, a user-story format explains the features in the release as well as the business purpose and value.

Proposed test scenarios

In outline or story format, provide a high-level list or explanation of existing test-case scenarios. Consider using a flow diagram if it’s easy to follow.

Risk analysis

This includes a table of items not testable due to platform, environment, time, or resource constraints.

Default test coverage

If you always test five browsers, or iOS and Android for mobile, or SQL injection for security, list that information here.


List any notes and comments from the QA review with the developer and product manager. Note the results of the review and whether new test-case scenarios were added or any additional changes made. 

The elements of a release-level test plan

Here are the sections you should include in a release-level test plan are slightly different. These include:   


Include a brief description of the features in the release in list or paragraph form. For many applications, you can use a user-story format to explain the features in the release and the business purpose and value of each. For larger releases, or when a set of features affects the same workflow, consider grouping those features together. 

Release date

When is it going to be in customer’s hands? Include the original date as well as any date changes, if applicable.

Risk analysis

Include a table or list of known risks and the part of the application's functionality affected. Also include any workflows or testing that is not being completed, or can’t be completed. For example, full-scale security testing may happen right after a release rather than before, or performance testing might be executed between releases after you've established a baseline.  

Default test coverage

List all the browsers, platforms, and versions to be tested, as well as the standard test coverage and any additional test executions. Bullet-point lists work well here; don't make it into a long list of application features. Keep it relatively high-level, or this section will grow very quickly.  

Scheduled testing

Note the test types and how defects will be handled relative to the release timeline. Make a note if defects will be handled differently based on priority.  

Release exit criteria

Define when the release is good enough to go. For example, you might release only with a 99% pass rate for smoke tests, or when no critical defects have been entered for five days. Describe how you judge when application quality is high enough here.  

Write your test plan: Keep it short and sweet

The single-page test plan is a valuable tool for test planning, even in agile development environments. A succinct test plan produces test planning for QA, input from development and product management, and reference documentation that's useful for a variety of tasks. Test plans shouldn't be doorstops. When they are written correctly, your team will see them as valuable planning and recording tools. 

Do you have tips for writing a concise test plan? Share your thoughts and comments below.

Keep learning

Read more articles about: App Dev & TestingTesting