https://habrastorage.org/getpro/habr/post_images/d6f/b64/ab3/d6fb64ab3b3da0fc545bb79c18be54a8.jpg
Against the background of constant talk of global information, the rapid development of IT industry and, in particular, software development technology, there are reflections on the harmony of this development. If software development by leaps and bounds moving towards DevOps, automation tools, and continues to move, though no longer as active in the Agile side, that's where automated testing is moving?

Although the fact of test automation in advanced CIS companies could find evidence, but it is a confirmation, in fact, it turned out to formal. As they say, and "yes and no". At least it was a few years ago.

There is an opinion that is still not all companies understand, why do you need automated testing. And if we assume that such a situation does not change with the overall progress in the development of software, then there are doubts about the direction of the harmonious development of automated testing. Perhaps this lag occurs in all countries where software development is actively underway.

Of course, much depends on the direction in which this type of testing is used. In the case of web development situation, in my opinion, easier: a few years ago all conquered the Selenium, which is alive and well to this day. Also relatively comfortable settled autotests in desktop ARM development, ABS with databases: the NUnit tool remember the simple, obvious use is reduced to automatic testing them the same query to the database after the changes made by the developer. Surely, someone else will remember some good examples of the implementation of automated tests with a happy ending, or at least with a happy beginning.
https://habrastorage.org/getpro/habr/post_images/8d8/edf/e8d/8d8edfe8d5560d74cc7df6fa9109e284.jpg
Nevertheless, a huge number of attempts to introduce automated testing was reduced to such a result, "Well, we dig deeper, look, something that the test this way, but then still rechecking hands - you never know what ...". On the experience I have had to face, unfortunately, with this result. In many IT companies to automate the testing it was as an experiment, and sometimes - just a "thing in itself": tester writes something, starts doing this any conclusions, and the staff remaining departments really do not notice the difference between the Autotest efficiency and manual testing.
And if you remember that developing software is not only specialized firms, but also non-core companies with IT departments, the picture becomes even more pessimistic, since such companies, shall we say, other priorities.

Of course, we are talking about the true values ​​of commands rather than a "title" that often arise in an attempt to wishful thinking or influenced by the environment. If the test automation is implemented only because it is - in a trend, then the effect would be appropriate: the authorities pretend that they really need, the testing team pretend that introduces "advanced" technology and understand why this is necessary, and the rest of the staff pretend that notice some changes for the better.

Worse, when the company is no agreement on this issue: someone really believes in progress and is struggling to introduce new technologies, and someone just imitates the tireless activity. In such cases, the inevitable "battles" between employees, which, again, can lead to disruption of communication and isolation of innovations that still remain in their "sandbox". Then the initiators of change to break a lance tired and calm, waiting for better times.
https://habrastorage.org/getpro/habr/post_images/a7c/d01/c88/a7cd01c885e0126539705d060aaa195f.jpg
Such stories, of course, there were not only testing, but it is often perceived as a "brake" for developers. This is partly due to the situations where management has taken on testers work with lower qualifications than the developers. The reason was not only the desire to save on salaries of management, but also an objective fact - the CIS universities are mostly not supplied to the market professionals such as testers. A test automation requires a sufficiently high qualification and in programming and testing, which further complicates the situation.

Thus, in the IT industry (at least in the CIS) had the idea that qualified testers, able to engage in test automation, still less than skilled developers capable of solving non-trivial task. If many low-skilled programmers have not reached a high level, because they could not find the "self" (or simply because of their laziness), then the testers in the CIS was objectively less likely to receive highly qualified. It's not just universities, but also about internships, corporate training, professional development, advanced Russian-speaking community of testers - all of this a few years ago were poorly developed. Perhaps now the situation has changed for the better.

Whatever it was, it is necessary to make allowances for the fact that testing as a separate direction began to develop later than programming. If considered appearance methodologies such as TDD (Test Driven Development), BDD (Behaviour Driven Development) as another attempt to "play" this gap, then they are most successfully for long time existed in the form of beautiful ideas.
https://habrastorage.org/getpro/habr/post_images/1d3/299/81c/1d329981c8568723bd208e134599ec8f.jpg
In the transition from the ideal world underwent changes in real these concepts, which after them sometimes only had a name. Of course, every team is unique, and the adjustment is necessary, but the question is where to draw the line between the concept of adaptation and its degradation.

So we come to another lag - lag theory from practice. There is no guarantee that a suitable at first sight the methodology has been successfully implemented in one or another team without a critical loss. These losses can be shown not only that the little that remains after the introduction of the original concept, but in the fact that the development of the company's products seriously slow down. Numerous eyewitness accounts suggest that the introduction of the same TDD is necessary to literally turn the idea of ​​the development team. On it is necessary to spend a lot of time and nerves.

IT companies, aiming at commercial success, but it is not attained, can not afford to slow down or stop at the pit stop, "to change the shoes." Any change in process technology threatens their business. It takes us out of the field thinking about ideas, the progress of theory and practice in the area of ​​the financial interests of the company. Here the most important thing - to work quickly, "without the noise and dust, on the spot." From this perspective, it is important for the company to release the product for the minimum time, without any obvious errors and with minimal time to correct them. If testers are not only not all of the errors, but also allow their own to create automated tests, it is absurd and simply counterproductive.
https://habrastorage.org/getpro/habr/post_images/1f6/006/487/1f6006487b8d4248bd9aaad466aa519a.jpg
As before, there are new tools for automating various types of testing. In this sense, the direction is developing quite actively. However, many IT companies still not learned to identify which tools they really need and which are redundant. They learn not to assess the risks and time needed to introduce innovations. The contradiction between the need for these instruments and the difficulties with their implementation have not been resolved. This is particularly keenly felt a few years ago.

Given this situation, many companies are treated test automation with the utmost skepticism - until the complete denial. It is easier and cheaper to hire a couple of testers and spend a couple of extra design iterations. In part, there is a problem of opposition reformers and conservatives, but to a greater extent, in my opinion, it's still a matter of business survival.

The situation is different situation in those companies which can afford to allocate finances and other resources for research and pilot projects. Thus, obkatyvaya new technology, they convey their community experience. Adopting successful strategies, other companies can go to the "progress" after these pioneers
https://habrastorage.org/getpro/habr/post_images/c07/dc2/e9c/c07dc2e9cbdee691b05e0a9b788f82f6.jpg
Another category of "pioneers" - start-ups, who have nothing to lose. They gather a strong team and try that "no one has ever done before us." But their projects are not always sufficiently ambitious and difficult to separate the attention paid to the special testing technology. So once again the crucial role and impetus to the development of effective methods of getting programming.

A special case is a question of a general perception of staff jobs "developer-programmer" and "tester". Programmers are seen creative personalities that create complex structures from "nothing". They sort of optimists who believe that their code works. And testers - those who destroy these illusions. In a sense, the professional duties of the testers are to prevent the release of the product, seek to prove that he is not good enough, it contains defects. If programmers are working on the principle "Every mistake is corrected penultimate", their motivation would hardly have been higher.

Realizing that the testers also benefit the company, give feedback, employees may still feel some "precipitate". As a result, many subconsciously seek to step back and do not want to once again help the department test or contribute to its development. Much "nicer" to help, lead to the advancement of people who believe that they can do the "impossible" to the specified deadline.

As they say, all professions are needed, all professions are important, but the human factor is unable to neutralize. Sometimes people do not get to abstract from the purely psychological effects.
****

It is often said that the past seems to much better than the present. "Here in our time ..." - they say. However, in the case of test automation development is hardly possible to argue for the same scheme.
https://habrastorage.org/getpro/habr/post_images/ed7/866/6a5/ed78666a5557af3c8b1d88b4d52e2506.png
5 years ago, described the problem has not been solved in the Russian-speaking IT community, I thought. Maybe now the situation has changed?
Lenar.