Answers to all embarrassing questions about automated testing that you always wanted to ask but were afraid to. Help yourself!
The fact that automated testing is expensive often prevents product teams from turning to it at the very beginning of the project. In this article, we answer the most common questions our clients usually ask us about automated testing, when it’s the best time on the project timeline to embark on test automation, and try to figure out how it can help teams be more efficient.
Automated testing means that tests are fully performed by machines? Doesn’t it require any human participation at all?
Well, it’s clear from the name itself that there is no “handicraft” in automated testing. Basically, everything that is done by humans in manual testing, is performed by software tools and scripts in automated testing. For example, in automated UI tests, the script fully imitates the way an ordinary user interacts with the application to check whether the interface responds to user actions as it should.
However, humans still play a big part in automated testing when it comes to developing testing frameworks and scripts, as well as keeping them up-to-date. This is done by automated test engineers — first-class specialists, who are well-versed both in engineering and testing. As for tools and scripts, they are used mostly for repetitive tasks that can easily be programmed, such as detecting bugs, reporting them in a bug-tracking system and notifying responsible engineers.
But all this can be done by manual QA engineers too! What’s the point in expensive automation then?
The main advantage of test automation is that it can release manual QA engineers from tiresome and time-consuming work, such as regression tests. Unlike humans, scripts can’t get tired and lose focus from monotonous and repetitive tasks, that’s why they can be much more productive and time-saving than manual tests.
Moreover, unlike manual tests that require time and effort from a responsible human, automated tests can be performed any time by any team member. For example, an engineer can run an automated unit test to check a new piece of code immediately after committing it and see the result immediately without having to wait until a QA engineer has time to do the job.
Another advantage of test automation over humans is that automated tests can easily make complex calculations. Let’s say we need to make sure that an algorithm inside a financial application calculates monthly loan payments properly, taking into account various dynamic data, such as interest rate, exchange rate, etc. Apparently, it will take eternity for a manual QA engineer to check all calculations, while an automated test will handle them instantly.
Finally, it’s obvious that automated tests can simply work faster than any human, therefore, an iteration of automated testing is much cheaper than manual testing. As a bonus, after the testing cycle is over, anyone in the project team can access the report and see all the reported bugs. Moreover, the process of detecting and fixing bugs can be automated even a bit further; for example, when upon detecting a bug, the script creates a ticket in a bug-tracking system and then subsequently sends a notification to a responsible engineer.
Wow, does it mean automated tests are so cool that we don’t have to hire humans anymore?
Automated tests are not a magic bullet. First and foremost, they are just scripts that are programmed to check specific things in a certain way, but, unlike humans, they lack improvisation. For example, if a script is programmed to check if there are only “two” buttons in a registration form, it won’t report a bug If suddenly a “third” button appears, simply because it’s not programmed to do this.
We don’t want to paint only a positive picture with no areas for improvement. For example, test automation requires extensive investment and preparation to embark on. While manual QA engineers only need documentation on hand to start working, it’s not that simple with automated tests. First, we should define clearly what app functionality will be covered by the tests, ideally with a prototype on hand. Then, we should choose a preferred tool and develop a testing framework to start working, lastly, it’s important to constantly keep an eye on the scripts so that they stay up-to-date as the product functionality changes and gets updated. As you see, it’s a pretty laborious process.
Finally, not all types of tests can be automated. For example, automation is not the best option for usability tests, because the script will never be able to determine if the application is comfortable to use. There are also certain restraints for automated UI tests, such as captchas, emails, etc.
In general, it’s fine if 90% of your products repetitive tasks, such as regression and load testing, are performed by automated tests, while the other remaining 10% (that cannot be automated), is handled by manual QA engineers.
Now that it’s more or less clear… If I decide to use automated tests in my project, what part of the SDLC would be the best time to start?
If you are planning a long-term project with frequent updates, start as early as possible. Ideally, you should hire both a test automation engineer and a manual QA engineer at the same time. You’ll find proof on the below chart:
While test automation is much more expensive than manual QA at the beginning of the project, it can be less expensive in a long-term project because as the project grows, you’ll have to hire more “manual” QA engineers to test new features and updates, therefore, the cost of manual testing will increase significantly. At the same time, the cost of test automation will remain relatively low and stable because you won’t have to hire more specialists to keep scripts up-to-date.
If you are still not sure where to start test automation, the general recommendation is the following: if you know exactly what your product should be in the future and you don’t plan any major changes and revamps, be sure to embark on test automation as soon as possible.
Again, don’t think that automated testing will solve all your problems, though, a well-blended mix of manual and automated tests has the possibility of doing this. Automated tests lack intellect, at least for the time being, but when the human intellect joins the speed and accuracy of machines, they make a dynamics duo. Don’t hesitate to benefit from it.
Originally published at yellow.id.
