Automation testing, by rerunning a test over and over again, is just revolutionary for teams. But automation testing cannot replace manual testing or manual testers as many people think. In this article, let’s discuss the 6 major differences between manual testing and automation testing. Through that, you can better understand the nature of each of them.
Table of Content
The short-term cost of manual tests is fairly lower than automated tests. In manual testing, initial efforts can go all into creating test plans and test cases, without any license cost to pay. And there’s also no learning curve, as human testers can gradually understand how the system under test works. Because writing manual tests require lower skills compared, you can expect more savings from employee training or onboarding.
On the other hand, the upfront cost of automation testing is prohibitive. Commercial test automation tools are generally expensive. Usually, these tools are sold on a per-user installation basis. The price can be up to $1000 or more per user per year. This is not to mention the renewal cost to pay each year. While there are open-source tools with no license fee such as Selenium, they are not a good fit for teams inexperienced with automation. Free tools are very difficult to install and use for testers with low or no coding skills. Support for these tools is also limited to the user community or forum, rather than professional staff.
Having said that, the cost of automation testing can be lower than manual testing in the long run, commonly from 9 months onwards. In a real-world project, automation testing costs substantially more than manual testing in about the first 10 months. This is mostly due to the license fees of tools and implementation costs. But after that, the efforts and money going into automation become gradually less than manual testing thanks to the reduction in man-hours.
In manual testing, tests are performed, well, manually without the help of any automation tools. A testing process can still be considered “manual” if test case management tools like Jira are used. In contrast, automation testing relies on automation tools, such as Selenium or Katalon, to execute and monitor tests.
However, automation testing cannot happen alone without first performing manual tests. If you don’t run manual tests, then you couldn’t validate that those tests are suitable for automation or not. It clearly says in the principle of automation testing: 100% automation is not possible. Thus, manual testing is irreplaceable.
In manual testing, some degree of vagueness is acceptable—and popular even. But automation testing requires everything to be precise.
Some explanations may be useful. Manual test cases are written by humans (manual testers) for other humans (other manual testers, developers, business analysts) to consume - i.e., read, understand, and execute. In some cases, the clients are also involved in this consumption of test cases.
Even though manual tests are meant to be consumed by all stakeholders, in reality, test cases are usually executed by the people who wrote them. In other words, many testers intend test cases to be a description of what they need to do, not of what others should understand. This one-sided process can make the test cases vague.
While humans can try to grasp with vagueness, computers just can’t. It does not make sense to write general, ambiguous test cases for automation. This means that automated tests must be precise and detailed for the computer or tool to run.
That’s why when many teams first try to convert manual tests to automated tests, a lot of questions arise. It’s important to resolve every one of them to automate the tests. And the answer to those questions is reflected in the automation script when the tests run.
Yes! It’s a lot of work to get done. But those questions, once resolved, can sometimes reveal more bugs than when you actually run automated tests.
You should expect that the test cycle changes when the application changes. Therefore, test cases are supposed to be adjusted often to account for changes in application. However mostly this does not happen in manual tests. In cases where the changes to application are minor, manual testers can understand those changes and what they should do from there without writing new test cases.
But for automation testing, it’s a different story where every little detail matters. So automated test scripts must be updated whenever changes, even the minor ones, to the application under test.
Let’s consider an example. Your application has the “Setting” menu being included in the “Account” menu. But at some point the “Setting” is moved outside the “Account” and now sits next to it. While the manual testers can easily understand this change and can locate the “Setting” menu, the automated code just can’t. Every change to the application matters, which must be reflected in the scripts.
Sensitivity to Change – Preciseness and Maintainability Put Together
From the preciseness section above, many would think of automated scripts as full of details. And from the maintainability, the more details, the harder it gets to update the scripts. It now seems that keeping automated scripts precise and maintainable is impossible.
Luckily, preciseness is not stuffing the scripts with as many details as possible. The details must be defined, but they can be defined somewhere else, not necessarily the scripts. Not only a container of scripts, a test automation framework could be modular-based, meaning the application is divided into separate modules to test. Test scripts are created for each module, and these scripts are composed into larger scripts. This method, known as modular automation framework, has one major benefit. It’s that changes to the applications only require updates to the module and the scripts it contains.
When you first execute a manual test case, you may find yourself in unexpected conditions that you couldn’t have planned for when you wrote the test case. After that you may fix the test case to account for those conditions. And this same process can happen to automation testing, but during when you develop the automated tests, until the test passes at least once.
After this first stage, either it’s manual or automated tests, there are unexpected conditions that you can face. Those could be a new bug in the product (regression), an update that you weren’t aware of, an environmental issue such as network failure, or an event that the test was not designed to deal with.
Even though many same conditions can happen to both manual testing and automation testing, the way they are handled is different. Manual testers are able to tell which condition is which, and how to resolve them. For example when there is a product bug, the tester can report the bugs and then continue to run the rest of the test case. On the contrary, anything unexpected and not specified in the automated test cases can confuse the automation tool.
This article has looked into the 6 ways that manual testing is different from automation. While each method has its advantages, the right mix for manual tests and automated tests is important to meet today’s need for agile delivery.
Don't know where to start with Automation Testing? Contact us now! At KMS Solutions, we help enterprises plan, design, execute, and monitor automated tests for top-notch products.