What if you’ve found a minor bug, affecting 1% of users and your actions?
What I would do with any other bug - report it, write the bug report.
1% of 100 users is a very different issue to 1% of 1,000,000 users - make your team and stakeholders aware of the issue (preferably in writing, with a defect report) and then they can make the decision on the priority / severity of the issue.
It might be a minor issue for you, but a huge issue for the company.
This is called Risk Analysis.
By the book, the over-simplified step is to analyze Impact x Frequency. Things that happen rarely but with huge impact can be prioritized, as well as things with little impact but too frequent.
For a deeper understanding, I would suggest watching Michael Bolton's talk on Risk Analysis. There he questions our biases that may induce you to shallow analysis and suggests how to tell a Risk Story, so you can make stakeholders aware of the risks:
There's already 2 correct answers but I can't stress this enough.
You found a bug, you file a bug report.
It doesn't matter who it affects or how. It could conceivably affect 0 real users and still be a bug and you still file a bug report.
A QA's job is not to determine whether or how quickly bugs are fixed. A QA's job is to find bugs and make it known that bugs were found.
There are plenty of answers here talking about how all users matter. Essentially, this is a good reason to care about rare bugs, but I thought I would give a developer's perspective on some other reasons.
First, and most importantly, bugs reveal a mistake in my thinking. It is important to correct my thinking so that I can correct the rest of my code. I once had a bug where a progress bar didn't disappear on time for a small minority of cases. As the dev leading that part of the product, I recognised it as an indication that the clean up routine for the whole system was running just a tad later than I thought it was, and after things that it needed to run before. Occasional ui glitches may seem a minor bug, but the issue it revealed was an absolute time bomb.
Second, and important but less so, I am mathematical enough to know 1 percent is not that small a number. I am a very competent bug writer. All devs are. I have written hundreds of the things, and that is only the ones I am aware of! So, if there were a policy that only bugs affecting over 1 percent get flagged and fixed, chances are almost all users would wind up with a bug that doesn't go away.
Third, even things that do not immediately justify fixing are worth knowing. If it turns out that this bug is really hard to resolve and not immediately urgent, I may mark it wontfix. Even so, when I get chance to do a chunky rewrite for other reasons, I would keep a checklist of defects and avoid them. But if I don't know, I can't design for it.
It really depends on many different things like:
- What is the severity of this bug?
- What is the effort of fixing it?
- 1% of how many users?
There are a lot more things to consider, but a bug is a bug. It needs to be reported and the decision should be taken by the managers. So, I would simply report it.
How do you know bug will affect only 1% of the Users?
Even if bug severity is low (impact low number of user as you say), business like Product owners might increase bug priority and fix it. If you do not create bug report for it, they are missing important information about the SUT.
You should always report bug, once you find it.
A bug that is considered minor today may become critical tomorrow. As an example, many external HDDs only implemented USB mass storage properly, and had buggy USB attached SCSI implementation. That was a minor issue until UAS driver made it to the Linux kernel, resulting in data loss or inability to use such drives with Linux PCs after an update.
Having a minor bug in the bug tracker that stays unfixed is better than finding a bug, not reporting it and forgetting about it until the day it strikes back and you have to search for the root cause all over again.
What I'd do is, as many already said here, to write a bug report. In it you describe what impact it has (not only in terms of affected users but what it causes as well) and with what frequency it happens.
As soon as it's described, you and your team can decide what to do next. Perhaps the business representatives, or the team, decide what priority this bug has. Then you (most likely the developers) can either start working on it, or it will be left for later.
There're some other alternative paths which I don't recommend:
- you don't file a bug report - you're running the risk it is actually a serious issue and you've just failed to find all impacts of it; in such a case, it'll backfire on you later
- you talk about it with the rest of your team first - still better than 1. since others might have important inputs on the topic, but you're still running the risk of e.g. forgetting it after the discussion
...and we'd probably be able to come up with more, these seem to be the most common ones.
I would suggest that you bring it to the client/sponsor's attention and let them prioritize the fix. At the end of the day it's their call as to the severity of the issue.