How to become a testing automation?

Good afternoon!

Yesterday, answering, it seems, for the sixth time to this question, he firmly decided that the time had come to write an article. I’ll note right away that this is only my vision, which I’m sure a good half of the world of automation will not agree with — my recipe is somewhat more complicated than “reading about tools”, “putting tools”, “using tools”, “writing what you can do in a resume use tulza. "

This article is useful not only for manual testers who want to automate their routine checks, but also for businesses and HRs, who, due to the absence of any generally accepted criteria, usually have no idea who the QA Automation Engineer is and in most cases decide based on "good man."

It happens even worse - the head of / PM / etc ... comes to their manual testers and says: “Listen, maybe we will automate our testing - this will save us a lot of time and money. Tell me which books you need and which courses. ”

0. Let's start with mistakes that should not be made:

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

This is all good, but only in addition to the recipe, which is described below. In no case can not begin with this.

1. First of all, you need to choose a programming language
Not tools, not TestComplete, not macro-like pokes on the screen. A object-oriented programming language. I used to work a bit 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 a Delphi application is tested through WinAPI (but it is better to use Delphic DUnit for such tasks and so on).

So, we learn what primitives, classes, objects, polymorphism, encapsulation, interfaces, abstract classes, static fields, loops, arrays, sheets, maps, flows, and so on ... This study will continue as a whole all the time, even when you already automate testing. But at a basic level - Junior Java Developer - you must (if you chose 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 played out incomprehensibly and it’s not clear why” - your task is for the developer to know that a person nearby can find bugs without even launching the application. Do not believe it, when 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 moved smoothly to

2. Using design patterns to develop a test framework.
YES YES. You opened, for example, Selenium, - all sorts of examples, thoughtlessly copied, 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 a bit to the market here”, the developer cuts everything perfectly, - 90% of the tests fail. They come to the automation “we changed a little here, we need to put the tests in order”, and the automation in response to “there is work for a month” ... Oops ...
The framework architecture you write should not only be flexible, but should constantly strive to minimize the time for refactoring existing tests and writing new ones. Ideally, if a developer and an automation engineer sit down to fix something at the same time, then the automation engineer should do everything faster and provide the developer with some form of TDD.

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

3. Using libraries
What smoothly flows into any tasks is external APIs, libraries, drivers, and other delights. 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 many APIs, GSON - helps to bring json to and from the object model and so on and on ... Many beautiful libraries have been written for almost any task - you can read about some of them here . Do not be afraid that there are a lot of them - you already know enough to choose what suits you / likes / fits into the architecture. For example, for testing Java Swing applications, I use JUnit, Fest, Mockito and the extensive features of java.lang.reflect - this set 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 you will need to look into the source. And most importantly - do not be afraid not to figure it out.

4. Test planning / writing tests
In the framework of this article, I do not talk about the fact that the idea of ​​100% coverage, about scheduling scripts, etc. is detrimental to any project. In general, classical testing approaches are detrimental in automated testing - for example, isolated input for tests. In general, your skills, the ability to think analytically, the ability to doubt what to doubt and not to look for a problem where it cannot exist, already play a role here. Good test scripts are like a good interface ... they can't be perfect. My experience gives such statistics: 5% of all scenarios provide 95% coverage of functionality. 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 low which completely did not affect the main functionality and customer loyalty, and were quickly fixed. But for their sake, it’s unprofitable for money to make another 2000 tests - I’m turning to the leaders and businesses who dream of 100% coverage. Believe me, you do not need it. Here I’ll make a reservation if it’s not about automatic testing of security or billing - here the risks should not be minimized, but, if possible, reduced to zero. But this is another story ... if possible, reduced to zero. But this is another story ... if possible, reduced to zero. But this is another story ...

5***. Writing utilities and own libraries
There are asterisks ... You have everything wonderful on the project, the regression is covered, the tests are chasing, 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 his hands, the developer has to do the same action with his hands from month to month. Write a utility for it that optimizes these processes, include all sorts of invalid scenarios there, advertise at the company level, let everyone start using it ... This will speed up the work and, oddly enough, reduce the number of bugs, as the developer will have more time to check more scripts before committing changes to the branch. Look around and you will see so many processes that can be automated that you won’t know what to take.
Write quite abstract libraries that can be used on different projects in your company, and simply in your work in the future.

Conclusion

You, of course, you can think to yourself "crap", but ...

• yes, this is not the shortest, this is the way that you can go through which you can become a really cool specialist
• this is a very interesting way - thorny, but interesting
• you are absolutely confident as a specialist
• if you are tired of automating testing, you can safely go to the developers
• You do not depend on any paid tool, in which there may also be bugs.
• if you organize everything correctly (it's like professional administrators do), then you will have a lot of free time for self-development
• Well, more wealth :)

PS
For business, managers, and recruitment specialists: A

professional testing automation tool ultimately saves company money, I would even say, in the short term. We look at a comparison very close to reality here .