- This topic has 9 replies, 10 voices, and was last updated 7 years, 6 months ago by
.
-
Posts
-
How rejected bugs are being handled in your organization.
For example, If a developer rejects a bug with resolution as “Won’t fix” etc. how does your test / project managers handle them:- Rejected bugs are assigned to Project Manager for further review.
- Developers have the last say
- Any suggestion ???
In one of my previous organisations, the developers could not mark a defect as won’t fix. They had to assign it to the dev team manager with appropriate comments who would then decide whether the defect should be marked as Won’t fix. Because of this process the number of such occurrences would be pretty low.
It really really annoys me that the developer can say “won’t fix” and it’s never challenged by tester or product owner. It sounds to me that the developer has more to say than any other person. That really bugs me!
My preferred approach is to have the person that created the defect close the defect, both when it’s solved and when it’s “no issue”. //The fixer, to me, does not have the option to close it [1] alone. Nor can he fix the bug without letting the tester know. In the end the tester calls whether it is resolved or acceptable given the updated information//
It really depends on your defect flow and view on closure: //Setting [Rejected] back to “detected by” will aid that the tester reflects on the reasons. The reasons are then tested (in the brain). Sometimes it’s a “my bad” but quite often also the tester finds that issue is simply not “rejected” with more data and examples.//
https://www.ministryoftesting.com/2014/11/closure/Haven’t experienced it that much. We are communicating most of the time on non-reproducible issues or feature requests or just wrong tester understanding of the information. I think I close myself most of the issues like this after I gather enough information.
We agree to close issues as won’t fix, can’t reproduce, close without additional status.
If the dev you are working with does this often to you, most probably the issue is somewhere else:
1. You are not communicating properply. Can be because you don’t like each-other, or don’t trust one another. Can be because you or him are too lazy to wait for when you meet or just go to one’s desk or skype him about the issue. Can be because you haven’t earned his trust yet so he doesn’t care much about you. And other similar communication linked issues.
2. You are misunderstanding the relation between requirements, specifications and built code. Maybe he’s interpreting it in a way that you are not. Maybe you need to do more research and information gathering before creating issues? Maybe issues are just in your head. Or maybe issues can be fixed after a conversation with the dev, without a ticket.
3. You have a very basic understanding of the product. Maybe it’s just 1 and 0 for you. Maybe you’re testing without much knowledge of the product – just use the specifications and build pre-defined steps test-cases. Try to learn more about the product, test more, reach a very high level of product knowledge, outside-inside-lateral..
4. The tickets you’re creating seem more like features than bugs to him. In that case take it first with the Product Owner/BA or someone leading the project development. Confirm with them..let the feature become a task for him from that person.
I’ll start on a slight tangent and something that frustrates me a little…
We’ve all been guilty of this in IT, myself included. The key to many of these issues is communication, the fastest and most effective way to communicate is to speak with one another. If there is disagreement over a defect a conversation should follow (not via email, or through defects comments, or instant messengers)… go talk to one another. So many positive reasons to do so, forging relationships, collaboration, often the defect can be the catalyst for a wider valuable discussion, sharing of knowledge and perspectives about consumers/domain, a huge amount of communication is actually non verbal, etc. etc. etc.
In an ideal world you’ll have a black and white clear spec with detailed requirements and the defect represents a deviation from a requirement. If, following discussion, there still isn’t agreement that it needs resolution then it should be discussed including the stakeholder who drafted the requirement and it is their decision. Unfortunately we don’t live in an ideal world and often a defect is logged based on a QAers expert opinion that an issue should be resolved, some are naturally accepted and a small number will typically prompt discussion.
If reasonable fact based discussion, with customer/consumer impact as the primary consideration, still leads to a difference of opinion then the owner of the specification is the ultimate decision maker…. be it Product Owner, Business Analyst etc.
Hope it helps… not everything needs to be escalated… it should be a very small minority.
won’t fix, without any other reason, is not acceptable, never (despite of environment, methodology, market, background, whatever…)!
wont’t fix, with a reason, a link to the next already planned improvement or change or refactoring or decease, could be ok.we are Testers, we do not decide! we offer more opportunities to those who have to decide!
cheers.
The developer can not decide on her/his own.
Agreement on prio etc are needed.
If needed escalation to …
In agile this kind of behavior should not happen, because the team decides. The product owner can decide too.
But if all make a hughe mistake (because we as tester sometimes have a much broader view), then wait until you turn out to be right. No other options are then left. And if you are right, then do not make a big fuzz out of it, unless they start blaming you.
Our organization is not that large and one can have direct talk with anyone else.
It’s all about reasoning. There might be different reasons about each bug.
- I might be wrong and programmer may show me that.
- We may have or have not more serious issues.
- Refactoring of functionality bug was found in is coming, so there is no reason to fix it.
- The functionality the bug was found in may be close to its end of life (will be removed from app soon). So there is no reason to fix that thing.
- We may go to BA for verdict and his word determines bug’s fate (he may change requirements / specification to match found behavior).
Remember, testers do not always have the last word. Our job is to inform that what we think is a bug is there, what to do about it is up to other stakeholders who have the upper hand on business decisions.
Like most others, we have a discussion in place (usually between developer-PO-tester) before the bug is put to Won’t Fix. In most cases if there is a strong reasoning it is is accepted by all parties. If it is a regression issue, it needs to be fixed immediately (no Won’t Fix possible; unless the change requires lot of work and the impact for the customer is too low). If the issue is put to Won’t Fix, in order to be fixed later, then we include that bug in Known Issues list and plan it for a precise future release.
- You must be logged in to reply to this topic.