Our mission, as testers, is to adjust the balance: you should know which parts should be automated and which parts should be done by manual testing. But what is better, automatic testing or manual testing?
Testing is testing and must be done between developers and testers. Every kind of testing is great. It’s a task for every member of the team, not just one person. It all comes down to team needs and cooperation between testers and developers.
To help you choose the right approach, take a look at pros and cons of both types of testing.
Manual testing pros
Manual testing is suitable for usability testing and it is used to evaluate a product by testing it on users and getting a direct input on how real users use the system. That kind of testing cannot be automated because it requires human interaction. This kind of testing is a well known way of evaluating how users feel while using the product.
Another type of manual testing is exploratory testing, used mainly to explore new functionalities and to find bugs. New functionalities are not familiar to testers so they cannot be automated and have to be done manually.
So to summarise – manual testing is the right approach for finding visual or UX bugs and for testing new functionalities.
Manual testing cons
The cost of manual testing depends on human resources dedicated to testing. If there are not enough testers, the quality of a product decreases because the sufficient amount of tests is not completed.
Manual testing is often slower and the probability of human errors is higher.
Furthermore, manual testing is not suitable for some types of testing (such as stress testing) or performing complex test cases. This is because testers are not able to perform simultaneous testing of the product.
Automation testing pros
Automated testing is the perfect choice for regression testing, performance testing, load testing, and repeatable functional test cases.
Automated testing is more reliable and quicker than manual testing. A lot of tests can be executed quickly and any failures or errors are clearly visible (automatic validation fails and testers get the error).
It increases the development team’s productivity (there is quicker feedback because automated tests can be executed without human interaction).
In addition to this, automation testing improves project quality and coverage. Automation testing covers some layers of architecture that manual testing cannot reach, such as controllers, DB, integration, backend or frontend tests. These layers could be tested more quickly than by doing them manually and if they are executed periodically, testers could find bugs that manual tests could not reach.
Automation testing cons
Automation testing requires knowledge of automation languages and tools that perhaps some testers do not possess. That could lead to switching from testing time to training time and increase the test time by trying to acquire that knowledge (time that maybe the team or project does not have or cannot afford to spend on learning).
Another con is that automation is a repetitive process, so all new functionalities have to be tested manually first before automating that process, thus new features cannot be automated. This is why manual testing is always the first type of testing to use.
Last, but not least, is that a team can spend a lot of time debugging tests trying to understand why the test has failed and fixing them if the test is not correctly programmed. This process is time-consuming and can even cause missed deadlines.
Which approach to choose?
A good rule for choosing the right approach is to make sure that automation covers selected parts which are not going to be changed periodically, so the time invested to automate these parts will be, at the end, less than repeating that testing manually. Wasting time costs money, so we have to use all available resources properly.
Using for a short period all resources to automate parts of the applications will lead to getting those resources available in the near future. This is why it may be a good idea to consider automation testing over manual testing. But, in order to do that, we need to make sure that automation coverage is better than a manual one.
How to automate
Sustainable automation must be simple, reusable, dynamic and centralised. QAs have to be able to move most of the tests down into the lower layers where UI changes will not affect the integrity of the tests.
Achieving this doesn’t have to be time-consuming or complicated, because in the end, it is irrelevant which software or which programming language is being used. Basics are always the same – as a tester, you should know the environment, decide a strategy to follow, implement it and test it until you find ways to improve that strategy.
Follow the rule for testing: Write before doing. When you are writing the test, think about whether it could be done automatically. If it can, write it again and then execute it.
The workflow is simple: write a test, test it, test it again to debug it and improve it, if possible. QA professionals’ responsibility is to embrace the technology, find ways to improve it, adapt it to suit the team’s goals, and understand the value of the automatic testing to eventually produce the best possible outcome.
Our advice to QAs?
As testers, we have to get to the next level, always trying to perform our work better and deeper, finding useful ways to improve, even if it implies spending more time exploring and refactoring already valid tests.
Automation tests should never stop changing. QAs have to take advantage of the technology and use it and never stop improving themselves and their tests. Only in this way will they be able to fulfil their goals and never stop adapting.
