Test Automation from the Manual QA Engineer Side

Many manual testers have a wrong idea about the basics of test automation, as a result, they draw false conclusions. In the following article, we will take a look at the top 5 questions about what test automation is and why switching to it is a must-have!

Author: Nataliia Syvynska, TestMatick, https://testmatick.com/

1. Why Should Something Be Automated if QA Engineers Can Do It Manually? 

Of course, there are at least three factors to consider before you start implementing automation on a project:

• What is the project duration, what is its current scope, and how much it can be changed;
• Analyze how costly it will be to develop automated tests for a particular case. Sometimes, it is more difficult to automate tests than to execute them manually;
• Automated tests aren’t a good option if the system structure is completely changed on a project.

However, if the project is running consistently, involves more and more staff and new functionality is added to it, the test can and have to be automated. In this case, all developed automated tests can become a kind of guarantee that nothing fails, while the programmers are developing new functionality. Of course, manual regression tests are great, but they are inextricably linked with the human factor, the tunnel vision, and unpredictability of places where bugs can be found. And at the same time, no one completely rejects manual checks because the need to check the functionality, which can be updated in a while, will not go anywhere!

2. Is It Possible to Learn How to Develop Automated Tests in Just 1 Day?

You can develop tests right at the moment of studying profile courses, but it’s better not to rush, and to resolve such a question as consciously as possible. If you’ve never tried your hand at automation before, it will be extremely difficult at first. It is very challenging to start writing tests if you don’t have examples at hand, and there is nothing to lean on technically.

Fortunately, nowadays the Internet is full of all sorts of articles and materials with lots of useful examples, where you can take the basis and adjust it to your tasks, thus developing something of your own.

After all, to start automating, it is necessary to start trying to automate. This rule works under any conditions. If you have questions, do not hesitate to ask programmers, and if they cannot or do not want to help, the Internet has many QA communities, where you can get answers to any question.

3. Can I Be an Automated Tester Without Any Manual QA Experience?

Maybe you have some sort of programming experience. In some product companies, this actually works. Manual testers work on designing automated test cases, and the automated QA engineer puts it all into an HTML code structure. This kind of approach works, but it can have a bit of a catch:

1. First, when you develop automated tests by yourself for functionality that you know well, you can independently (while working) add some tests that may have been missed during the test-case creation process. Moreover, there will also be automated tests, which you can add to, if necessary. And, as a result, it is very easy to keep tests up to date in this way.
2. Secondly, software test automation is extremely interesting and useful. A user starts studying the code, extends his/her knowledge about the product, understands how everything works from the inside. This practice is useful for a manual tester as well.

4. Can Developers Write Automated Tests?

In general, yes, why not. But probably, they won’t like to do so. That’s because:

• It would clearly slow down the development process itself. Instead of developing program code, working on product functionality, programmers will be busy developing automated tests.
• This is very expensive.
• Each of the participants must mind their own business. Programmers are busy developing functionality, QA is busy validating it. It’s the same with automated tests as with manual testing.

5. Can I Develop Automated Tests Automatically?

You can try. For such purposes, there are special recorders (often used by game testing companies). But the problem is that the tests they develop are humongous and poorly supported parts of program code.

It is recommended to use them in some difficult parts of the software to analyze which ways of interacting with hard-to-find parts of functionality can be covered by the tests. That is, in other words, to use it as a faithful helper, as a special auxiliary tool, rather than as a basic tool for test automation.