Developers do not like testers. Because they do not know how to use them
Tales about the quarrels of developers and testers were once true, but now there are almost no such conflicts. Calm collaborative work on the release of software, focusing on common goals, blah blah blah ...
But if you take a closer look, then under the appearance of productive collaboration there is often an absolute lack of understanding of the developers: “why do these testers are needed at all ??”. This misunderstanding is often mutual, and despite the seeming peacefulness, it leaves in joint work only the appearance of productivity.
1. There are few qualified testers.
This causes a quite expected negative attitude on the part of developers to the overwhelming majority of testers, who cannot be classified as “qualified.”
')
2. Testing is not always beneficial.
In general, it is difficult to evaluate the effectiveness of testing. Not every project boasts clear and measurable testing objectives. Therefore, testers often consider "the more bugs, the better." But the defects found are not good yet!
3. Testing often “distracts time” from development.
In order to penetrate deeply into the product, its architecture, the right testers inevitably get to the developers. Well, who loves it? :)
4. RMs often add fuel to the fire, considering “is there a bug? need to fix! "
But not everything needs to be fixed, and certainly not everything needs to be fixed now . Many developers who understand this, instead of arguing with RMs, prefer to hide defects.
5. Some developers are upset by the presence of errors.
Also, in principle, it is logical. I tried, tried, and here bam - mistakes! Consciously, we understand that this is correct and that in this way we will make the software better, but subconsciously unpleasant and it would be desirable to prevent repetition.
The result is a vicious circle. Because of the above five reasons (and perhaps not only them), the developers believe that they do not need testing. As a result, they do not support testing as it would cost. As a result, testers can not make their maximum, and this all leads to the repetition of all the same reasons.
In the standard scheme, when developers write-write, and then give testers a product for testing (a product!), There is a big ambush. For example, three months, half a year of development have passed before something similar to the user product has taken shape. This product is tested by testers. They bring up gazionny defects that are not clear how to localize (and the developers, having wondered at bad bugs, find out for a long time what and where is wrong). It is difficult to localize, difficult to fix, and the worst thing is that bugs appear and appear. Tomorrow release? And here you have 10 more critics! The cold war is starting :) Gone in the release? And all the bugs are and are.
And the opinion of the uselessness of testing is confirmed, and everything goes in a circle.
In fact, in the absence of clear testing objectives, the above described developments are not surprising. But it happens in a different way. Luckily :)
Any project wants to be released as quickly as possible, as successfully as possible and as qualitatively as possible. Of course, information about defects in the product helps to assess the status of the product, but to release faster and more successfully? Hardly.
And what helps?
1. Formalization of testing objectives.
And why is it necessary? What do you want to get as a result?
If you initially come up with the idea of ​​"well, there is no benefit from testing," then it will not be. And if you penetrate, scratch your turnip, brushstorm, draw mind-mepa, you can always think of how it should be right for you. But here the key to success is not just the appearance of a construct, but a really close cooperation of development and testing.
2. Testing from the first days of development.
This is the thing that almost any developer runs from. And in vain. The developer’s logic is usually the following: “I don’t have a finished product yet, I don’t have to test anything!”. But the bugs in the finished product are more difficult to find, later, longer, and fixing them is also more difficult! As soon as the first component appears with at least slightly stable interfaces, it should be tested!
What else does component testing provide?
3. Infosharing.
That is, sharing information. To the maximum. If someone somewhere once said that it is more efficient to test software, not knowing how it works - you are deceived. Testers do not know what affects the performance of a particular operation. UI options? No problem. But usually, in addition to them, there are plenty of factors that only developers know.
What to do?
SHARE AND DO NOT WAIT!
Hidden small defect today is the risk of big hemorrhoids tomorrow.
4. Develop a common approach to defects.
Of course, if the developer does not want to switch to some kind of bugfix today, he will do everything to hide the bugs. It sounds old-fashioned, now they don't do that? It is not true, do. This is a natural process :)
But, if the developers know that the bugs in the BTS (bug tracking system) are only information, but not always the signal for action, then there will be no frustration.
At the same time, for testing, sometimes fixing some bugs is very important. They are usually called Blockers (these are defects that may not be very critical from the user's point of view, but prevent testing of a substantial part of the functionality). Here they really need to fix, it is important, and preferably quickly.
5. Do not measure the result of parrots.
Sometimes the project management praises testers who found the critic a couple of hours before the release. Many bugs? Well done. Developers' management also often tries to measure, for example, KLOCs. But neither the amount of code, nor the number of bugs bring us closer to the release, sometimes - on the contrary! What really is a measure of the effectiveness of collaboration?
Only release. Timely and quality.
This means that defects, lines of code, medium criticality and other crap are formalism that helps the management to feel at the helm when looking at the graphics.
ps In one company where I worked, one day they introduced the assessment of developers by the number of written lines of code. The following month, the total was almost twice as large as the committed code. Just imagine its quality :)
Formalism focuses on tsiferki and removes from the result.
6. Provide testability of the product.
It is very important for us (we = the entire project, not just the testers!) To be able to quickly test our software. And for this sometimes you have to try. Fix blockers? Create additional interfaces for testing? To promise stabilization of interfaces and to fulfill your promise in every possible way?
It is important! Highly…
All project participants are interested in effective testing. It allows you to save development costs and bugfix, level project risks, improve product quality, save developers from unnecessary tasks ... In general, if the project has the right testing, then the total number of defects found is usually only lower!
BUT!
Testers are not always able to provide this most "correct" testing without the help, support and understanding from developers and RMs.
For this to happen, we need to communicate more. To find out who is waiting for what results from testing, what goals he sets. Who needs what to help, who does not like what is in the current process.
Having openly discussed such issues, we can make testing and the project as a whole much more efficient, and the main obstacle along the way is not customers, not tools, not technologies, but only a lack of understanding .
But if you take a closer look, then under the appearance of productive collaboration there is often an absolute lack of understanding of the developers: “why do these testers are needed at all ??”. This misunderstanding is often mutual, and despite the seeming peacefulness, it leaves in joint work only the appearance of productivity.
Why is this happening?
1. There are few qualified testers.
This causes a quite expected negative attitude on the part of developers to the overwhelming majority of testers, who cannot be classified as “qualified.”
')
2. Testing is not always beneficial.
In general, it is difficult to evaluate the effectiveness of testing. Not every project boasts clear and measurable testing objectives. Therefore, testers often consider "the more bugs, the better." But the defects found are not good yet!
3. Testing often “distracts time” from development.
In order to penetrate deeply into the product, its architecture, the right testers inevitably get to the developers. Well, who loves it? :)
4. RMs often add fuel to the fire, considering “is there a bug? need to fix! "
But not everything needs to be fixed, and certainly not everything needs to be fixed now . Many developers who understand this, instead of arguing with RMs, prefer to hide defects.
5. Some developers are upset by the presence of errors.
Also, in principle, it is logical. I tried, tried, and here bam - mistakes! Consciously, we understand that this is correct and that in this way we will make the software better, but subconsciously unpleasant and it would be desirable to prevent repetition.
What is the result?
The result is a vicious circle. Because of the above five reasons (and perhaps not only them), the developers believe that they do not need testing. As a result, they do not support testing as it would cost. As a result, testers can not make their maximum, and this all leads to the repetition of all the same reasons.
In the standard scheme, when developers write-write, and then give testers a product for testing (a product!), There is a big ambush. For example, three months, half a year of development have passed before something similar to the user product has taken shape. This product is tested by testers. They bring up gazionny defects that are not clear how to localize (and the developers, having wondered at bad bugs, find out for a long time what and where is wrong). It is difficult to localize, difficult to fix, and the worst thing is that bugs appear and appear. Tomorrow release? And here you have 10 more critics! The cold war is starting :) Gone in the release? And all the bugs are and are.
And the opinion of the uselessness of testing is confirmed, and everything goes in a circle.
What testing can give the development of such a tasty and healthy?
In fact, in the absence of clear testing objectives, the above described developments are not surprising. But it happens in a different way. Luckily :)
Any project wants to be released as quickly as possible, as successfully as possible and as qualitatively as possible. Of course, information about defects in the product helps to assess the status of the product, but to release faster and more successfully? Hardly.
And what helps?
1. Formalization of testing objectives.
And why is it necessary? What do you want to get as a result?
If you initially come up with the idea of ​​"well, there is no benefit from testing," then it will not be. And if you penetrate, scratch your turnip, brushstorm, draw mind-mepa, you can always think of how it should be right for you. But here the key to success is not just the appearance of a construct, but a really close cooperation of development and testing.
2. Testing from the first days of development.
This is the thing that almost any developer runs from. And in vain. The developer’s logic is usually the following: “I don’t have a finished product yet, I don’t have to test anything!”. But the bugs in the finished product are more difficult to find, later, longer, and fixing them is also more difficult! As soon as the first component appears with at least slightly stable interfaces, it should be tested!
What else does component testing provide?
- Simple bugfix. There is no need to locate problems for a long time, it is immediately clear where something is wrong.
- Finding hiding defects. In a large product with a complex architecture, it is always easy to hide the defects at the lower level: not to let in something in the UI, for example. But if the level below lives a bug that is not visible to the user, then there is no bug in the product! But, there is a risk that he will appear tomorrow :) What prevents to catch him today and level risks?
- Reduced software stabilization period . How usually looks like a graph of the convergence of defects on the project? The severity of defects caused from a certain point decreases, and their number grows. This is the period of "unlocking" functionality for testing. We do not open the window in the program? Blocker But we can not find 10 defects on this form. Did you fix it? But the input field does not work and ~ 9 more problems in the window. Critics Did you fix it? Found 10 small errors in the text field. Etc. Recursion Errors more and more, but they are less. In the meantime, few errors, but they are terrible, testers spit at the ceiling in anticipation of fixation. Half of the developers also spit at the ceiling, because there are no bugs on them, and we are at the “bugfix” stage. Component testing allows you to find a good half of them immediately. And that means - bug fixes when it is convenient, and evaluate your plans realistically.
3. Infosharing.
That is, sharing information. To the maximum. If someone somewhere once said that it is more efficient to test software, not knowing how it works - you are deceived. Testers do not know what affects the performance of a particular operation. UI options? No problem. But usually, in addition to them, there are plenty of factors that only developers know.
What to do?
SHARE AND DO NOT WAIT!
Hidden small defect today is the risk of big hemorrhoids tomorrow.
4. Develop a common approach to defects.
Of course, if the developer does not want to switch to some kind of bugfix today, he will do everything to hide the bugs. It sounds old-fashioned, now they don't do that? It is not true, do. This is a natural process :)
But, if the developers know that the bugs in the BTS (bug tracking system) are only information, but not always the signal for action, then there will be no frustration.
At the same time, for testing, sometimes fixing some bugs is very important. They are usually called Blockers (these are defects that may not be very critical from the user's point of view, but prevent testing of a substantial part of the functionality). Here they really need to fix, it is important, and preferably quickly.
5. Do not measure the result of parrots.
Sometimes the project management praises testers who found the critic a couple of hours before the release. Many bugs? Well done. Developers' management also often tries to measure, for example, KLOCs. But neither the amount of code, nor the number of bugs bring us closer to the release, sometimes - on the contrary! What really is a measure of the effectiveness of collaboration?
Only release. Timely and quality.
This means that defects, lines of code, medium criticality and other crap are formalism that helps the management to feel at the helm when looking at the graphics.
ps In one company where I worked, one day they introduced the assessment of developers by the number of written lines of code. The following month, the total was almost twice as large as the committed code. Just imagine its quality :)
Formalism focuses on tsiferki and removes from the result.
6. Provide testability of the product.
It is very important for us (we = the entire project, not just the testers!) To be able to quickly test our software. And for this sometimes you have to try. Fix blockers? Create additional interfaces for testing? To promise stabilization of interfaces and to fulfill your promise in every possible way?
It is important! Highly…
findings
All project participants are interested in effective testing. It allows you to save development costs and bugfix, level project risks, improve product quality, save developers from unnecessary tasks ... In general, if the project has the right testing, then the total number of defects found is usually only lower!
BUT!
Testers are not always able to provide this most "correct" testing without the help, support and understanding from developers and RMs.
For this to happen, we need to communicate more. To find out who is waiting for what results from testing, what goals he sets. Who needs what to help, who does not like what is in the current process.
Having openly discussed such issues, we can make testing and the project as a whole much more efficient, and the main obstacle along the way is not customers, not tools, not technologies, but only a lack of understanding .
Source: https://habr.com/ru/post/114836/
All Articles