Defining core software regression tests

There's no definitive term for 'core regression tests'. However, I can speak to regression tests and their purposes. The goal of regression tests is to retest major components of an application. It's a known IT best-practice to limit the scope and 'breadth' of application changes for a given release – rather than changing each major functional area of an application, a better strategy is to focus on adding, enhancing, or modifying functionality in a few areas. Once that functional enhancement has been completed, it's critical to validate that nothing changed has a negative impact on the functionality and reliability of the untouched portions of the application. This is regression testing.

A key to good regression testing is to have a solid set of regression test cases. This set of cases, called a regression test suite (or a set of test suites, one for each functional area of the application) includes high-priority functional tests, deeper testing for functional areas prone to breaking under change or highly sensitive to change, and perhaps a suite of tests aimed at key show-stopping/break-fix bugs which have impacted customers in the past. This suite of tests should be reviewed frequently for completeness, precision, and usefulness.

A common strategy applied in regression testing is to automate the identified regression tests. I find this to be a critical aspect in my test strategy. A good automated test (which produces reliable, consistent, repeatable results as well as a minimum of false positives and false negatives) allows me to regression test my applications over and over again. Automated tests do not, however, replace a strong tester. I never release software which hasn't had a good manual test pass, because a human being can spot nuances an automated test will rarely find.