Software products must be checked for defects before release. Afterward, what happens to the functionality test is up to the QA specialist. Ideally, these tests should be saved and reused for future testing. However, it is possible to have so many tests sitting around that there is no way to run them on a regular basis. In a white paper by QA analyst Lisa Shepard, the over recording of tests is taken to task.
QA experts document tests because these tests establish a standard of functionality that can be tracked across usage cases, and to provide acceptance criteria for future cases. Regression testing also proves the value of, well, regression testing! If similar tests are needed with every new release, these tests are made available.
Less In, Less Out
Shepard maintains that regression tests should be kept for future cases, but that it pays to be strategic when creating those tests in the first place. Once a test is created, it doesn’t necessarily have to be saved in an official archived format. Similarly, as test plans are reviewed with every new release, excess tests that no longer provide good QA can be deleted.
One can also limit the amount of detail contained in tests by focusing on the main goal, the intent of content, without going to great lengths to generate the exact text. This approach avoids excessive explanations and long-winded setup instructions.
Review a Few
Find time to clean up your existing test plans by glancing at each to detect details that can be deleted, duplicate text that can be removed, or tests that can be rewritten and simplified. Create a “depreciated” folder to let the unneeded tests sit in limbo before you finally dump them.
<p>Finally, if you’re trying to break your bad test-documenting habits, try running a report at the end of each release or subjecting your code changes to peer review. Less is sometimes more when you’re running QA for software.
To read the full document, visit: http://www.uploads.pnsqc.org/2012/papers/t-46_Shepard_paper.pdf