The never-ending discussion of manual versus automated testing continues unabated in work environments when we face the challenge of controlling the quality of a product. This is because there is more than one way to perform a QA process with good results. The key is to find a quality control process that best suits the product we want to test and define the working methodology of the development and testing teams. This is what EmpathyBroker is putting into practice to improve its quality control process.
The “controversial” automation of testing brings benefits, allowing us to improve the quality control process just as long as it’s applied in appropriate areas or scenarios. As Jorge Gabriel concluded in his post “Let’s talk about Testing”, the objective of this technique should not be to eliminate manual testing, but to complement it.
Myths and Facts
On many occasions, I have read that automatic tests are more reliable than the manual ones. The truth is that test software is like any other software, it can contain bugs. One of the most important limitations is the fact that automation can only verify what it has been programmed to verify.
For example, let’s imagine an eCommerce quality control process. We can check that when we search for dresses that product is being returned in the results, but we can’t check whether the colours and clarity of the accompanying texts allow us to read them clearly. Automated tests can detect if the filtering of search results is working correctly, but we would not have information about whether the use of this functionality is intuitive.
In short, we can check for bugs, but we cannot guarantee their absence. Does this mean that automation is not useful and that we should leave everything to manual testing? I think the answer has to be no.
In order to achieve a complete and more efficient quality control process, it’s essential to ask yourself which processes can I automate and how? The real challenge is to correctly determine when an automated test is useful. To answer this question developers and manual testing teams play a key role.
In most cases, the tasks to be automated are checks that the manual testers have previously detected. As some articles highlight: “Automated testing is not really testing, but fact checking.” This type of check has the main advantage of saving time. This is why repetitive testing tasks for manual testers are the most likely to be automated.
For example, let’s imagine that in our eCommerce site we have different markets and languages. To manually test a functionality like the search engine we would need to try all the possible combinations of all the possible market and language variables, which would take a considerable amount of time for the manual tester. In addition, human errors may occur as a result of the continuous repetition. However, through automation, we could check, for example, if the non-results page is displayed in all markets or in all the different languages in a way that’s faster and less tiring for the tester.
Thanks to the time savings automation can achieve, this frees up the manual testers to be able to focus on exploratory tests to find other bugs or to test new features that may have been developed. The work of the manual tester is not replaced, both practices feed off each other to find a harmonious balance.
One of the most common uses of this type of testing is smoke tests. Its objective is to ensure that the critical functionalities of the system is working. These are usually simple tests, of a short duration, which are executed after a software build to check the basic functionalities.
A useful practice is to have a series of these tests running periodically. This ensures you’re able to quickly detect errors and save the QA team time by being able to check a system where errors have already been detected. On the other hand, these tests require continuous maintenance.
So-called regression testing is another type of check for which automation is perfectly suited. Its purpose is to determine whether the current functionality of an application is maintained after a new one has been added or after changes have been made. This is an essential feature if we bear in mind that when correcting a detected error, we may also be introducing a new one, and what worked yesterday may be broken today. Regression tests usually have a longer duration than the smoke test mentioned above, and are executed before a push into a production environment.
Sometimes, the behaviour of a system can vary according to the number of users that are using it, so another area where automation works well is in load and performance testing. This test allows us to simulate the use of a system by a large number of concurrent users, delivering valuable information such as the errors generated when requests are made or possible application response times. This type of testing is very valuable in systems that must support a significant number of simultaneous users. At the moment, there is no way to perform this type of test manually.
Additionally, the ability to store tests in code is not only a time saver for the project under development but these can be reused throughout the entire lifecycle of the project. They can also be used for newer versions of the product or even similar variants that may be developed in the future.
Like all types of tests, automated testing has its pros and cons. However, the benefits of automatic testing are greater than the time and extra effort of writing and maintenance.
With well-designed automated testing working in combination with manual testers and developers, we can make a positive step towards achieving the desired objective of ensuring product excellence.