Non-reproducible bugs – What does that mean?
From Testing team standpoint: We found this Bug once while testing the software. Now we are not able to reproduce it.
From Development team standpoint: Please reproduce it else we will mark this bug as invalid.
These are the two aspects against a bug which the tester’s find only once while testing the software but not able to reproduce it. In my opinion, non-reproducible bugs should be renamed as "hard-to-reproduce" bugs. This term will justify some existence of these kinds of Bugs.
All the Bug Tracking Tools have some options to handle these kinds of issues but normally I have seen a same way to tackle these kinds of bugs by the development team. “Please reproduce it. Then we will consider this as a Bug and work on it”.
In one of my previous organization, I found a bug which I was able to reproduce it my setup but the developer was not able to reproduce it in his setup. I also tried my best to recreate the scenario in the development’s setup but all efforts failed. At that time, one of my development manager surprisingly said that the Test team should not file this bug because the development team is not able to reproduce this bug in their setup. It was the statement that truly captured his attitude towards Testing. But I still logged that Bug and it has been marked as “rejected” by the development team. After two months, same problem has reported by the customer and then you can imagine whatever happened after that was not good for that development manager. Every muscle in his neck and face was tensed when he was questioned by the management.
In my first organization where I worked and progressed as a Test team member, I fired 75% of the total bugs logged in the Bug Tracking System against specific software that I tested. Some of those issues are non-reproducible but 65% of those bugs have resolved by the development team. Fortunately, the development team understood the term in a better way.
I have seen in my carrier that a non-reproducible bug remains as it is in the Bug Tracking System as decorative as Chinese lamps. And after some time, that bug has been rejected by the management without even asking from the Test team.
There should be some rule (or process) according to the organization perspective as to how to handle the “Non-reproducible” (or better say “Hard-to-Reproduce”) bugs. Good people do not need rules to tell them to act responsibly, while bad people will find a way around the rules. If we ignore these bugs, we have to pay off. Ignorance can lead to unawareness that the light you see the end of the tunnel is actually an oncoming train.
-- Sanat Sharma (सनत शर्मा)Quality and Testing Expert
3 comments:
Not reproducible bugs are "Hard-to-reproduce" bugs. Nice thought but I think not acceptable from development point of view.
- Sandeep D.
Oi, achei seu blog pelo google está bem interessante gostei desse post. Gostaria de falar sobre o CresceNet. O CresceNet é um provedor de internet discada que remunera seus usuários pelo tempo conectado. Exatamente isso que você leu, estão pagando para você conectar. O provedor paga 20 centavos por hora de conexão discada com ligação local para mais de 2100 cidades do Brasil. O CresceNet tem um acelerador de conexão, que deixa sua conexão até 10 vezes mais rápida. Quem utiliza banda larga pode lucrar também, basta se cadastrar no CresceNet e quando for dormir conectar por discada, é possível pagar a ADSL só com o dinheiro da discada. Nos horários de minuto único o gasto com telefone é mínimo e a remuneração do CresceNet generosa. Se você quiser linkar o Cresce.Net(www.provedorcrescenet.com) no seu blog eu ficaria agradecido, até mais e sucesso. If is possible add the CresceNet(www.provedorcrescenet.com) in your blogroll, I thank. Good bye friend.
Its a common but frequently ignored problem. Non-reproducible bugs are mostly rejected by Development Team and such bugs may become problem in future.
'Non-Reproducible bugs can be handled by -
1. Mentioning the non-reproducible defects in Release Description Document.
2. As mentioned in the blog, assign a suitable label to such bugs,like 'hard to reproduce' bugs, instead of rejecting it.
This would not create embarassing situations for the Testing as well as Development Team when the same reported by customer.
Also, if the defect is rejected by development team, testers may miss to reproduce the defect on current release of the application. Since it is not recorded anywhere tester may not remember the bug and thus miss to reproduce the bug.
Post a Comment