07 Mar Can automation completely replace manual testing?
Did you know that a car is manufactured pretty much 1 per second? This kind of productivity and efficiency is purely possible due to the automation using robots. There are several reasons why robots became popular. First and foremost, they don’t get tired easily, they do exactly as they are programmed to do, and their productivity is not driven by emotions.
Some of the successful stories of automation from manufacturing sector inspired the software development teams as well. If you are part of a team applying the latest methods like Scrum, XP, Kanban, etc, you would have heard your Agile coach or Scrum Master asking you to automate your test cases, integration and deployment.
There is nothing wrong with automation. However, I always recommend challenging the rationale for asking you to automate things. Common answers your could expect include, efficiency, productivity, cost reduction, time to market and quality.
Let us take the example of automating the testing process. Some of the questions, one should ask before introducing automation in this scenario include:
- What are we planning to automate?
- Does it make economic sense to automate?
- Do we have necessary tools?
- Does our team have skills to maintain the automation system?
- How much should we automate?
- Do we need any manual testing after automation?
Somehow there is an inherent assumption that once testing is automated, we don’t need any manual testers. I beg to differ, in the sense that we may not need as many “manual” testers we needed before, but we need “automation” testers with the ability to manually fix the automated system. We need humans to build and maintain the automation system and also if the system breaks down we need people to fix it. In addition, not everything could be automated.
One should not get fixated with automation too much. One should remember that “automated” system is built manually by the testers on the ground. If the testers are not skilled enough, they would in turn build a faulty automation system.
This scenario of unskilled testers building an automated system would cause more harm than any help. For example, if the testers are feeding wrong tests to automation system, the system in turn keeps executing the wrong things day-in and day-out. This in turn results in releasing a faulty, bad quality product to your customers more often.
It is also essential to know when not to automate. For example, there are many organizations still running legacy systems like mainframes and Siebel systems. There are not many tools available to automate tests in this legacy world. Even if you do so, the effort and cost needed would be much more than the effort needed in manual testing. Someone told me once that an automation tool for a mainframe system could cost anywhere from couple of thousands of $ to a million $. Unlike in Java world, where the open source tools are available free, it would not make any economic sense to buy an expensive tool to automate tests in mainframe.
Here are some tips to keep in mind before embracing automation
- Automate tests that are repetitively executed manually by testers
- Ensure that the cost of automation makes economic sense in the long run
- Don’t try to automate for a short term project
- Automate only when you have enough skilled testers available to manage the system
- Ideally 100% automation is the goal, however, due to the complex nature of the software development, manual testing is essential
- A highly skilled manual testers managing the automation tests helps in building a quality product
