4

Occasionally I'll find a bug that is so minor, so miniscule, so unimportant that I know it will get buried under all the high priority bugs. The bugs I find in the application are things like "The Tab order between two items is reversed" in the face of the occasional "Opening the application twice and spinning around three times counter clockwise will set your computer on fire" bugs. I have a growing backlog of bugs that will never get solved, and there is some work involved not just for me in every "fluff" bug I write, but also for others. My team has to triage the bug, and it has to be considered with every iteration whether it will be picked up to be fixed.

While I understand that such careful scrutiny shows that 1.) I'm paying attention to detail and 2.) I'm testing the application, it doesn't seem from my end like I'm bringing much value to the company.

How should I approach bugs like this?

2
  • The way we approach bugs like this is that we throw it deep in our backlog. Also, if the bug is minor AND easy to fix we usually bring it up in our regression testing and let developers fix it there. Are you in an agile team?
    – Robben
    Dec 29, 2015 at 20:53
  • See also sqa.stackexchange.com/a/17387/8992 Dec 11, 2016 at 12:37

5 Answers 5

6

Based on your example "fluff" bug, which is not really that fluffy: keep logging small bugs, and do more to convince your team to fix them.

The book Lessons Learned in Software Testing addresses this head-on in a page called "Lesson 72: Minor bugs are worth reporting and fixing." A few key quotes:

they concluded that cheap fixes (of minor bugs) could have prevented over half the technical support calls for this product. [...] Any product can get by with a few minor defects. But as the number increases, customer confidence declines. More disturbing is the corrupting effect of tolerating these bugs.

I'd recommend reading all of Chapter 4, "Bug Advocacy."

Some teams are more wiling than others to go back and do minor bugfixes. Talk to your colleagues individually and figure out who your allies are. If your team can clean up the small bugs on a regular basis, it will significantly improve your product.

If that remains a struggle, do your best to catch and fix bugs before you sign off on new features.

1
  • Well said. And that annoying tab order could be the niggle that causes a user to prefer an alternative product. Consumers are increasingly preferring simple, fast, and correct, over all the bells and whistles.
    – Andy Boura
    Dec 30, 2015 at 22:02
2

Yes, it is common for some bugs to never be fixed because it's always considered to be more worthwhile for the business to either fix different ones, perform tasks or (most commonly) implement new features to achieve new business objectives and increase revenue. I experience this myself particularly with old browser bugs that I have to keep testing and seeing and knowing that other devs don't have to see them as they are not exactly testing IE8.
Some options are

  • Keep them in the backlog and revisit them each week. This way you spread the pain and increase the likelihood of attention.
  • Make a schedule to fix, say, 1 per month, so they only take a small % of time in comparison to new feature work.
  • Fix them on technical fix fridays.
  • Have an occasional 'bug fix week' just for fixing old bugs even small ones.
  • Put them in the icebox and consider looking at them periodically or occasionally. or never.
  • Delete them and rely on the product owner or the team to remember the little stuff.
  • Focus on educating the team more on good practices and approaches and why to do them and what the aniti-patterns are. Then tickets that are relevant will then have had the general case made for them up front.
1

One of the most important tester's tasks is to find bugs, track them clearly in order to allow developers to reproduce them and set the right priority and severity.

I fully understand you concern when you spend hours reporting minor bugs but even finding minuscule issues you are providing value to the product and, as a consequence, to the company. Trust me if I say that when you present a new product to customers even a wrong tab order could be embarrassing if the user tries to move between fields with the TAB key. Tens of minor bugs are really annoying when you use a software on a daily basis and users start thinking to the product as non reliable.

If you are working on an Agile team you should have a product owner and perform testing sessions on regular basis, that one will be the moment for evaluating all of the new issues and changing the priority of the existing ones if required.

0

bug may be major or minor need to be fixed ASAP because as a black box testers we don't know the code structure and objects used in it so severity of that bug might be high or low , fixing those minor bugs at release time might produce functional issues.

if you following agile methodology and that bug is out of scope for first iteration the have a word regarding bug with yours seniors.

if the bug is minor introduced at release of product keep informed about it, if minor bugs are more in numbers then client or customer wont happy at all.

0

Another problem with deciding which bugs to report or not is that there is a risk that you stop reporting bugs that should have been reported and corrected.

In my experience you should report ALL bugs you encounter into the bug reporting system. If you don't want to "expose" these minor bugs imediatly you could asssign them to your self and revisit them later.

With bugs i don't only mean obvious errors, but also if you are not sure if this is an error or not.

In some (imature) organisations the developers/product owner consider flaws in the GUI as minor bugs. I think it is important to build confidence in the application by having a nice and flawless GUI to intearct with.

The first thought I get when using a new application with minor bugs is that these bugs are the "top of the iceberg".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.