- Oct 15,2010
- In: Articles
Developers do not like the testers. Because I do not know how to use them
Tales about a quarrel developers and testers were once true, but now such conflicts almost can not be found. Quiet working together on the release of software, a focus on common goals, blah blah blah …
But if you look closely, you behind the facade of a productive cooperation often hides the absolute lack of understanding of the developers: "why these testers do we need?". This misunderstanding is often mutual, and despite the seeming peace-loving, left to work together a semblance of productivity.
Why is this happening?
- Qualified testers little.
This is quite expected negative attitude on the part of developers to the vast majority of testers, which can not be attributed to a number of "qualified." - Testing is not always beneficial.
Generally, to evaluate the effectiveness of testing is difficult. Not every project can boast of clear and measurable objectives of testing. So, testers are often considered "the more bugs, the better." But the found defects – that’s not good! - Testing is often "distracted time" for development.
To penetrate deeply into the product, its architecture, the right testers will inevitably dig to developers. Well, who likes it?
- RM’y often pour oil into fire, believing "there is a bug? should be fixed! "
But not everything has to be fixed, and certainly not everything should be fixed now. Many developers who understand this, instead of disputes with RM’ami prefer to hide defects. - Some developers are frustrated by the presence of errors.
Also, in principle, it is logical. I tried and tried, but here bam – error! Consciously, we understand that this is correct, and that is how we make software better, but subconsciously uncomfortable and want to prevent a recurrence.
What happens in the end?
The result is a vicious circle. Because of the above five reasons (and perhaps not only them), developers feel that they nafik testing is not necessary. As a result, they do not support testing as would have cost. As a result, testers can not do your maximum, and it all leads to a repetition of the same reasons.
In the standard scheme, where developers write, write, and then give the product testers for testing (produkt!), there is a great ambush. For example, three months, six months of development have been before taken shape something like a custom product. This product is tested testers. Gazionny give birth defect that is not clear how to localize (and developers matyugayas the bad bugs, for a long time figuring out where and what is not). Localize difficult, fixed hard, and worst of all – there are bugs and there. Release tomorrow? And here’s another 10 kritikalov! Cold War begins:) They’ve gone into the release? And all the bugs are and are.
And the opinion of the uselessness of testing is confirmed, and everything goes in circles.
That test to develop such a tasty and healthy?
On actual fact, in the absence of clear testing purposes, in the above scenario is not surprising. But it also happens the other way. Fortunately:)
Any project wants unreleased as quickly as possible, as can be successfully and how to perform better. Of course, information about defects in the product helps to assess the status of the product, but unreleased quickly and successfully? Hardly.
What helps?
- Formalizing testing purposes.
And why is it necessary? What I want to get a result?
If initially approached with the idea of ??"well, from tasting good no," then it will not. And if you penetrate, scratch turnip pobreynshtormit, draw Mind-mepy, you can always think of how it should be the right thing from you. But this success – not just the appearance of structural elements, but really close cooperation development and testing. - Testing since the early days of development.
This is the thing, which runs from almost any developer. But in vain. The logic of the developer usually is: "I do not have a finished product, do not need to test!". But bugs in the finished product is more difficult to later, longer, and fixed them too hard! As soon as the first component with at least a little bit of a stable interface, it must be tested!
What else makes component testing? A simple bug fixes. No need for a long time to localize the problem is immediately obvious where that is not true.
Finding the hiding of defects. In a large product with a complex architecture of the defects on the lower level is always easy to hide: not to enter anything in the UI, for example. But if the level of living below the bug is not visible to the user – hence, the product is not a bug! But there is a risk that it will appear tomorrow:) What prevents his word today and level the risks?
Reducing the period of stabilization. As usual, the schedule looks like the convergence of defects on the project? Severity zavodimyh defects from a certain point decreases, and their number is growing. This period of "unlocking" the functional testing. We do not have a window in the program? Blocker. But we can not find 10 defects on this form. Repaired? But not working the input box and a "9 problems in the window. Kritikaly. Repaired? Found 10 small errors in the text box. Etc. Recursion. Errors more, but they are smaller. And while few mistakes, but they are terrible, testers spit at the ceiling in anticipation of fixation. Half of the developers also spit at the ceiling, because they do not have bugs, and we are at the stage of "bug fixes". Component testing allows a good half of them is right. And that means – bugfixes, when convenient, and realistically assess their plans. - Infosharing.
That is, the division of information. To the maximum. If someone somewhere once said that an effective testing software, not knowing how it works – you have been cheated. Testers do not know what affect the execution of an operation. Options UI? No problem. But usually, in addition to these, there are plenty of factors that is known only by the developers.
What should I do?
Share and do not be greedy!
Hid a small defect in today – the risk of large piles tomorrow. - Develop a common approach to defects.
Of course, if the developer does not want today to switch to some kind of bugfix, then he will do everything possible to hide bugs. It sounds old-fashioned now, so do not? True, they do. This is a natural process:)
But, if developers know that the bugs in the BTS (bug tracking system) – it’s just information, but not always a call to action, then upset their presence will not be.
In this case, testing is sometimes fix some bugs are very important. They are usually called Blocker’ami (a defect that can not be very critical from the standpoint of the user, but prepyatstsvuyut testing a significant part of the functional). That is their truth must be fixed, it is important and desirable fast. - Not to measure the result of parrots.
Sometimes the project management praises testers who found the Critical couple of hours before the release. A lot of bugs? Well done. Developer guide too often tries to compete, for example, KLOC’ami. But no amount of code, nor the number of bugs is not bringing us closer to release, sometimes – on the contrary! What really is an indicator of the effectiveness of working together?
Once the release. Timely and quality.
This means that defects, lines of code, the average criticality and other Labuda – this formalism, which helps guide feel at the helm, looking at the charts.
p.s. In one company where I worked, one day entered the developers estimate the number of written lines of code. The following month total was nearly twice as much zakommichennogo code. Just imagine the quality:)
Formalism focuses on Tsiferki and removes from the result. - Ensuring testability of the product.
We (we = the whole project, not just the testers!) Is very important to be able to quickly test our software. And for that sometimes have to try. Fixed blockers? Create additional interfaces for testing? Promise to stabilize the interfaces and otherwise fulfill its promise?
This is important! Very …
Conclusions
The effective test the interest of all parties to the project. It allows you to save development costs and bug fixes, level project risks, improve product quality, save developers from unnecessary problems … In general, if the project proper testing, then the total number of defects that are usually just below!
BUT!
Testers are not always able to ensure this is the most "correct" test without help, support and understanding on the part of developers and RM’ov.
For this to happen, we need to communicate more. Know who are waiting for results from testing, which was targeting. Who you need to help someone that does not like the current process.
To openly discuss such issues, we can do testing and the whole project more efficiently, and the main obstacle on this way – not customers, not tools, not technology, but only a misunderstanding.