I recently read an a article entitled “When not to automate testing?”.
In that article it was suggested that it was not worth automating regression testing for (or even manually regression testing) areas of an application that are rarely changed, even though other areas of the application are under constant change. What was the rationale behind this statement? Automation is hard and time consuming and the code isn’t changing.
Well, I don’t agree.
Firstly, it is absolutely necessary to regression test those areas of the application that are not being changed. Just because the code isn’t changing, it doesn’t mean that a change elsewhere is not going to impact it. Of course, a proper impact analysis of a change should highlight other areas of the application that may be affected. However, as we all know, things get missed and the first time you know about it is when something goes wrong in production and impacts your ability to do business. Therefore, regression testing is essential.
Secondly, these stable areas of the system are good candidates for automation. As they are not changing, the automation will also not require changing. Once a regression test has been automated it can be run as often as you please. And I can almost guarantee that issues will be uncovered.
Lastly, automation does not have to be hard. The market has moved on from the purely developer-focused programmatic tools and the mechanics of creating automation are themselves being automated. What is required is an effective process for identifying what to automate and a plan to create that automation. Of course, a sensible choice of tools will minimise the time taken to create the automation and empower a much wider group of people.
Theme by Danetsoft and Danang Probo Sayekti