Everything About Bugs a QA should know
From the Perspective of a Tester: What Is a Bug? And How is it Navigated in their Life?
What is a bug🐞?
If you are someone who is already a part of the Tech workforce, you will have some knowledge for sure. For those who are new:
A bug is an error or flaw in an application that causes it to behave in unintended ways or produce incorrect results.
Not every bug is a bug!
Being a QA, before reporting a bug it is highly recommended to look for bug attributes or bug characteristics before proceeding to show off your new findings to the developers or whoever it may concern.
If a bug is reported from the end-users, it may not be the first time it is occurring. Therefore, it should be analyzed for some attributes associated with the bug so that it can be rectified accordingly.
We will discuss well-described examples in the later section of the blog.
What are Some Attributes of Bugs?
Or how do we describe a bug? Does it have wings?
A software bug has a variety of characteristics that will be useful for different people in the organization. Being a QA, it is very important to identify the attributes of the bugs and report them, which will provide the most information to anyone who reads it, thus ensuring that it will be resolved as soon as possible. Let’s dive deep into very common attributes:
Severity
The severity of the bug is determined by the impact that its occurrence has on the system. The severity of a bug can be largely categorized as:
Critical
These kinds of bugs have a severe impact on the system. Impacts like system crash (application not working), data corruption(change/leakage of information), or critical failures. These bugs are given the highest priority while giving attention and resolution.
A simple example:
Upon entering valid credentials, instead of gaining access to their account, they are logged into someone else’s account without their consent.
This bug is a real deal. It needs to be solved as soon as possible to prevent unwanted breaches and to protect users’ confidentiality.
High
These bugs have a high negative impact on the system as critical bugs. But the main difference between a critical issue and a high-priority issue is that high-severity bugs have a high impact, and the possibility of them occurring is very low, therefore they might not need high attention as critical bugs.
A simple example:
When a customer adds items to their cart and proceeds to checkout, the system fails to apply discounts.
Here there is a potential to lose customers due to the frustration of not being able to redeem their discount which contributes to the high priority of the bug.
Medium
Bugs that cause noticeable but non-critical issues, such as minor functionality failures or usability problems do not significantly hinder the user's ability to use the software.
A simple example:
In a messaging application, users are unable to send messages containing special characters such as “&” or “$”. However, the application does not provide any error message or indication to the user that their message failed to send due to these characters.
Here the bug affects the usability of the application as it restricts users from sending messages containing certain characters without providing proper feedback. While it doesn’t completely prevent users from using the application, it significantly hampers their ability to effectively communicate, potentially leading to frustration and confusion.
Low
These bugs can easily be overlooked even by the clients as well. They could be a slight alignment issue in certain pages of the software, spelling mistakes, or low-impact usability issues like adding keyboard shortcuts for frequently used features, etc.
Other low-priority issues also encompass non-essential features or those that are rarely utilized within an application. Documentation inconsistencies and non-critical edge cases, although rare, can often be resolved with straightforward workarounds, placing them in the category of low-priority bugs.
Reproducibility
It is the ability to consistently replicate an issue’s occurrence in a specific condition.
It is easier for developers to fix it when the bug is reproducible. There could be several conditions depending on the size of the application and the influence of the multiple conditions can contribute to the bug.
It is important to provide detailed information to the developer on what exactly is happening from the perspective of QA.
The information could be:
- Version of the Software
- Specific logs when the error occurred.
- API logs in log management tools like (ElastiSearch, Graylog, etc)
- Log files in the machine where the application is running.
- Specific configuration in which the error is occurring.
- Platform in which the software is running. It could be a web-based application, mobile app, desktop app, or any platform.
With the information provided, the product managers can decide whether it’s truly a bug or a hidden gem, uncovering any quirks in the requirements. The developer can easily use the information in the bug report to swiftly spot it, squash it, and get back to their coffee break!
Description
A clear and detailed description of the bug is essential for developers to understand its behavior and potential causes.
This includes information such as the steps to reproduce the bug(reproducibility), expected versus actual outcomes, inputs, and any relevant error messages or logs.
Think of bug descriptions as the gossip column of the software world. These descriptions of the bug collectively contribute to the bug report, which in turn helps everyone associated with the piece of software become aware of the bug and aids in finding solutions to it.
Frequency
The frequency of a bug is the number of times the bug occurs or the number of people it impacts.
A bug’s frequency can influence its priority. High-frequency bugs that occur frequently or affect a large number of users are typically prioritized over those that are sporadic or affect only a small subset of users. To understand this better:
Let’s consider a bug in a web application where clicking on a specific button sometimes results in the application crashing. Based on the frequency:
- If the application crashes every time the button is clicked, it should be placed in high priority, given that the button is part of an important feature in the software.
- If the application crashes only when multiple users click the button at the same time, this would be a less frequent occurrence but still a significant issue. Considering the application has a few hundred users, this could be marked as a medium-priority bug.
- If the app only crashes when lots of people click the button at the same time, it’s still a problem, but not as urgent. Imagine if you’re at a party and everyone tries to go through the same door at once — it’s a mess, but not a disaster. In this case, the issue might be given medium priority because it affects quite a few users.
- If the application crashes only when the button is clicked by a user using a particular browser (the place where web-based application works) version or if the button is an infrequently used part of the application. It’s like if you have a toy that only breaks if you play with it in a certain way or if you barely play with it at all — it’s not a problem most of the time. It could be marked as a low-priority bug.
There are other attributes like Environment (the place where the application is run), Attachments (screenshots or screen records) related to the bug, Assigned To (person/team the bug is reported to), Status (current state of the bug “assigned”, “in progress”, “fixed”, etc) and Comments/Notes (other observations, possible workarounds, root cause). When this information is collected from the QA, a bug report is filed.
Bug Report
Now we know what a bug is and we delved deep into it to find more information about it to provide a helping hand to our colleagues. We QAs collect these attributes of the bug and construct a document called “The Bug Report”. Bug reports are created only when we are sure that what we have found is a bug.
Note: Only submit a bug report if you are certain about the issue. If unsure, always seek approval from the responsible party beforehand.
The point of writing a problem report (bug report) is to get bugs fixed” — Cem Kaner.
Let’s have a look at a sample bug report!
Bug Description:
Issue: Duplicate Notifications
Scenario: The college student relies on a scheduling app to receive timely notifications for upcoming classes and assignment deadlines. However, they notice that they are receiving duplicate notifications for the same event, which can be confusing and overwhelming.
Steps to Reproduce:
- Add a new class or assignment to the schedule.
- Set a reminder/notification for the added event.
- Wait for the scheduled time to receive the notification.
Expected Result: The user should receive a single notification for the scheduled event.
Actual Result: The user receives multiple notifications for the same event, causing confusion and potential annoyance.
Additional Information: This bug could be a result of a programming error in the notification system, where the app is triggering multiple notifications for a single scheduled event. It might be related to how the app handles and manages scheduled events and reminders.
Possible Impact on User: The user might miss important notifications due to the flood of duplicate alerts, leading to potential issues like missing classes or deadlines.
Possible Solution: The software developers should investigate and fix the issue in the notification system, ensuring that each scheduled event triggers only one notification at the specified time.
End of sample report
To ensure a successful bug-reporting pipeline, it is important to have a clear and concise process in place.
This includes comprehending the bug, authenticating its existence, reporting it, and ensuring that it is received by the appropriate team or individual.
However, the ultimate determination of whether a bug truly matters depends on various factors such as industry standards (bug reporting in hardware is different from software), customer expectations (a bug for s), and the level of risk tolerance.
QA Advice 01: To maximize what you observe you can test in pairs, perform tests more than once, video your testing so that you can play it back, don’t test when you are sleepy, or at the very least: be aware of how easily you can miss important bugs that you see only once.
Embrace the learnings and grow professionally.
Happy Testing :)
Author: M M Kishore
Stay connected and stay informed with ProductPanda! If you’re a recent graduate who’s hungry for tech-knowledge, make sure to follow us 🎉 on our journey 🚀 .
