How to become a test automation?

Good day!

Yesterday, answering, it seems, for the sixth time to this question, I firmly decided that it was time to write an article. I’ll note right away that this is only my vision, with which, I am sure, half the world of automators will not agree - my recipe is somewhat more complicated than “reading about tulz”, “putting tulz”, “using tulz”, “writing in a resume that you can use tool.
')
This article is useful not only for manual testers who want to automate their routine checks, but also for business and HR professionals who, due to the absence of any generally accepted criteria, as a rule, have no idea who is QA Automation Engineer and in most cases decide based on "good man."

It is even worse - the supervisor / PM / etc ... come to their manual testers and say: “Listen, or maybe we automate our testing - it will save us a lot of time and money. Tell me what books you need and what courses. ”

0. Let's start with errors that should not be allowed:

• Give me a smart book that will do everything for me.
• Give me paid courses that will teach me everything.
• Give me specialized forums that answer all your questions.
• Give me a useful certification with which I will be accepted everywhere.

It's all good, but only in addition to the recipe, which is described below. In no case can not start with this.

1. First you need to choose a programming language.
Not a tool, not a TestComplete, not a macro-like screen. And an object-oriented programming language. I once worked a little with C #, then I chose Java - and still have not regretted my choice. But I will not insist. I can only say that I have not yet encountered a single unsolvable problem in Java - even the Delphi application is tested via WinAPI (but it is better to use Delphic DUnit, etc. for such tasks).

So, we learn what primitives, classes, objects, polymorphism, encapsulation, interfaces, abstract classes, static fields, cycles, arrays, sheets, maps, streams, and so on are ... This study will continue as a whole all the time, even when you already automate testing. But at the basic level - Junior Java Developer - you should (if you choose Java) be familiar with the language and have the appropriate skills, because the primary localization of the problem lies on your shoulders. Forget about "but I have a script, the error is incomprehensible as it is not clear why" - your task is for the developer to know that here a person can find bugs without even running the application. Do not believe how suddenly the quality of the product increases when there is a person who not only hears the smell of a bad-smelling code, but can also offer solutions for improvement.

We smoothly switched to

2. Using design patterns to develop a test framework.
YES YES. You have discovered, for example, Selenium, - all sorts of examples, copied thoughtlessly, wrote 1000 tests on the resulting “framework”. The customer comes to the business, says “I need to redo something here,” the business comes to the developer, “we need to adjust to the market a little,” the developer has done it all in an excellent way, - 90% of the tests fall. They come to the automator "we changed a little here, we need to put the tests in order," and the automator responds with "work for a month here ..." Oops ...
The architecture of the framework you write should not just be flexible, but should constantly strive to minimize the time it takes to refactor existing tests and write new ones. Ideally, if a developer and an automator simultaneously sit down to correct something, the automator should do everything faster and provide the developer with some form of TDD.

Designing patterns and their competent use help us to create such a wonderful architecture ... Builder, Facade, Factory, Null Object, Singleton, Adapter and many other patterns actively help in solving such problems. Literate test framework architecture is a blessing for you, for developers, for business ... and ultimately for the user. Remember that the exponential growth of test support resources with a linear increase / change in the functional indicates that it is time for you to refine the engine architecture. The most complete list of patterns with examples in Java can be found here . Separately, I note the Page Object Pattern, but it is better to first get acquainted with the classic.

3. Using Libraries
That smoothly merges into any tasks - external API, libraries, drivers and other amenities. Selenium - we test Web, Robotium / Espresso - we test Android, Fest / Jemmy - we test Java Swing, JemmyFX - we test JavaFX, wonderful Apache HttpComponents - we make requests and we test a lot of API, GSON - helps to bring json to the object model and back and so on to infinity ... The libraries of the beautiful ones are written a lot for almost any task - you can read about some of them here . You should not be afraid that there are many of them - you already know enough to choose what suits you / likes / fits into the architecture. For example, I use JUnit, Fest, Mockito and java.lang.reflect for testing Java Swing applications - this suite is more than enough for me.

Be prepared for frequent visits to stackoverflow and similar resources in the early stages. Be prepared for the fact that sometimes it will be necessary to look at the source. And most importantly - do not be afraid not to understand.

4. Test Planning / Writing Tests
In this article, I am not talking about the fact that the idea of ​​100% coverage, scheduling, etc. is destructive for any project. In general, classic testing approaches are disastrous in automated testing — for example, isolated test input. In general, your skills, the ability to think analytically, the ability to doubt what should be doubted and not to look for a problem where it cannot be, already play a role. Good test scripts are like a good interface ... they can't be perfect. My experience gives the following statistics: 5% of all scenarios provide 95% functional coverage. On the current project, we have 180 full-fledged functional tests for almost 2 years of work, which provide us with these 95% - 99%, six successful implementations - the output is a bit of low remarks, which absolutely did not affect the basic functionality and customer loyalty, and were quickly corrected. But for the sake of them to fence another 2000 tests is unprofitable purely for money - I am turning to the side of managers and businesses who dream of 100% coverage. Believe me, you do not need it. I’ll make a reservation here, if we are not talking about automated security testing or billing - here the risks should not be minimized, but, if possible, reduced to zero. But this is a separate story ...

five***. Writing utilities and your own libraries
There are asterisks here ... Everything is fine with you on the project, the regression is covered, the tests run, the developers are calm and can calmly refactor the architecture without fear of breaking the existing functionality. But, for example, in order to emulate something with hands, the developer has to perform the same action with hands from month to month. Write for him a utility that optimizes these processes, include any non-valid scenarios there, advertise at the company level - let everyone start using ... This will speed up the work and, oddly enough, reduce the number of bugs, since the developer will have more time to Check out more scripts before committing changes to a branch. Look around and you will see so many processes that can be automated that you will not know what to undertake.
Write enough abstract libraries that can be used on different projects in your company, or simply in your work in the future.

Conclusion

Of course, you can think about yourself “zeee”, but ...

• Yes, this is not the shortest, this is the path that you can take to become a really cool specialist.
• this is a very interesting way - thorny but interesting
• you are absolutely confident as a specialist
• if you get tired of automating testing, you can safely go to the developers
• You do not depend on some kind of paid tool, which can also have bugs.
• if you organize everything competently (like professional administrators), then you will have a lot of free time for self-development
• Well, more material wealth :)

PS
To business, managers, recruiters:

A professional automator of testing ultimately saves the company's money, I would even say, in the short term. We look at the comparison very close to reality here .