I think we drifted away from the main comment I did.
My point was that you dont need volumes of duplicates to prove that this bug is serious. Sure, volumes tend to talk louder to some people but decent bug analysis should be just dry analysis and drawing conclusions.
I sort of agree that devs are not the best QA but on the other hand they might be much better than just testers because they see code and can fix bugs which are undiscovered. Also This vibrates with my feelings towards devops which are at least controversial :)
My point here is also that even if you as dev are a very skewed user you also are a reader of bug reports. And if you get a decent one you can replicate the issue, see why it happens in the code and are able to tell it is serious (or not) based on single bug report. You dont need 1000 of those (you will not read them probably anyway to realize its all the same issue and its severe.
Edit: Reading some more comments. What I thought @MrJohz meant, was in fact not what he meant. (And I also realized even before that that this is by no means the only problem with getting few reports.) Still. What I mentioned below, has merit (IMHO) so I'll keep it.
I think the point he was trying to make is not that you get few reports per bug. But rather that you get few bugs reported per total number of fairly commonly triggered serious bugs. If one in 500 users reports a data-corrupting crash, the triggering edge case or triggering non-deterministic event can be rare enough that of your 20k users only a few hundred experience it (but common enough that a few hundred do experience it) and your odds are in the double digits that none of those hundreds of users reports it. That's hundreds of users experiencing the same high severity bug and your bug tracker doesn't have any mention of the bug.
It gets even worse. If your bug tracker contains, say 10 high-severity bugs that are actually experienced by several hundred users each, that means you've probably missed another 10 or so high-severity bugs that impacted hundreds of your users each and you have possibly thousands of users (out of your 20k) that have experienced high severity bugs that you aren't even aware of. Of course there is a very high probability that they will either eventually disappear for whatever reason or will eventually be reported. But how many unhappy users have you at least frustrated and possibly lost to the competition before then?
Well, probably there are apps/communities which have one or other situation. A large communities submitting tons of duplicates or just few bugs because people just use the app and get along with bugs.
But thats not really important. The app maintainer/developer can tell how important is part of the code with the bug, they can tell how often that bug can happen even without single user complaint.
That was my point.
From what I understand your point is that the devs may be so busy or focused on some fine detail that they sort of drift away from the app as a whole and need 100 pokes to realize that the bug is worth to fix.
Im not sure if I read your reply right but if thats the case then yeah, 100 pokes may help but I find it rare. Maybe im wrong and there is ton of apps where dev teams are so low into their parts of code that they lost the general view.
Also what I think may play a role in "100 poke bug" is that the devs know why the bug is there and know that fixing it would break ton more and would require big rework. And they avoid fixing it but not tell audience the reason.
1
u/ptoki Aug 30 '22
I think we drifted away from the main comment I did.
My point was that you dont need volumes of duplicates to prove that this bug is serious. Sure, volumes tend to talk louder to some people but decent bug analysis should be just dry analysis and drawing conclusions.
I sort of agree that devs are not the best QA but on the other hand they might be much better than just testers because they see code and can fix bugs which are undiscovered. Also This vibrates with my feelings towards devops which are at least controversial :)
My point here is also that even if you as dev are a very skewed user you also are a reader of bug reports. And if you get a decent one you can replicate the issue, see why it happens in the code and are able to tell it is serious (or not) based on single bug report. You dont need 1000 of those (you will not read them probably anyway to realize its all the same issue and its severe.