As with all software products, bugs may surface that affect the functionality of the application. This article provides insight into the process that we follow when characterizing, prioritizing, mitigating, and testing a resolution of a bug.
All bugs are not the same. When prioritizing bug resolutions, we take into consideration their impact on the platform, or “severity”, as well as the number of customers affected, or “Prevalence.” A deficiency of the system that has a more severe impact on customers, and is also affecting a larger number of customers will get more priority than a bug that is less impactful and/or is affecting less users.
The times outlined in the matrix below represent our maximum goal resolution times for each bug type, as measured by Severity and Prevalence. Due to the nature of bugs, some seemingly simple bugs become very complex and difficult to resolve. As such, despite our best efforts, these goals may not always be met for every bug we encounter.
|Affects a Single Customer||Affects Multiple Customers|
Issues of both a critical and timely nature whose impact, if left unresolved, could have a crippling effect on sales teams and/or marketing campaigns. “Crippling” means that the ability to market and sell to customers has ceased. Examples may include:
|48 hours||24 hours|
Issues of a crucial nature whose impact, if left unresolved, could have a major effect on sales teams and/or marketing campaigns or could result in possible data loss while the problem persists. Marketing and sales beneficial aspects of the application are disabled. Examples may include:
|5 business days||3 business days|
Issues of an important nature whose impact has an effect that limits functionality, but there is no possibility for data loss. Examples may include:
|12 business days||10 business days|
Issues whose impact does not completely affect the functionality but may detract from the user experience. Examples include:
|15 business days||15 business days|
|Trivial/Tasks and individual customer induced issues
Issues that have no impact on functionality or are limited to a single customer. Examples may include:
|20 business days||20 business days|
New feature requests are evaluated on a completely different scale. For more information, please read the help article available in the Support portal.
If we miss our goal for the resolution time of a Moderate, Minor, or Trivial bug, we will continue to work on the issue with the updated status of Severe.
The bug resolution process includes multiple steps to address and resolve the issue. The steps are:
- Analysis and logging – The Support and Product groups verify that it is an actual bug and that it has not been addressed by another development ticket. Once it is verified, identified as unique, and all relevant details have been gathered, a new bug ticket is logged.
- Development – The logged bug ticket is picked up by development and work is done to reproduce and resolve the issue.
- Code Review – Once the ticket has been marked done by development, it undergoes a review process to ensure that the code is consistent with the rest of the application and will not negatively affect other areas of the application.
- Quality Assurance testing – This step confirms the resolution in a staging site and runs tests to ensure that the issue is resolved
- Regression Testing – The step records the resolution and runs test against the entire application to ensure it has not recreated previously resolved bugs. This step ensures that a bug can never reoccur in the same way.
- Release – Once a bug resolution has passed QA and been verified by the product team, the update code is released into the production environment and resolved in customer instances.