Introduction to Defect Management
Defects (or bugs) management is a crucial part of the QA Process. Managing bugs is a non-negotiable skill when it comes to software quality assurance. The ability to identify, log, prioritize, and track bugs will increase the quality of any product. In this article, we will look into the specifics of logging bugs, severity vs. priority, and bug triage.
Let’s dive in.
Logging bugs
When we test applications we (more often than not) run into issues we call defects or bugs. These bugs need to be documented. Bugs are commonly logged in project management tools such as JIRA, Quality Center, or similar tools. The point is to ensure the project team has visibility into the bugs you are finding.
It is of the utmost importance to ensure your bugs are clear and descriptive. While there is no standard on how to log a bug, here are a few fields we always include:
- Title or Summary: A concise, descriptive title.
- Description: Include actual vs expected results, steps to reproduce, and attachments (screenshots, screencasts, data dumps, etc.). Please don’t forget the steps to reproduce!
- Severity and Priority: We will go over these in the next section
- Linked Test Cases: It’s important for traceability that we create a link between our bug and the failed test case(s).
- Misc: You may have several other fields available or important to your specific project. The more detail we can provide developers, the better.
Severity vs Priority
These two fields tend to confuse those new to QA. We have seen Severity without Priority and Priority without Severity. We have also seen these two fields used interchangeably.
There are major differences between these fields and both are equally as important!
Severity
Severity reflects the technical impact of the bug on the software’s functionality. Exact definitions can vary between organizations and references.
These are some common Severity levels and their usual definitions:
- Critical — These bugs have a severe impact on the system’s functionality or performance. They often lead to system crashes, data loss, or security vulnerabilities. Example: A bug that causes the application to crash when a user tries to log in.
- Major — These bugs affect important functionality but do not result in system crashes or data loss. They significantly hinder the normal use of the software. Example: A bug that prevents users from saving their work within an application, even though the application doesn’t crash.
- Minor — These bugs have a limited impact on the software’s functionality. They are usually annoyances or inconveniences but don’t significantly disrupt the user’s experience. Example: A typo or a minor alignment issue in the user interface.
Depending on your organization, you may see Severity levels with different titles. They should represent more or less the same definition. Be sure there is a clear agreed-upon Severity scale within your project to ensure consistent bug classification.
Priority
Priority represents the importance of fixing the bug relative to other issues. It considers factors outside of the development team, such as business impact and deadlines.
The scale for Priority is straightforward. 1 represents the highest Priority and 4 represents a Priority so low, that we aren’t going to worry about this bug until some unknown future date. Using the number scale allows you to easily add new levels of Priority if the project demands it. You can also use High, Medium, Low, and Deferred. We prefer using the number scale.
Along with Severity, there is no textbook way to define Priority. It is up to you and your organization to build this scale.
Bug Triage
This is where all our hard work comes together. Triaging bugs is the process of evaluating and prioritizing bugs we have logged. It is a meeting hosted by QA with representation from QA, Dev, Product Owner(s), and Project Manager(s). Typically, the QA Lead will host the meeting and Dev Lead will represent the development team as a whole.
Pro tip: We’ve learned that keeping the invite list on the smaller side typically leads to quicker decision-making. Be sure to invite at least one person from each of the above teams.
In the Triage, you will go through the list of open bugs and make updates to each bug as needed. You must consider the following while triaging each bug:
- Is this bug reproducible?
- Is this bug assigned to the right team?
- Is this bug’s Severity correct?
- Is this bug’s Priority correct?
- When can we expect a fix?
As you can see, this meeting is where we ensure the team agrees upon Severity and Priority. Priority is typically decided by the Project Manager and Product Owner. They have better insight into the business side of your organization and what is more important in the eyes of the “business”.
The cadence or frequency of the Triage meeting is very project-dependent. The meeting can be scheduled once a week, twice a week, or as needed.
Conclusion
Defect management is a skill that every QA Engineer should have. The more you practice it, the better you will become. Defect management is not an exact science. There are general do’s and don’ts, but no defined standard.
Every organization has its own needs. Heck, there are also projects within that same organization with its own needs. This story is meant to serve as a guide to defect management. Tweak it how you see fit.
Curious to hear your thoughts! Let’s ensure quality together by sharing your insights.