40

Some opinionated points from my experience, doing mostly development and operations with only a bit of QA and support, for the past few decades. Make of them as you will. I don't think it matters if bugs are picked up during formal QA, or by developers doing other work, or even customers or consultants. They should be treated, mostly, the same. My opinion is ...


19

There is a third way, a middle of a road way, if you wish: don't polute the backlog with many low priority bugs, but group them in an epic or a story that might hold them. So, instead of having 20 low priority front end (for example) hot fixes that take 10 minutes coding each but you don't want to build a vesion for each of them, you can have a dedicated ...


13

You deal with them the same way as any other bug report. Review the bug and decide what (if anything) to do about it. If you decide to do nothing, tag it in the bug database with "won't fix" and add a description of a work-round, if available. That doesn't "pollute" your backlog. When you have decided not to fix them they are no longer in ...


13

I go with reject and move-on. The downside is that other folks and new folks will keep discovering the bug 'anew' and have to remember them in their head. Which sounds like a huge problem. In practice I have found that the fear is worse than the reality. Also consider that in many systems the number of bugs based on the combination of different devices, ...


7

I suggested this in the comments but figure it works just as well as an answer: Keep the low priority bugs around, especially things that aren't hard to fix in principle. Use them as onboarding exercises for new people. They'll be just as good for learning codebases and team processes as anything else; delays from lack of experience won't disrupt anything ...


7

Personally, I ask the other team members if such and such a problem is something we even want to deal with. If we agree it's not, I don't bother opening a new bug because obviously no one cares and I don't like doing work that's considered useless. I think what's important is that the team, the customer, or whoever decides what quality is with a concrete ...


4

Communicate. Early and often For this release Be open. Assess the situation as best you can but be sure to pull in the rest of the team and get their input, advice and opinions. Err on the side of over-communicating and most of all don't let fear stop you from being honest. Using a good communication form - slack, teams, etc. may be better than long ...


3

Distinguish "low-priority-and easy" from "low-priority-and-hard". For low-priority-and-easy (for example a spelling mistake in an error message) just fix it. It should be less effort to fix it than to manage a bug entry for it. Make sure your processes allow such bugs to be fixed with 5 minutes' effort; they don't even need a test case. ...


2

"The essence of strategy is choosing what not to do"- Michael Porter What QA need here is insight into underlying pattern/s for bugs, not the nitty gritty details of Individual fixes. Abstract vs Concrete There can be established a solid common ground( probably by a meeting) mutually beneficial for both parties involved by setting the right ...


1

Report the bug(s) and move on with your day, you did your job. Devs should want to fix them now, because fixing them later is more work for them. If the team collectively decides not to fix it, that is fine. If a PM decides it is not a priority to fix, that is on them. If the bug is found by a customer or snowballs into a bigger bug... again, you did your ...


1

There should be dedicated time for low priority bugs. For example, once a month team should review bugs and work one, or two days on all of them, including few low priority bugs.


1

It is clearly a hypothetical question and answer differ based on scenarios here: Scenario1: Defect Spotted: Severity 2 (vulnerability defect in a password field by performing SQL injection) Days before release: found 3 Days before release in 50 days cycle Protocol: I will reach to application owners, BA,Product Owners to be alerted about delays caused in ...


1

You shouldn't feel bad about finding too many bugs. Firstly, what is too many? Are two bugs too many? Are two hundred bugs too many? Your findings are either bugs or not, if they are - report them. Secondly, you might want to consider the social impact your reports have on developers. Maybe reporting 200 bugs to one person or to one team might make them look ...


Only top voted, non community-wiki answers of a minimum length are eligible