March 3, 2011 at 15:51Developers 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 you can hardly meet such conflicts. Calm collaboration on the release of software, focus on common goals, blah blah blah ...
But if you look closely, then under the guise of productive cooperation is often hiding the absolute misunderstanding of the developers: "Why are these testers at all ??". This misunderstanding is often mutual, and despite the apparent peacefulness, leaves in the joint work only the appearance of productivity.
1. There are few qualified testers.
This causes the expected negative attitude on the part of developers towards the overwhelming majority of testers, who cannot be classified as “qualified”.
2. Testing is far from always beneficial.
In general, it is difficult to evaluate the effectiveness of testing. Not every project can boast of understandable and measurable testing objectives. Therefore, testers often consider "the more bugs, the better." But found defects are not good!
3. Testing often "takes time" from development.
In order to delve deeply into the product, its architecture, the right testers inevitably dig into the developers. Well, who loves this? :)
4. PM’s often add fuel to the fire, considering “is there a bug? must be fixed! ”
But not everything needs to be fixed, and especially not everything needs to be fixed now . Many developers who understand this, instead of arguing with RM, prefer to hide defects.
5. Some developers are upset about having bugs.
It is also, in principle, logical. I tried, I tried, but bam - mistakes! We consciously understand that this is correct and that this way we will make software better, but it is subconsciously unpleasant and I want to prevent a repetition.
The result is a vicious circle. Because of the above five reasons (and possibly not only them), developers believe that they do not need testing. As a result, they do not support testing as it should. As a result, testers cannot make their maximum, and this all leads to a repetition of all the same reasons.
In the standard scheme, when developers write and write, and then give testers a product for testing (product!), There is a big ambush. For example, three months, half a year of development took place before something took shape that looked like a custom product. This product is tested by testers. They make gas defects that are not clear how to localize (and developers, mating on bad bugs, find out for a long time what and where is wrong). It’s difficult to localize, it’s difficult to fix, and what’s the worst is that bugs appear and appear. Tomorrow release? And here you have 10 more critics! The cold war begins :) Gone on release? And bugs are all there and are.
And the opinion in the uselessness of testing is confirmed, and everything goes in a circle.
In fact, in the absence of clear testing objectives, there is nothing surprising in the above development of events. But it happens differently. Fortunately :)
Any project wants to be released as quickly as possible, as successful as possible and as high quality as possible. Of course, information about defects in a product helps assess the status of a product, but is it faster and more successful to launch? Unlikely.
What helps?
1. Formalization of testing goals.
Why is it necessary? What do you want to get as a result?
If you initially come up with the idea “well, there is no benefit from testing”, then it will not be. And if you delve into, scratch your turnips, brainstorm, and draw mind maps, you can always figure out how it should be most right for you. But here the key to success is not just the appearance of a construct, but a really tight collaboration of development and testing.
2. Testing from the first days of development.
This is the thing that almost any developer runs from. But in vain. The logic of the developer is usually the following: "I do not have a finished product yet, no need to test anything!". But 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 with at least slightly stable interfaces appears, it must be tested!
What else does component testing give?
3. Infosharing.
That is, sharing information. To the maximum. If someone somewhere once said that it is more efficient to test software without knowing how it works, you were deceived. Testers DO NOT know what affects the execution of an operation. UI options? No problem. But usually, in addition to them, there are still a lot of factors that only developers know.
What to do?
SHARE AND DO NOT BE GREED!
A hidden small defect today is the risk of a big hemorrhoids tomorrow.
4. Develop a common approach to defects.
Of course, if the developer does not want to switch to some kind of bug fix today, then he will do everything to hide the bugs. Sounds old fashioned, don't they do it now? Not true, they do. This is a natural process :)
But if the developers know that bugs in BTS (bug tracking system) are just information, but not always a signal to action, then their presence will not be upset.
At the same time, for testing sometimes the fix of some bugs is very important. They are called Blockers (these are defects that may not be very critical from the point of view of the user, but prevent the testing of any significant part of the functionality). Here they really need to be fixed, important, and preferably quickly.
5. Do not measure the result of parrots.
Sometimes the project management praises the testers who found the critic a couple of hours before the release. A lot of bugs? Well done. The developers, too, often try to measure the leadership, for example, with KLOCs. But neither the amount of code, nor the number of bugs brings us closer to the release, sometimes - vice versa! What really is an indicator of teamwork?
Only release. Timely and high quality.
And this means that defects, lines of code, average criticality and other crap are formalisms that help management to feel at the helm, looking at the charts.
ps In one company where I worked, one fine day they introduced an assessment of developers by the number of written lines of code. The following month, there were a total of almost two times more of the committed code. Just imagine its quality :)
Formalism focuses on numbers and removes from the result.
6. Ensuring product testability.
It is very important for us (we = the whole project, not just testers!) To be able to quickly test our software. And for this, sometimes you have to try. Fix blockers? Create additional interfaces for testing? Promise stabilization of interfaces and keep your promise in every way?
It is important! Highly…
All project participants are interested in effective testing. It allows you to save development costs and bug fixes, level project risks, improve product quality, save developers from unnecessary tasks ... In general, if the project is tested correctly, the total number of defects found is usually only lower!
BUT!
Testers are far from always able to provide this most “correct” testing without the help, support and understanding of developers and RMs.
For this to happen, we need to communicate more. Find out who expects what results from testing, what goals it sets. Who needs 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 effective, and the main obstacle to this is not customers, not tools, not technologies, but just misunderstanding .
But if you look closely, then under the guise of productive cooperation is often hiding the absolute misunderstanding of the developers: "Why are these testers at all ??". This misunderstanding is often mutual, and despite the apparent peacefulness, leaves in the joint work only the appearance of productivity.
Why is this happening?
1. There are few qualified testers.
This causes the expected negative attitude on the part of developers towards the overwhelming majority of testers, who cannot be classified as “qualified”.
2. Testing is far from always beneficial.
In general, it is difficult to evaluate the effectiveness of testing. Not every project can boast of understandable and measurable testing objectives. Therefore, testers often consider "the more bugs, the better." But found defects are not good!
3. Testing often "takes time" from development.
In order to delve deeply into the product, its architecture, the right testers inevitably dig into the developers. Well, who loves this? :)
4. PM’s often add fuel to the fire, considering “is there a bug? must be fixed! ”
But not everything needs to be fixed, and especially not everything needs to be fixed now . Many developers who understand this, instead of arguing with RM, prefer to hide defects.
5. Some developers are upset about having bugs.
It is also, in principle, logical. I tried, I tried, but bam - mistakes! We consciously understand that this is correct and that this way we will make software better, but it is subconsciously unpleasant and I want to prevent a repetition.
What is the result?
The result is a vicious circle. Because of the above five reasons (and possibly not only them), developers believe that they do not need testing. As a result, they do not support testing as it should. As a result, testers cannot make their maximum, and this all leads to a repetition of all the same reasons.
In the standard scheme, when developers write and write, and then give testers a product for testing (product!), There is a big ambush. For example, three months, half a year of development took place before something took shape that looked like a custom product. This product is tested by testers. They make gas defects that are not clear how to localize (and developers, mating on bad bugs, find out for a long time what and where is wrong). It’s difficult to localize, it’s difficult to fix, and what’s the worst is that bugs appear and appear. Tomorrow release? And here you have 10 more critics! The cold war begins :) Gone on release? And bugs are all there and are.
And the opinion in 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, there is nothing surprising in the above development of events. But it happens differently. Fortunately :)
Any project wants to be released as quickly as possible, as successful as possible and as high quality as possible. Of course, information about defects in a product helps assess the status of a product, but is it faster and more successful to launch? Unlikely.
What helps?
1. Formalization of testing goals.
Why is it necessary? What do you want to get as a result?
If you initially come up with the idea “well, there is no benefit from testing”, then it will not be. And if you delve into, scratch your turnips, brainstorm, and draw mind maps, you can always figure out how it should be most right for you. But here the key to success is not just the appearance of a construct, but a really tight collaboration of development and testing.
2. Testing from the first days of development.
This is the thing that almost any developer runs from. But in vain. The logic of the developer is usually the following: "I do not have a finished product yet, no need to test anything!". But 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 with at least slightly stable interfaces appears, it must be tested!
What else does component testing give?
- Simple bugfix. It is not necessary to localize problems for a long time, you can immediately see where something is wrong.
- Finding hiding defects. In a large product with complex architecture, defects at the lower level are always easy to hide: do not let something enter in the UI, for example. But if a 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 it will appear tomorrow :) What prevents to catch it today and mitigate risks?
- Reduced software stabilization period. What is usually a graph of defects convergence on a project? The criticality of induced defects decreases from a certain point, and their number grows. This is the period of "unlocking" the functionality for testing. Our window does not open in the program? Blocker. But we cannot find 10 defects on this form. Have you fixed it? But the input field does not work and ~ 9 more problems in the window. The critics. Have you fixed it? Found 10 small errors in the text box. Etc. Recursion. There are more errors, but they are less. In the meantime, there are few errors, but they are scary, testers spit on the ceiling in anticipation of a fix. Half of the developers also spit on 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. So - bug fix, when 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 without knowing how it works, you were deceived. Testers DO NOT know what affects the execution of an operation. UI options? No problem. But usually, in addition to them, there are still a lot of factors that only developers know.
What to do?
SHARE AND DO NOT BE GREED!
A hidden small defect today is the risk of a big hemorrhoids tomorrow.
4. Develop a common approach to defects.
Of course, if the developer does not want to switch to some kind of bug fix today, then he will do everything to hide the bugs. Sounds old fashioned, don't they do it now? Not true, they do. This is a natural process :)
But if the developers know that bugs in BTS (bug tracking system) are just information, but not always a signal to action, then their presence will not be upset.
At the same time, for testing sometimes the fix of some bugs is very important. They are called Blockers (these are defects that may not be very critical from the point of view of the user, but prevent the testing of any significant part of the functionality). Here they really need to be fixed, important, and preferably quickly.
5. Do not measure the result of parrots.
Sometimes the project management praises the testers who found the critic a couple of hours before the release. A lot of bugs? Well done. The developers, too, often try to measure the leadership, for example, with KLOCs. But neither the amount of code, nor the number of bugs brings us closer to the release, sometimes - vice versa! What really is an indicator of teamwork?
Only release. Timely and high quality.
And this means that defects, lines of code, average criticality and other crap are formalisms that help management to feel at the helm, looking at the charts.
ps In one company where I worked, one fine day they introduced an assessment of developers by the number of written lines of code. The following month, there were a total of almost two times more of the committed code. Just imagine its quality :)
Formalism focuses on numbers and removes from the result.
6. Ensuring product testability.
It is very important for us (we = the whole project, not just testers!) To be able to quickly test our software. And for this, sometimes you have to try. Fix blockers? Create additional interfaces for testing? Promise stabilization of interfaces and keep your promise in every way?
It is important! Highly…
conclusions
All project participants are interested in effective testing. It allows you to save development costs and bug fixes, level project risks, improve product quality, save developers from unnecessary tasks ... In general, if the project is tested correctly, the total number of defects found is usually only lower!
BUT!
Testers are far from always able to provide this most “correct” testing without the help, support and understanding of developers and RMs.
For this to happen, we need to communicate more. Find out who expects what results from testing, what goals it sets. Who needs 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 effective, and the main obstacle to this is not customers, not tools, not technologies, but just misunderstanding .