Today test automation is seen as a strategic step and gains a lot of focus in software testing world. Applying to automated tests company saves costs, decreases overall time of testing cycle enhances product quality, and enables the staff to focus on testing details.
Nevertheless, there are risks associated with test automation; paying attention to each one of them you are able to manage the process successfully. When automated tests are under go, changes made in the interface can cause serious problems, like irrelevant test results.
The occurred problems cause additional costs to provide support and analyze outcomes. Anyway, to prevent the problem you need some kind of mitigation plan. First of all, the development team should share the interface changes with QA team, and of course, monitor the irrelevant test results related to the changes.
Similar problems may occur because of changes in business logic. Apart from the irrelevant test results, support, costs increase, it can yield to changes in test data structure and can impact other cases. The cautions are pretty much the same: share the changes with QA team and monitor the irrelevant results.
Besides the changes huge number of defects in functionality can also pose threats, such as improper execution of some of the automated tests because of the defects in others (if the tests are interdependent). The consequences are quite unfavorable, first of all, the results are to be analyzed (tests should be covered manually), while the costs get increased and can be compared with manual testing efforts. Along with that test development is more expensive, when functionality is unstable.
Though, the challenge can be eluded, for that very purpose work out necessary rules or instructions and follow them. Firstly, automate critical path functionality (small number of test cases), then monitor irrelevant test results related to defects and, of course, monitor extra test development efforts for such cases.
There`s a risk of the issues related to the environment execution. For example, when background processes are scheduled on test server, it increases test execution time as application works slowly. . In the situation like this the plan of mitigation will consist of monitoring the irrelevant test results related to environment, and tracking the test execution time. The impact of the environment issues is quite small for web projects, though it can be serious for desktop and mobile applications.
Along with that all, parallel test execution may impact on test data, which causes again irrelevant test results. To preclude such problems, it is useful to create independent datasets and implement procedures, which reset datasets.
Mitigation plan is not the only prevention from the arising problems, along with that you are to care about the automation solutions (from technical point of view) that are based on principles that reducing the impact of risks, when they occur. Just keep in mind that is always better to prevent the risk than to remove the consequences.