Autotest - lordly business
Why do developers write autotests? With the same success they can be made to lay tiles or keep accounts. Not lordly this thing! Or, after all, lordly?
')
Note: the article under autotests means not unit-tests, but automated functional tests that are performed on a fully deployed product in an environment as close as possible to the combat one.
There are many myths and nonsense in software development. Consider two of them.
It so happened that testers in the industry earn on average less than developers. This is apparently due to the fact that there is a perception that the role of testers can hire students for three rubles a bundle, show them where to “poke” - and that's all, the monkey testers team is ready. This is nonsense, of course. A good tester is essentially an experienced pedal hacker with intelligent intelligence and should be expensive, but for some reason few people understand this.
The second nonsense is the attitude to autotests. It is believed that the development of autotests is a dull tedious job that can and should be entrusted to anyone who agrees to do it, because the user and the customer for autotests do not care, he needs a product.
If we combine these two stupidities, then we get a situation where autotests are given to the testing team, as a result we don’t have a testing team, as it is busy developing autotests, or autotests, as it turns out that:
The first reason for the problems described above is that a satisfactory automated test system is often more complex than the product being tested and is itself a software product. The developers of automated test systems require high qualification in the field of software development, and there are not many such people in the testing team. The result is tests that are very expensive to maintain and develop.
The second reason stems from the fact that the testing team does not own the product code. The code is owned by the developers and only they can make corrections to it.
From the practice of using unit tests, it is known that their development is most effective when the author of the tested code deals with it. In this case, the code, as a rule, turns out to be more suitable for testing, and as a result, the tests are easier and more reliable.
Exactly the same situation takes place in the development of functional autotests. When developers write the product code, and testers test this code, the complexity and quality (sustainability, execution speed, fragility, etc.) of such tests turn out to be worse than if both teams were developed by one team. This is due to the fact that the developer has the opportunity to tweak the code slightly so that it is more convenient for him to write an autotest for this code. Theoretically, an engineer from the testing team can also ask the product development team to modify the code. But in practice, this does not always happen, as it is often easier for a tester to leave a crutch in a test (for example, sleep), than to ask a team of developers who are currently busy with something important, to wait until they realize that it is necessary, then get what he asked for and so on in a circle. As a result, over time, the tests become overgrown with crutches, become unsupported and turn into that very case without a handle, which is pitiful and hard to throw away.
Thus, the most reliable and easily supported tests are obtained when they are made by a team of product developers. But this option is also not without flaws. These shortcomings are well known and thanks to them testers are generally available. Everything ultimately boils down to the fact that testers are better at finding errors.
Therefore, some intermediate option is optimal when autotests are written by both developers and testers. With such a combined approach, it is possible to combine the strengths of those and others. Developers lay the competent architecture AutoTests, adapt the product and provide coverage of product code tests. Testers, for their part, provide coverage for test cases, using autotest of developers as a base.
The development of autotests is an integral part of the overall product development process. When planning an iteration for each user story, we will definitely put in time to prepare autotests for it. The complexity of autotests is usually 10-20% of the complexity of history, but the time spent then repeatedly pays off.
When introducing such an approach to the development of autotests there may be problems with the motivation of developers, but to overcome these problems is not difficult. It is necessary to make the auto test run (at least, some of them) become an internal affair of the team of programmers. This means that testers receive only those assemblies that have fully passed automated tests for testing. At the same time, there are no bugs on the broken functionality that was discovered by autotests, because testers do not know anything about this shame. If a programmer checks code that breaks auto-tests, then he either immediately rolls back the check, or repairs it quickly if there is some trifle.
After that, an amazing thing happens - programmers suddenly notice that autotests save them a lot of time:
Then it remains only to monitor and maintain regular classes AutoTests, so again not to fall on the couch and not swim fat.
')
Note: the article under autotests means not unit-tests, but automated functional tests that are performed on a fully deployed product in an environment as close as possible to the combat one.
There are many myths and nonsense in software development. Consider two of them.
It so happened that testers in the industry earn on average less than developers. This is apparently due to the fact that there is a perception that the role of testers can hire students for three rubles a bundle, show them where to “poke” - and that's all, the monkey testers team is ready. This is nonsense, of course. A good tester is essentially an experienced pedal hacker with intelligent intelligence and should be expensive, but for some reason few people understand this.
The second nonsense is the attitude to autotests. It is believed that the development of autotests is a dull tedious job that can and should be entrusted to anyone who agrees to do it, because the user and the customer for autotests do not care, he needs a product.
If we combine these two stupidities, then we get a situation where autotests are given to the testing team, as a result we don’t have a testing team, as it is busy developing autotests, or autotests, as it turns out that:
- Autotest will be extremely expensive to develop.
- A large number of false positives. Rarely, when a full autotest run is completed successfully, as a result, no one believes a broken attestation.
- The time-consuming process of analyzing the results of the autotest run due to the large number of false positives and difficulties with diagnostics.
- Very high fragility. Tests constantly break even after minor changes in the product. Because of this, they need to constantly “finish”.
- In the end, autotests are scored and try to forget this shame.
The first reason for the problems described above is that a satisfactory automated test system is often more complex than the product being tested and is itself a software product. The developers of automated test systems require high qualification in the field of software development, and there are not many such people in the testing team. The result is tests that are very expensive to maintain and develop.
The second reason stems from the fact that the testing team does not own the product code. The code is owned by the developers and only they can make corrections to it.
From the practice of using unit tests, it is known that their development is most effective when the author of the tested code deals with it. In this case, the code, as a rule, turns out to be more suitable for testing, and as a result, the tests are easier and more reliable.
Exactly the same situation takes place in the development of functional autotests. When developers write the product code, and testers test this code, the complexity and quality (sustainability, execution speed, fragility, etc.) of such tests turn out to be worse than if both teams were developed by one team. This is due to the fact that the developer has the opportunity to tweak the code slightly so that it is more convenient for him to write an autotest for this code. Theoretically, an engineer from the testing team can also ask the product development team to modify the code. But in practice, this does not always happen, as it is often easier for a tester to leave a crutch in a test (for example, sleep), than to ask a team of developers who are currently busy with something important, to wait until they realize that it is necessary, then get what he asked for and so on in a circle. As a result, over time, the tests become overgrown with crutches, become unsupported and turn into that very case without a handle, which is pitiful and hard to throw away.
Thus, the most reliable and easily supported tests are obtained when they are made by a team of product developers. But this option is also not without flaws. These shortcomings are well known and thanks to them testers are generally available. Everything ultimately boils down to the fact that testers are better at finding errors.
Therefore, some intermediate option is optimal when autotests are written by both developers and testers. With such a combined approach, it is possible to combine the strengths of those and others. Developers lay the competent architecture AutoTests, adapt the product and provide coverage of product code tests. Testers, for their part, provide coverage for test cases, using autotest of developers as a base.
The development of autotests is an integral part of the overall product development process. When planning an iteration for each user story, we will definitely put in time to prepare autotests for it. The complexity of autotests is usually 10-20% of the complexity of history, but the time spent then repeatedly pays off.
When introducing such an approach to the development of autotests there may be problems with the motivation of developers, but to overcome these problems is not difficult. It is necessary to make the auto test run (at least, some of them) become an internal affair of the team of programmers. This means that testers receive only those assemblies that have fully passed automated tests for testing. At the same time, there are no bugs on the broken functionality that was discovered by autotests, because testers do not know anything about this shame. If a programmer checks code that breaks auto-tests, then he either immediately rolls back the check, or repairs it quickly if there is some trifle.
After that, an amazing thing happens - programmers suddenly notice that autotests save them a lot of time:
- When you make another change to the product code, the developer does not spend his time checking that he has not broken anything. The developer simply puts the code in the repository, and the check is done by automation.
- Working code is much easier to modify than non-working. Autotest confirms the performance of the product before the programmer starts the next task, which gives him a firm footing.
- It is known that the earlier the error is detected, the easier it is to localize and fix it. Auto tests in many cases help to reduce the time of error detection to a minimum, due to which the error is corrected without delay.
- Autotesting allows you to effectively refactor code, as the programmer can automatically verify the correctness of the refactoring. Due to this, refactoring ceases to be a walk in a minefield and becomes a routine working procedure.
Then it remains only to monitor and maintain regular classes AutoTests, so again not to fall on the couch and not swim fat.
Source: https://habr.com/ru/post/238353/
All Articles