3 Worst Defect Reporting Habits and How to Break Them

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

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)

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”.

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:

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:

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.

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?

5. Can 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.