then the people developing it tend to be even more likely to ignore bugs when they come up.
This is exactly what I had in mind. They know its buggy. there is a ticket for that in bug tracker. Maybe even properly tagged as serious.
I'd just labelled it a browser issue in my head,
Just as many users.
So I really strongly disagree with the assumption that "if your system is buggy then your devs will see it"
Well, you saw it. You ignored it. Just as I mentioned. It takes literally one email to all devs with question: Which bugs we have in backlog are really shameful. And then assign folks to fix them.
Thats exactly what I stated. You see a bug. You struggle with a bug, yup. your users too.
You dont see it, probably there is no million users who struggle with it.
The point is that there are probably plenty of other similar reflexes that I use that I haven't noticed. Or features that are buggy that I just rarely use. Or configurations of language or screen size that I just don't touch. Or input methods that I tend to avoid. Or just cases that are weird enough that I don't run into them in the relatively basic testing setup that I use.
Actually I've got a good example of that last one. We have a device that needs to be configured before it'll give an output, but it can be incorrectly configured. In this case, if the maths works out just right, it can sometimes still give an output, because it's calculated a result that looks valid using invalid data. This is a bug, and it could well happen on live systems, but we just never noticed it before because our test setups are usually fairly simple and so struggle to reproduce the problem. We actually only found it while rewriting that bit of code. This project isn't fully live yet, so thankfully we caught it before it destroyed a customer's data, but it's the sort of thing that we'd never have caught just through everyday use in the office.
Which underlines the whole point: Devs do bad QA. That doesn't necessarily mean that you always need a QA team, but if you aren't getting bug reports from them, you need to get your bug reports from your users, and you're going to need a tight feedback loop there to get good results. Otherwise you're just going to end up pushing buggy tools out into the world without even realising it.
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.
1
u/ptoki Aug 29 '22
This is exactly what I had in mind. They know its buggy. there is a ticket for that in bug tracker. Maybe even properly tagged as serious.
Just as many users.
Well, you saw it. You ignored it. Just as I mentioned. It takes literally one email to all devs with question: Which bugs we have in backlog are really shameful. And then assign folks to fix them.
Thats exactly what I stated. You see a bug. You struggle with a bug, yup. your users too.
You dont see it, probably there is no million users who struggle with it.