WavebreakmediaMicro - Fotolia
It's time for no more paperweights or online documents that no one on the team reads or reviews. Agile test plan 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 Topics Archive
Related Q&A from Amy Reichert
Let's explore the importance of result analysis, the right measurements and test design for application performance testing. Continue Reading
QA needs to reiterate its value to the business side of the organization. Use this tried-and-true advice to leverage documentation and automation to ... Continue Reading
Vendors have inched toward automated application testing for a long time, yet there is still room for growth. Software tester Amy Reichert offers her... Continue Reading