It's time for no more paperweights or online documents that no one on the team reads or reviews. Agile test plan...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
documents range from near novels to short stories, and neither are generally read or reviewed outside of QA. Many software development groups develop test plans either within a wiki or other online storage mechanism where documents can be easily transmitted or shared and still controlled. In my experience, more often than not, an Agile test plan, regardless of its quality, is rarely read by team members outside of QA.
Why even write one? After all, in an Agile-type methodology, documentation is minimal. However, software development groups are starting to return to using a test plan in order to track project testing. In order to be useful, an Agile test plan must be easy to read, concise and stick to the critical points. A test plan that isn't used isn't worth the effort of developing. But test plans can be relevant and useful.
Making it worth the effort
The first thing I'd do is rename it. Sounds silly, but the connotation of an Agile test plan sounds long, heavy and dull. I create test strategy documents instead. The test strategy document is a one-to-two page outline, short, concise and to the point. The test strategy document covers who, what, where and how testing was performed. There are no long paragraphs duplicating the description of the overall project, testing server descriptions, or repetitive data on test cases or execution. All of that data can be found within a test management tool, the user story or within the test cases themselves. There's no need to duplicate the information in the test strategy document.
Why create it? Agile-type development teams move quickly and take in a variety of ongoing projects broken into small fragments across multiple iterations. The only reliable method of tracking an actual project is with a test strategy document. The test strategy lays out concisely what was tested, by whom, when and where exactly, as well as how. It includes critical details on test environments, release levels, test case location and other truly relevant details.
Now anyone down the road a few weeks, months or years can access the test strategy for a project and find concise, critical detailed information on what was done and where to find the testing artifacts in a single, easy to read location.
Here's another way to track your project progress
Look in to the testing crystal ball -- you may like what you see!
Testing issues? More might be, well, more
Dig Deeper on Software Testing Tools and Frameworks
Related Q&A from Amy Reichert
You can't test something if you don't know what it's supposed to do. Often, testers have a very incomplete understanding of what they're testing. ...continue reading
At some point, software testers are going to end up working with remote or contract developers. Expert Amy Reichert explains how to make the ...continue reading
It's a big test, but if you break it down into smaller bits -- and study with a group -- it's much easier. Expert Amy Reichert explains prepping for ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.