All testers have encountered this situation.  At some point in the testing cycle, you notice a minor issue.  Misaligned text, a button that’s not quite the right size, color is not pretty or any number of other bugs that don’t really affect functionality or may not even be client facing.  Now you have to decide if you stop your functional or other test to spend the time to write up this trivial bug.

Some testers operate by the credo of logging every single bug, no matter how trivial. Others ignore all trivial bugs altogether.  I believe there’s a happy medium, and most testers do operate within a balance between logging all trivial bugs and logging none, if they’re allowed to.

First, let’s be clear that neither way is more right or wrong than the other. But here are some things to consider when deciding whether or not to have your testers – or if you, if you’re the tester – to log every single bug, no matter how trivial.  They might also help you prioritize the ones you do decide to log.

• Will it affect the user experience?
• Will a user even notice it?
• Will it affect a backend process?

Once you’ve answered those questions, then consider the following.  How much time will be spent logging the bug, prioritizing it, fixing it, and testing the fix? Is it worth that cost?  Time is money, after all.

Some managers and developers can view testers as too focused on minor details if most of their time is spent logging trivial bugs.  Much like people question police officers for focusing on minor, victimless crimes when much more significant ones need to be stopped, testers need to put things into perspective and focus on larger issues first.

I’m of the mindset that trivial bugs do need to be logged, but only after the major bugs have been found and fixed.  While testing new functionality back in the days, I focused on the big issues. I made quick notations of trivial things to come back to later, but focus my time on the big things.  Not wanting to slow down the testing and release process, I was waiting to log trivial bugs until the testing is nearly done and the product is close to a release. Time to market is the key. Making your product UI pretty instead of concentrating on functional or usability parts as a first priority is not ideal.

You don’t want to ignore the trivial bugs altogether. Doing so could result in an application with a bunch of minor issues that can start to add up and make your product seem unprofessional and sloppy.  However, the time should only be spent on them after the big ones have been found and fixed.  Help shorten testing cycles and keep them smoother by prioritizing which bugs you add and when. Thoughts?