How to Identify Bugs that Need to be Fixed

Bugs fixes are an essential part of the quality assurance process. You may think your code is perfect, but bugs will likely find a way to real devices somehow. Sometimes these bugs pop up right before release, and when you are coming up on a deadline, you might be forced to make a choice: which bugs do you fix right away, and which bugs do you live with? This guide will show you how to make those kinds of decisions.  

A bug fix is something that corrects a bug in a program. A bug is something that does not work as expected. Developers fix that unwanted behavior by making changes in the code/database/configuration etc. The method they choose to implement the fix will depend on the type of bug.   

Bug fixes are an integral part of the software process. Companies' reputations rely on the quality of programs they provide to their customers. As we highlighted in an earlier post, customers and users will abandon websites and apps if the program does not meet their expectations. In this increasingly digital world, those expectations can be very high. To make sure you meet those expectations, you must fix issues that would affect user experience. However, in agile development, changes are being made regularly, and in parallel bugs are found constantly. To keep up with release cycles, developers must choose what bugs need to be fixed so that the program can be released on time while maintaining the highest quality possible.  

Not all businesses have the same goals and metrics, and these will affect what types of bugs they care about the most. Ecommerce companies focus on conversion rates. Media companies worry about bounce rates. Mobile App companies care about their app ratings. Fintech companies prioritize information security above all else. As you can tell, there is no one answer. The bugs you choose to prioritize and fix depend entirely on your company objectives. So, take the time to define these before moving on to the next step. 

Now it's time to assign the bugs you find a severity based on your business objectives. Severity is the amount of impact a defect has on the program, often grouped into categories like low, high, and critical. Bug trackers like Jira, Pivotal, and many others make it easy for you to label these categories as you like. While the criteria for what bugs fall within each category will be unique to your business, here are some general guidelines to give you a head start.   

LOW:  

• Minimal impact on the usage of the product.  
• The product shows unintended behavior, but the general usage is not affected.  
• Few users, products, or items are concerned.  
• A feature/piece of functionality is broken or unavailable, but an easy workaround solves the problem.  

HIGH:  

• Serious impact on the usage of the product, but the main functionality is intact.  
• A large number of users, products, or items is concerned.  
• Non-trivial functionality is broken or unavailable, and no workaround exists.  
• Essential functionality is broken or unavailable, but a workaround exists (hence not a showstopper).  

CRITICAL:  

• The bug prevents the core functionality of the app or website.  
• A showstopper prevents the user from continuing with the main process, e.g. the checkout process.  
• The bug causes a potential and notable loss of sales for the company running the app or website.  

For further context, it may be useful to provide your testers with specific examples of bugs and the severities you'd assign them in a "bug assessment sheet." But please keep in mind these are general guidelines. Something like a content / visual bug where an image does not load might be critical to an eCommerce shop (shoppers won't buy what they can't see) while low on a fintech site.  

It's time to prioritize which bugs need to be fixed for the program to be good enough for release. You've pinpointed the things your company cares about the most, and you've made it clear which bugs are affecting those goals by the level of severity you've assigned it. However, just as not all bugs are created equal, not all critical bugs are created equal. 

Let's focus in on an eCommerce example. Imagine your team has found a bug where valid credit card numbers are marked as invalid and are not processed. This is revenue impeding and marked as Critical. Another tester has found a bug where items of a specific product line cannot be added to the cart. Per your bug assessment process, this has also been labeled Critical. Both bugs prevent transactions from occurring, so which one do you fix first? Since the first bug affects every item in the store, while the second only affects a part of the store, the first should be assigned a higher priority and fixed first.   

• Keep your business objectives in mind when you create your bug assessment process. 
• Not all bugs are created equal. A critical bug for some may not be a critical bug for you.  
• Fix bugs that have a significant impact on your users first. NOT bugs that are the easiest to fix.  

test IO prides itself on the quality of bugs it finds, not the quantity. That's why we extensively train our testers to identify the needs relevant to your business and ask that they associate a severity with each bug they submit. However, we also understand that not every tester will understand your business as you do. That's why you can reject bugs. Every time you accept or reject an issue, we learn from it. Rejected a Critical because you didn't think it was Critical? Next time, bugs of that same type are reported as high. Your business is unique, and we make sure to learn overtime and tailor our results to make sure you get value every single time.   

While it can feel like you have to fix every bug you find, the teams that prioritize the important ones first ensure a better experience for their customers. So the next time you are triaging bugs, put yourself in your customer's shoes and think about what impacts them the most. Once you standardize this process, you will be well on your way to shipping higher quality software, faster.

If you want to learn more about how to use crowdtesting to identify issues like these earlier in your release process, check out this post.