|
|
|
|
|
by tfehring
2498 days ago
|
|
This seems like a failure on the part of the product manager(s), not on QA. It's not QA's job to decide whether minor bug fixes should be prioritized over new features, or at all. And if the product manager decides that they should be prioritized, either on a case-by-case basis or as part of a broader "fix all bugs before writing new code" rule, then it's their job to take ownership of that decision and communicate it to the team. Also, if developers felt attacked when bugs (however minor) were reported, that's a pretty serious cultural issue, and again it was likely driven by the product manager's failure to actively take ownership of prioritization decisions. It's easy (and probably more common) to end up at the opposite end of the spectrum, where developers rightly complain about having to work with a bug-ridden codebase because new features continually get prioritized over bug fixes. Bringing all of this back to the OP, I think all of this is still mostly true for handling edge cases. Ultimately it's the product manager's job to decide how robust the application needs to be, and to take ownership of that decision - and to take the blame if deadlines are missed due to dealing with obscure edge cases, or if those edge cases are ignored and come back to bite the company in the ass later. |
|
But a cultural issue is ultimately what I was trying to say, and you kinda nailed it with the idea that cultural issues generally stem from someone not doing their job, or trying too hard to do someone else's.