The recent past: a study on the problems of test automation

Image from familyexpert.ru

Against the background of constant conversations about global informatization, the rapid development of the IT sphere and, in particular, software development technologies, there are reflections on the harmony of this development. If software development by leaps and bounds moves in the direction of DevOps, automation tools and continues to move, though not so active in the direction of Agile, then where does automated testing go?

Although the very fact of test automation in progressive CIS companies could be confirmed, but this confirmation turned out to be formal. As they say, yes and no. At least that was a few years ago.
')
There is an opinion that so far not all companies understand why they even need automated testing. And if we assume that this situation does not change against the background of general progress in software development, then there are doubts about the harmonious development of the automated testing direction. Perhaps this lag does not occur in all countries where software development is actively underway.

Of course, a lot depends on the directions in which this type of testing is applied. In the case of web development, the situation, in my opinion, is simpler: a few years ago, Selenium conquered everyone, who is alive and well today. Also, the autotests in the field of desktop development ARM, ABS with databases are relatively comfortable: I recall the simple NUnit tool, the obvious use of which was reduced to automatically running the same queries to the database after the changes made by the developer. Surely, someone else will remember some successful examples of introducing autotests with a happy ending, or at least with a happy start.


Image from qatestlab.com

Nevertheless, a huge number of attempts to introduce automated testing was reduced to the following result: “well, we dig deeper, we looked, we tested something in this way, but then we still recheck with our hands - you never know ...”. In my experience I have come across, unfortunately, with this very result. In many IT companies, automated testing remained in the experiment mode, and sometimes - just a “thing in itself”: the tester writes something, starts it, draws some conclusions from it, and the staff of other departments do not really notice the difference between the efficiency of autotests and manual testing.
And if we recall that software is developed not only by specialized firms, but also by non-core companies with IT departments, the picture became even more pessimistic, since such companies have, say, other priorities.

Of course, we are talking about the true values ​​of the teams, and not about the "title", which often arise in an attempt to give what is desired for real or under the influence of conjuncture. If testing automation is introduced only because it is in trend, then the effect of this will be appropriate: the authorities will pretend that they really need it, the testing team will pretend that it introduces "progressive" technologies and understands why it is needed, and the rest of the employees pretend to notice any changes for the better.

Worse, when there is no agreement on this issue in the company: someone really believes in progress and tries hard to introduce new technologies, and someone just imitates vigorous activity. In such cases, inevitable "battles" between employees, which, again, can lead to disruption of interaction and isolation of innovations, which remain in their "sandbox". Then the initiators of change get tired of breaking spears and calm down, waiting for better times.


Image from mishka.by

Such stories, of course, occurred not only with testing, but often it was perceived as a “brake” for developers. This is partly due to the situations when the management recruited testers with lower qualifications than the developers. The reason was not only the desire of management to save on salaries, but also an objective fact - for the most part, the universities of the CIS did not supply such specialists as testers to the market. And test automation requires quite high qualifications both in programming and testing, which further complicates the situation.

Thus, in the IT industry (at least within the CIS), there is an idea that there are even fewer qualified testers who can do test automation than there are skilled developers who can solve non-trivial tasks. If many low-skilled programmers did not reach a high level, since they could not find "themselves" (or simply because of their laziness), then testers in the CIS had fewer opportunities to get high qualifications. Speech not only about universities, but also about internships, corporate training, advanced training, advanced Russian-speaking communities of testers - all this was developed poorly a few years ago. Perhaps now the situation has changed for the better.

Whatever it was, you need to make a discount on the fact that testing as a separate direction began to develop later than programming. If we consider the emergence of such methodologies as TDD (Test Driven Development), BDD (Behavior Driven Development) as another attempt to “play” this lag, then for a long time they successfully existed in the form of beautiful ideas.


Image from blog.andolasoft.com

In the transition from the ideal world to the real, these concepts underwent changes, after which sometimes only the name remained. Of course, each team is individual, and an adjustment is necessary, but the question is where to draw the line between the adaptation of the concept and its degradation.

So we come to another lag - the lag of practice from theory. There is no guarantee that a seemingly appropriate methodology will be successfully implemented in a team without critical losses. These losses can manifest themselves not only in the fact that after the introduction of the original concept, little will remain, but also in the fact that the development of the company's products will seriously slow down. Numerous eyewitness accounts allow us to conclude that in order to implement the same TDD, it is necessary to literally reverse the development team’s presentation. It will have to spend a lot of time and nerves.

IT companies aiming for commercial success, but have not yet achieved it, cannot afford to slow down or stop at a pit stop in order to “change shoes”. Any change in process technology threatens their business. This takes us from the field of thinking about ideas, progress, theory and practice into the area of ​​the company's financial interests. The most important thing here is to work quickly, "without noise and dust, without departing from the cash register." From this point of view, it is important for a company to release a product in the shortest possible time, without obvious errors and with the minimum time to correct them. And if testers not only find not all errors, but also make them themselves when creating autotests, this is absurd and simply counterproductive.


Image from pp.vk.me

There are still new tools to automate various types of testing. In this sense, the direction is developing quite actively. However, many IT companies have not yet learned how to determine which tools they really need and which ones are redundant. They did not learn to assess the risks and time required for the introduction of innovations. The contradiction between the need for these tools and the difficulties with their implementation was not resolved. This was especially acutely felt several years ago.

Taking into account this situation, many companies treated test automation with utmost skepticism - down to complete denial. It is easier and cheaper to hire a couple of testers and spend a couple of additional development iterations. In part, there is the problem of confrontation between reformers and conservatives, but to a greater extent, in my opinion, it is still a matter of business survival.

The situation is different in those companies that can afford to allocate finance and other resources to research and experimental projects. Thus, testing new technologies, they pass on their experience to the community. By adopting successful strategies, other companies can go to “progress” after these pioneers.


Image from 13min.ru

Another category of "pioneers" - startups who have nothing to lose. They put together a powerful team and try something that "no one else has done before us." However, their projects are far from always sufficiently complex and large-scale to give special attention to special testing technologies. Therefore, once again, the decisive role and impetus to development are given to effective programming methods.

The question of general perception by employees of the “developer-programmer” and “tester” professions stands apart. Programmers are seen as creative individuals who create complex constructs from "nothing." They are such optimists who believe that their code works. And testers are those who destroy these illusions. In a sense, the professional duties of testers are to prevent the release of a product, to strive to prove that it is not good enough, it contains defects. If programmers worked on the principle “Every corrected error is the penultimate one”, their motivation would hardly be high.

Understanding that testers also benefit the company, give feedback, employees can still feel some sort of “sediment”. As a result, many subconsciously seek to distance themselves and do not want to once again help the testing department or contribute to its development. It is much “more pleasant” to help, to lead to the progress of people who believe that they can do the “impossible” by the deadline.

As they say, all professions are needed, all professions are important, but the human factor has not yet been leveled. Sometimes people can't abstract from purely psychological effects.

****

You can often hear that the past seems better to many than the present. “Nowadays ...”, they say. However, in the case of the development of test automation, it is hardly possible to argue according to the same scheme.


Image from gearmix.ru

5 years ago, the problems described were not yet resolved in the Russian-speaking IT community, as it seemed to me. Maybe now the situation has changed?