The Art of Bug Reporting: How to Market and Get Your Bugs Fixed?

What Necessitates the Advocacy of a Bug?

In the act of authoring this piece, the profound words of Cem Kaner spring to mind – “The most adept tester isn’t the one who uncovers the most bugs or shames the most developers. The most adept tester is the one who gets the most bugs rectified.”

Next, let’s dissect the difference between uncovering the most bugs and rectifying the most bugs.

Isn’t it straightforward that any bug noted in a defect tracking system ought to be addressed by the developer? No is the answer. Factors like product launch timelines, project delivery schedules, and developers operating under unrealistic deadlines compel corporations to release products with a few bugs that won’t notably impact customers.

[image source]

Who can assure management that the bugs in the product won’t hamper customer trust, dependability, or investor interests? It falls to the Testing Engineer or Testing team. Each testing engineer has a responsibility to ensure that bugs that could detrimentally affect the product’s quality are resolved or rectified.

The significance of the bug relies considerably on how the tester portrays the problem to the development and management teams.

Consider it as publicizing or advocating the issue. This encompasses two steps:

1. Writing or recording bugs accurately
2. Possessing a thorough comprehension of the bug so that further details can be elucidated effectively

The Methodology of Bug Reporting

Certainly, bug reporting is a systematic process. How a bug is recorded speaks volumes about the technical competence, domain expertise, and communication prowess of the test engineer.

Normally, a bug should comprise the subsequent information:

• Bug Summary
• Steps to replicate
• Attachments (Screengrabs, Log files, etc.)
• Bug reproducibility
• Bug Severity
• Software Version and Environment Data
• Further details based on company needs.

Noteworthy point: Always endeavor to ascertain the root cause of the problem and report it. For instance, a fundamental login failure with the precise combination of username and password could be due to multiple aspects such as:

1. No validation of login credentials
2. Network timing out issues for remote logins
3. The system differentiating between uppercase and lowercase characters.

As a Tester, you should be able to distinguish between the following bug summary statements:

• “Failed to log in with the accurate username and password”
• “Failed to log in with the accurate username and password when it includes a blend of uppercase and lowercase letters.”

The latter provides a lucid and unambiguous elaboration of the issue. By doing so, you not just enhance your credibility as a tester, but you also report the actual problem instead of a mere symptom.

Now, let’s scrutinize each field in a bug report and discuss their important facets:

#1. Bug Summary

A bug summary should offer a succinct outline of the issue. It needs to be explicit and distinct.

For instance::

Let me elucidate with a few cases apart from the theory.

Visualize a simple login module. Suppose the issue is that a new user visiting a site cannot login with their default password. When I illustrated this scenario to numerous beginners I trained at the outset, I received diverse bug summary statements. A few examples include:

“New user cannot log in”

“User login isn’t operating as anticipated”

“User fails to login with the correct password”

From the above instances, can you pinpoint a statement that aptly depicts the problem? I believe not. The summary should consistently offer comprehensive information regarding the failing scenario.

Consider the following statement:

“New user cannot login with the default password received via e-mail or text”

As is evident, the above statement candidly conveys the issue and its position to a developer.

Hence, strive to use exact verbiage in the summary to transmit information directly. Generic phrases like “not functioning right” or “not operating as expected” should be avoided.

#2. Steps to Replicate and Attachments

Bugs that cannot be replicated are often sidelined, even though they may be important. Therefore, it’s vital to jot down the steps precisely and thoroughly.

Steps should be exact and reproduce the actions that led to the issue exactly. For functionality-linked bugs, the following is a good instance:

For instance::

Let’s look at the same problem mentioned earlier.

1. Create a new user with the Sign Up option on the home page. (Sample Username: HelloUser)
2. Get an e-mail and text with a default password. The e-mail ID and mobile number for the text are provided during user creation in Step #1. (Sample e-mail: [email protected], Sample Mobile Number: 444-222-1123)
3. Choose the Login option on the home page.
4. In the username text field, input the Sample Username given in Step #1.
5. In the password field, input the default password received via e-mail or text.
6. Click on the Sign In button
7. Expected Result: The user should be able to log in with the provided username and password and navigate to the User Account Page.
8. Actual Result: The message “Invalid Username / Password” is displayed.

If any detail is absent from the aforementioned example, it will result in communication gaps and the developer will not be able to replicate the problem. The steps must be exact and thorough, including sample data utilized during testing.

When feasible, provide a snapshot of what you witness on the screen. This not only gives a clear depiction of the issue to developers but also serves as proof of your test results.

For non-functional test cases such as stress, stability, or performance testing, in addition to the aforesaid details, furnish information about scenarios that stress the system. Moreover, if accessible, report logs for every operation performed. Logs are generally print statements embedded in the code by developers. They are printed or displayed when a module is executed. Access to logs substantially assists developers in replicating the issue.

#3. Bug Reproducibility

The reproducibility of an issue influences its priority, irrespective of its extent. An issue can be reproducible always, occasionally, infrequently, or even just once. An issue that is reproducible “always” will be given higher priority.

Therefore, it’s a test engineer’s duty to precisely replicate issues that occur consistently. Sometimes, there may be external conditions beyond a test engineer’s control that result in an issue being reproducible only sporadically but over several attempts. In such instances, always furnish the number of attempts in which a specific scenario is executed and the number of times the issue is observed during those attempts.

This lends credibility to your bug report. Additionally, it enhances your standing as a tester. I will explain later why having a good reputation matters.

#4. Bug Severity

Severity is undeniably one of the main factors in prioritizing bugs.

Following are different categories of severity. Note that these are general examples, and severity levels may deviate across companies.

1. Severity 1 – Show Stopper – for catastrophic bugs that prevent users from continuing to use the software, with no feasible workaround
2. Severity 2 – High – for bugs similar to Severity 1, but with a workaround accessible
3. Severity 3 – Medium
4. Severity 4 – Low
5. Severity 5 – Trivial

For example, let’s compare two similar problems.

In our set-top boxes, some service providers exhibit the frequency information of the service currently being tuned. Let’s assume that the frequency is displayed as 100 MHz instead of 100.20 MHz. This may not impair users’ viewing experience but may impact the monitoring diagnostics of the set-tops. Therefore, this can be categorized as a Severity 3 issue.

Now, assume a similar problem in the banking domain: If your account balance is displayed as $100 instead of $100.20, envision the impact of the issue. This would be a Severity 1 bug. As you can see, in both cases, the issue is similar, but the impact varies based on the domain.

Productive Participation in Software Version Control Forums

Generally, companies have their own procedures for scrutinizing and prioritizing bugs. Typically, meetings are conducted at regular intervals during the project to discuss and prioritize bugs.

The process during such meetings is as follows:

1. Fetch the list of bugs from the bug management system based on severity.
2. Review the summary and debate the impact of each bug on the user’s interaction with the software product.
3. Based on risk and impact evaluation, prioritize the bugs and assign them to the appropriate developers for resolution.

During step #2, it is critical for every test engineer to advocate for the bug’s impact on the user experience if it doesn’t get the right priority. After all, test engineers consider the user’s outlook when authoring test cases and executing tests.

Let’s consider the earlier example of not displaying the digits after the decimal point in the banking domain. To a developer, this may seem like a less severe problem. They may suggest that declaring the variable as a floating point instead of an integer would resolve the issue and lower its severity.

But as a tester, your role is to clarify the customer’s perspective. You should underscore how the user would be affected by this scenario. You should stress that this issue could cause panic among users as it could lead to financial losses down to the cents.

Effect of Inadequate Bug Promotion

If a bug is not promoted properly, it can lead to problems such as:

• Incorrect priority given to defects
• Delays in addressing vital issues
• Product launches with serious defects
• Unfavorable customer reviews
• Damage to brand image

Aside from the mentioned reasons, it’s vital to build your reputation as a test engineer. It’s similar to establishing a brand value for yourself.

In the early phases of your career, if you can reduce the number of “Cannot Replicate” or “Need More Info” or changes in severity, your bugs will eventually be trusted and assigned directly to developers for resolution.

To build this brand value and earn the trust of your team, development, and management teams, you need to hone technical skills in terms of testing knowledge, domain expertise, and communication skills.

Conclusion

Proper promotion is vital for the success of any product or service. Even the smallest product can become a success when properly advertised. However, excessive advertising can also harm reputation.

Hence, bugs should always be reported in an accurate, concise, and detailed manner, stating their exact location in the software. By doing this, we not only enhance software quality, but we also cut down testing and development expenditures significantly.

It’s never too late! Let’s forge ahead and resolve those bugs promptly!