Nowadays, under the semblance of productive cooperation it often hides the absolute lack of understanding between developers and testers.
Why is this happening?
1. There is a lack of qualified testers.
This is quite expected negative attitude on the side of developers to the vast majority of testers, which cannot be attributed to a number of “qualified.”
2. 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 “more software bugs is better.” But the found defects – it is not useful yet!
3. 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?
4. PM often pours oil into fire, believing “Is there a bug? It 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 PM prefer to hide defects.
5. Some developers are frustrated by the presence of errors.
Also, in principle, it is logical. I tried and tried, but here bam – an 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 these five reasons (and perhaps not only them), developers believe that they do not need testing. As a result, they do not support testing. As a result, testers cannot do their maximum and it all leads to a repetition of the same reasons.
What may help?
1. Formalizing testing purposes.
Why is it necessary? What I want to get as a result?
Here the key to success is not just the appearance of structural elements, but really close cooperation development and testing.
2. Testing since the early days of development.
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?
• Simple bug fix
• Finding the hiding defects
• Reducing the period of stabilization
3. Infosharing.
That is the division of information. To the maximum. Hid a small defect today – the risk of large troubles tomorrow.
4. Develop a common approach to defects.
Of course, if the developer does not want today to switch to some kind of bug fix, then he will do everything possible to hide bugs. This is a natural process.
5. Not to measure the result with parrots.
Sometimes the project management praises testers who found the critical couple of hours before the release. Are there a lot of bugs? Well done. But no amount of code, no the number of bugs is not bringing us closer to release, sometimes – on the contrary. Formalism focuses on numerals and removes from the result.
6. Ensuring testability of the product.
We (we = the whole project, not just the testers!) need to be able to quickly test our software. And for that sometimes have to put in one’s best licks.
Conclusions
All parties of the project are interested of the effective test. It allows you to save costs on the development and bug fixes, level project risks, improve product quality, save developers from unnecessary problems … In general, if the project has proper testing, then the total number of defects that are usually just below!
BUT!
Software testers are not always able to ensure the most “correct” test without help, support and understanding of the part of developers and PM.
For this to happen, we need to communicate more.
To openly discuss the 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.