Regression testing provides an excellent opportunity for automation. A regression test bed grows as today’s functional tests become tomorrow’s regression tests. It’s only a matter of time before regression testing outnumbers the time and resources available to a traditional manual testing team.
When developing steps to prepare for automating regression testing. A number of questions need to be asked:

• How frequently should the tests be run?
• How long does it take to run each test for the regression suite?
• Is there functional overlap between the tests?
• Do the tests share data?
• Are the tests dependent on each other?
• What preconditions are required before test execution?
• What percentage of SUT coverage do the tests represent?
• Are the tests currently executing without errors?
• What should happen if regression tests take too long?

Each of these points is discussed in more detail below.

Frequency of test execution
Tests that are executed frequently as part of regression testing are the best candidates for automation. These tests have already been developed, exercise known SUT functionality, and their execution time is greatly reduced by using automation.

Test execution time
The time required to execute a particular test or an entire test suite is an important parameter when evaluating the value of implementing automated testing as part of regression testing. One option is to implement automation for time-consuming tests first. In this way, each test can be executed faster and more efficiently while adding additional cycles of automated regression test execution. The benefit is additional and more frequent feedback on the quality of the SUT and reduced deployment risk.

Functional overlap
When automating existing regression tests, it is recommended to identify all functional overlap between test cases and reduce it where possible in the corresponding automated test.
This will lead to further efficiencies in automated test execution, which will be significant as the number of automated test cases increases. Often, tests developed using automation take on a new structure as they depend on reusable components and common data sets. It is not uncommon to split existing manual tests into multiple smaller automated tests. Similarly, consolidating multiple manual tests into one larger automated test may be the appropriate solution. Manual tests need to be evaluated individually and as a group so that an effective conversion strategy can be developed.

Data sharing
Tests often share data. This may be the case when tests use the same data set to perform different SUT functions. An example of this would be test case “A,” which checks an employee’s available vacation time, while test case “B” checks what courses the employee has taken as part of their professional development goals. Each test case uses the same employee but checks different parameters. In a manual test environment, employee data would typically be duplicated many times in each manual test case that checks employee data against that employee. However, in an automated test, the shared data should be stored and retrieved in a single source, where possible and feasible, to avoid duplication or the occurrence of errors.

Test interdependency
When running complex regression test scenarios, it is possible that one test may depend on one or more other tests. This is quite common and may occur, for example, as a result of a new “Order ID” being created as a result of a test step. Subsequent tests may want to verify that a) the new order is correctly displayed in the system, b) changes to the order are possible, or c) the order can be successfully deleted. In either case, the “Order ID” value that is dynamically generated in the first test must be recorded for reuse by subsequent tests. Depending on the design of the TAS, this may be addressed.

Preconditions for the test
Often a test cannot be run until initial conditions are established. These conditions may include selecting the correct database or test data set to test against, or setting initial values or parameters. Many of these initialization steps required to set the preconditions for a test can be automated. This allows for a more reliable and dependable solution if these steps cannot be missed before the tests are executed.
When regression testing is moved to automation, these preconditions must be part of the automation process.

SUT coverage
Each time tests are run, some portion of the SUT’s functionality is tested. To determine the overall quality of the SUT, tests must be designed to have the broadest and deepest coverage possible. In addition, code coverage tools can be used to monitor the execution of automated tests and quantify the effectiveness of the tests. Through automated regression testing, we can expect over time that additional tests will provide additional coverage. Measuring this is an effective way to quantify the value of the tests themselves.

Executable tests
Before converting a manual regression test into an automated test, it is important to verify that the manual test is working correctly. This is the correct starting point to ensure a successful conversion to an automated regression test. If the manual test is not executing correctly – whether because it is poorly written, because it uses invalid data, because it is outdated or does not match the current SUT, or because there is an error in the SUT – converting it to an automated test before the root cause of the error is understood and/or fixed will result in a non-functioning automated test that is wasteful and unproductive.

Large regression test sets
The set of regression tests for an SUT can become quite large, so large that the test set cannot be fully executed overnight or over the weekend. In this case, concurrent execution of test cases is an option if multiple SUTs are available (for PC applications, this is probably not a problem, but if the SUT consists of an airplane or a space rocket, it is a different story). SUTs can be scarce and/or expensive, making concurrency an unrealistic option. In this case, running only parts of the regression test may be an option. Over time (weeks), the entire set is eventually executed. The choice of which part of the regression test suite to run can also be based on a risk analysis (which parts of the SUT have been changed recently?).

Source: ISTQB®: CTAL Test Automation Engineer Syllabus Version 1.0