Automating regression test cases

Automating regression tests may or may not be beneficial. Expert Scott Barber explains how to automate and when manual testing is more appropriate.

Please tell me how to identify a regression test case?

I presume that what you are asking how to pick a subset of set of existing test cases to be somehow transformed into regression tests. I have to further assume that the transformation is from a manually executed test case to an automated one. The simple answer is to pick a subset of the manual test cases that exercises what you would consider core functionality of the system that are unlikely to change significantly over time.

Automated regression tests are not very powerful tests. All they really tell you is if something that you thought to program your automation scripts to check for, basically making them an automated change detector. The biggest challenge with this is that these automated scripts tend to be quite fragile, meaning that slight changes in the application will often cause the tests to report "failures" that actually indicate that the script needs to be updated to deal with the change in the application. This is problematic because it often takes more time and effort to maintain these automated regression tests that it would have taken to just execute them manually in the first place.

On top of that, there is very little data to suggest that automated regression tests actually find very many defects. If your testing mission is to find as many of the existing defects as possible, investing in regression testing may not be valuable use of your time. If, however, you have a good business reason to need to demonstrate that some very specific features are available and working (at least superficially), over and over again, on a relatively stable and mature application, investing in automated regression testing may be a wise choice.


This was last published in October 2007

Dig Deeper on Software Regression Testing



Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

"If you are thinking of automating a project, there are some points that needs to taken into consideration? The common ones are risks involved, what to automate and remember every application cannot be automated. Now, the question arises when to automate. The answer can be simple. If the application is much stable, requirements are not changing constantly and application will persist for longer time than we can always think of automating test cases in order to reduce time of execution, little human interaction and most important one reducing lengthy process of running manual test cases.
To automate, there are several open source tools and frameworks available. However; these tools require in depth knowledge to create test suites. When a test suite is being designed it should be flexible enough to be changed easily, remove and add or remove new functionality as and when required.
One of the dangers of regression automation is that the tests become static. We don't make regression test cases to confirm new features, we use them to confirm that functionality that worked before is working consistently going forward. In this, there is a danger that tests can become obsolete, and we may never be the wiser because we will get a pass no matter what happens. Second only to flaky tests, tests that never fail should be revisited from time to time to ensure they are looking at relevant behavior and functionality, not just something that runs forever, always passes and we just assume it works.