3 Worst Defect Reporting Habits and How to Break Them

By Vijay

By Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.
Updated October 25, 2024

In this article, we will look at what are the 3 worst defect reporting habits and how do you break them. Let’s get started. 

Defects are serious business and small mistakes can be expensive.

You know what to do when you find a defect. You can report it; either in a Defect Tracker/Defect Management tool or in an Excel sheet. The underlying principles are the same for both methods.

Defect management tools don’t guarantee better reporting. Good practice always saves the day.  However, to appreciate the good, we must also recognize what’s not.

3 Worst Defect Reporting Habits and How to Break Them

Worst Defect Reporting Habits And How To Break Them

Let’s begin!

#1) Laziness

Don’t take the time to do the best that you can.

This is the defect tracking process followed by most teams:

(Note – click on any image for an enlarged view)

defect-tracking

As you can see, Test leads review the defects before sending them out to the QA teams.

This review includes confirming:

  • Validity – Is this a bug?
  • Completeness – Title, steps, data, screenshot etc.
  • Duplicates
  • Reproducible or not…etc.

I know firsthand that it is impossible for a QA lead to be 100% thorough.

So, the attitude, “I will report the problem the way I want and the QA lead can recheck. He can decide if the defect is valid/complete or not” is the end of your QA team’s and your credibility.

Did you know that some clients have an SLA for a number of acceptable invalid defects? Once the number exceeds, they start penalizing the contractors for every invalid defect reported.

Remedy: Do your due diligence and be responsible for your deliverables. Did the defect come back for insufficient information or that it is not a bug? It may not always be the development team’s fault.  It is not like they don’t want to own the problems in the application. It could be a genuine QA team mess-up. Don’t let it happen.

#2) Rushing

Let’s do this with an example.

Below is a screen shot of OpenEMR’s create-patient screen. It is an open source hospital management system.

This screen lets the user enter the patient’s date of birth through a calendar feature. What it does not do is restrict the entry to choosing from the calendar. What I mean is, you can choose the DOB as say, “31-Mar-1983” from the calendar. Later change it to “31-Feb-1983”.

open-emr-calendar-feature

open-emr-error-guessing

Why on the 31st of February? Implement error guessing and try negative data in the field; which is the whole point of testing, right?

Once done, I click “Create Patient”. Since the date is invalid, I expect the system to display an error and not create the patient. But that doesn’t happen. It creates the patient as below.

Note the Age and Date of birth fields on the screen below:

openemr-test-tester

After testing, you may try this a few times and decide that:

  • It is a bug.
  • It is reproducible.
  • This is not a duplicate (Check with your team to confirm)
  • Do you know the exact description of the problem
  • Also, for you to know the exact steps that will make it happen.

Now that you have the raw material, you are good to go.

You can start reporting it. Assigning defect severity is a compulsory step and your team might be using something similar to the following table for reference:

SeverityImpact
1 (Critical)• This bug is critical enough to crash the system, cause file corruption, or cause potential data loss
• It causes an abnormal return to the operating system (crash or a system failure message appears).
• It causes the application to hang and requires re-booting the system.
2 (High)• It causes a lack of vital program functionality with workaround.
3 (Medium)• This Bug will degrade the quality of the System. However there is an intelligent workaround for achieving the desired functionality - for example through another screen.
• This bug prevents other areas of the product from being tested. However other areas can be independently tested.
4 (Low)• There is an insufficient or unclear error message, which has minimum impact on product use.
5 (Cosmetic)• There is an insufficient or unclear error message that has no impact on product use.

Since this defect is not crashing the system or blocking a vital functionality or preventing the other areas of the application from being tested, we might go with “Low”.

Looks about right?

WRONG. Based on the patient’s data, all immunizations and other reminders are overdue. This may or may not be right. Also, for a patient their age determines if they see a paediatrician or a general physician, etc.

It affects the dosages of medicines and many other treatment areas that we might not even know of.

open-emr-clinical-reminder

So, I am going to go with “High”. I agree it is unlikely that the hospital staff will enter the DOB of the patient incorrectly. But let that be a factor that impacts the priority of when to fix the issue.

My job as a tester is to make sure that I communicate the seriousness of the problem as best as I can.

Remedy: Never be in a hurry to report. Be 100% sure that you understand the impact of the problem from many angles. They are the best value-add we testers can provide. We are not just saying, “Something is not working”. We are also saying, “Here is what will happen if this continues to not work.” There’s a lot of difference, isn’t it?

#3) Lack of Creativity

Testers have a wonderful opportunity to make suggestions to improve the software.

In your Defect Management tool too, you can submit a defect of type “Enhancement Suggestion.” This is where you can get creative.

Remedy: Think outside the box. If you think a certain feature is missing a “Wow” factor and you know how to bring it into it, put the idea forward. At worst, it could get rejected and that’s OK. The important part is trying.

Also, use this super power with caution. Try not to make comments such as “I hate the color of the banner, please change it.”

Here is a good example of an enhancement suggestion that I came across: Replacing “Email to dealer” with “Chat with the dealer” option on a car dealership site. It is predicted to convert more traffic into sales. 

I wish I was that creative! But maybe I can work towards it.

Here’s a bonus from me. A checklist to break free of these bad habits:

1. Does my title convey the problem clearly and concisely?
For example: “Create patient is not working” is not a good title. However, “Create patient fails even when all the input fields contain correct values” is.

2. What is the rate of reproducibility?
In other words, does it always happen? Do I know the exact sequence of steps that will repeat the problem?

3. Is the problem platform, browser or user specific?

4. Have the steps been completed and gotten you to your issue?

5Can I have a screenshot included?

6. Do I need to annotate my screenshot to highlight any particular areas?

7. Is the name of the image file attached descriptive?
Don’t use something like, “Untitled.jpg.” Make sure to give it a descriptive name.

8. Did I include the test data?
For example: For a defect in an Admin module that requires authorization credentials, include them. The development team may or may not have access to the QA environment. You don’t want a delay or follow-up on something as basic as that.

9. Can I give any other details to reinforce my defect?
(Example: a reference to the FRD or a conversation with the client, etc)

10. Do I understand how severe the problem is from different perspectives?

11. Do I know the root-cause of the problem? If yes, do I have evidence (maybe log files) and can I include it? Please note that you might not always know this or need to know this. But if you do, it doesn’t hurt to include it.

12. Is the defect report free of grammar, format, spelling and punctuation problems?

13. Do I know of a way to improve the product?

Do you think this is time-consuming? Well, once it becomes a habit, it won’t be anymore.

Rooting for better defect reporting routines!

About the author: This article was written by STH team member Swati.

Feel free to post your queries/feedback in the comments section below. We would love to hear from you.

Was this helpful?

Thanks for your feedback!

Recommended Reading

  • bug reporting skill

    In this article, we will see why bug reporting is an art that should be learned by every tester. Let's get started. What exactly is the tester supposed to do? I was just brainstorming with my team. A number of…

  • Defect Life Cycle Tutorial

    Introduction to the Defect Life Cycle In this tutorial, we will talk about the life cycle of a defect to make you aware of the various stages of a defect which a tester has to deal with while working in…

  • Bug Reports

    On request from may readers I am updating sample bug report on separate page. Here are couple of sample bug reports and treat them as samples only. You can always make the changes in bug report format as per your…

  • What is Defect Based Testing Technique?

    Defect-Based Software Testing Technique A Defect-Based Testing Technique is a technique where test cases are derived from defects. Instead of using traditional requirements documents or use cases (Specification-based techniques), this strategy bases its test cases on defects. A categorized list…

  • Defect Life Cycle and Defect Management Process

    Introduction to Defect Management Process: The more focused process and testing will allow less buggy software in the market. Defect Prevention is much more efficient and effective in reducing the number of defects and also is very cost effective to…

  • Defect Triage Meeting

    A complete guide to Defect Triage Process and Effective ways to handle Defect Triage Meeting: In today’s article, we will learn about Defect Triage meeting and how to handle a triage meeting in an easier and effective way. Before proceeding…

  • How To Write A Good Bug Report

    Here's how to write a good bug report with some helpful tips and tricks. Let's get started. "The point of writing a problem report (bug report) is to get bugs fixed" - Cem Kaner. If a tester is not reporting…

  • Deal with blocker defect

    In this article, we have provided our readers with the best 3 strategies for dealing with a blocker defect. We will cover some key steps a tester can take when dealing with them. Let's get started.  Blocker defects add a…


14 thoughts on “3 Worst Defect Reporting Habits and How to Break Them”

  1. Bug report should have minimum details. But developer should understand and no need to follow for tester.

    As a tester, i don’t like to go through other testers bug summary

    Reply
  2. @Naga Sekhar: That is what I meant by ” Can I give any other details to reinforce my defect?”- But you are right- I should have elaborated it further. Thank you for your contribution. I think it has enriched this article.

    Reply
  3. Hi there ,when assigning bug to developer do we need to assign the bug to the same developer who developed that particular module?

    Reply
  4. Nice and informative check list, but needs to be added few more as below mentioned,
    Severity and linking to the user stories/requirements if any other tools supports this.
    Video capturing and environment details( like configuration/test environment and etc).

    Overall nice article.

    Reply

Leave a Comment