When Low Priority Bugs Should be Fixed

So you file a UI issue. No functionality is broken, the site looks ok. The deadline is close, and it makes sense to launch it. No one wants to delay a deploy because of a few pixels. When do you put your foot down? Maybe it isn’t worth fixing the color on a banner that only shows up for 5% of people using the application, or optimizing for an outdated browser that few people use. But not all issues that are marked as low priority should be ignored.

Low priority issues should be fixed when they make you look sloppy. Sure, everything works, but if your alignment is off, your headlines are the wrong font size, or spelling / grammar could be improved – the overall look of the application is sloppy. People will not remember that the log in process worked just fine, they will remember that your news story hung halfway off the page, that they had to scroll down the page to get to information or that your content blocks were not lined up.

low priority defect on Facebook

Low priority issues should also be fixed if they they add frustration (now or in the future). If your page can only be viewed well in one or two browsers, you may lose users who don’t want to download and use an unfamiliar browser.  Anything that can cause frustration to your users or waste the customer service department’s time helping people find work around is better off fixed.

Your site should be polished- functionality, and look and feel. If adjusting a low priority defect gives a more professional overall appearance, or saves you from having to have a detailed troubleshooting page- they should be fixed before launch. And it is worth the QA departments’ time to make a stand for them.


4 responses to this post.

  1. Sing it to the choir! Absolutely agree.

    Websites and applications that are skewed / pixilated just have this look of neglect about them.

    It always worries me that if the development team behind a site/application let something small and noticable like an obvious UI issue through, what have they let through that is BIG and noticable.



  2. Devon, I totally agree that removing unecessary frustration and improving a professional overall performance would be a good thing… but I am just a tester.
    I can only report the facts about my findings and my personal opinion about the functionality and usability of the product. Whether any issues should be fixed or not is not up to me. My job is to provide information to the powers that be and let them decide.

    Personally I think your angle is wrong; You say “Low priority issues should be fixed when they make you look sloppy”. If you think issues making you look sloppy is a bad thing and should be fixed, on which I to a large extent would agree, they should not be a low priority. They should be Show Stoppers. But you, as I am, are probably just a tester. You do not decide what is important enough to commit resources to fix.
    Of course, this depends on the organization in which you work. Is it a large org where you just stick to your job or a small one where all people are encouraged to state one’s opinion about what matters or not.

    I just received my new MacBook Pro, and being a first time OS X user (after several years using different Windows and GNU/Linux variants) I immediatly recogniced the fact that there are something very different about the priorities of the Redmond and Cupertino clans. It would be meaningless for me to make any judgement on who got it “right” at the moment (we’re just talking hours since I got the MacBook) but it seems to be mostly in the details, the feel of it. However, both computers running Microsoft and Apple Os’ are capable of getting a lot of things done. The question is what’s you market? What matters?

    Sometimes the marketing guys and product owners just might not agree that your “horrible UI issue” is worth delaying the lauch for, but as long as you have made them fully aware of the facts concerning the issue its their call to make… not yours.
    … you might of course come to the conclusion that you will not want your professional reputation to be sullied by being associated to that product or company, but I guess thats material for another blog.

    Thanks for sharing,


    • Thanks for your comment! I appreciate another view on the subject.

      I do agree that the final decision is not up to QA, but as the Lead of the QA department, I do think it that fighting for bugs is part of the job scope. It does of course depend on where you are working, but in my experience, it is important not to just stick to your job, but to take the time to talk with developers about issues, be willing to stand up to other leads or the business department when there is an issue that you believe should be fixed.

      Something may not be high priority/severity- depending on how you set your bug priorities, but still impacts the user. It is up to you to say how much. Of course, you may not always get it fixed, you may not always be right about it needing to be fixed- but I believe it is better to have the conversation than to let an issue be deferred that makes the product look sloppy or frustrates users.

      Even if it isnt big show stopping issues, the customer care team will hear about it if a little thing frustrates a lot of people.


  3. Another important is such UI issues cause lot of call to customer support team,fixing those UI issues in turn reduce the maintenance cost of running customer support service.
    –Dhanasekar S


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: