ITMPI FLAT 005
Main Menu
Home / IT Best Practices / Avoiding Overkill in Manual Regression Testing

Avoiding Overkill in Manual Regression Testing

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.

The Rationale

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.

Limit Detail

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

About Eric Anderson

Eric Anderson is a staff writer for CAI's Accelerating IT Success. He is an intern at Computer Aid Inc., pursuing his master's degree in communications at Penn State University.

Check Also

10 Mistakes to Avoid When Troubleshooting IT Problems

Troubleshooting a problem can be a pretty tense time in the heat of the moment. …

Leave a Reply

Your email address will not be published. Required fields are marked *