As testers, defect tracking and reporting are key aspects within our role, as it is crucial to communicate such results back to our developers or higher management in order to ensure we release a stable and flawless product. However, we know that a lot of the times when we raise a defect, developers reject it for some reason.
In this article, we shall see what are the reasons developers reject reported bugs and Why? Usually, these are the 5 most common and generalized reasons (as also seen in the diagram below):
1. It is not a defect or it’s an invalid defect
Why does the Dev team say it is not a defect or that it is an invalid defect? By seeing the defect report, the Developer might say it is not a defect due to the following reasons:
- Misunderstanding of the requirement. For example, a developer understands a feature as a link, whereas a tester understands it as a button.
- When the build or software is wrongly installed. For example, when there’s a mismatch in the build steps.
- Referring to the old requirement. For example, when a feature is enhanced, the developer develops it with the new SRD (System Requirements Document), whereas the tester tests it using the old SRD.
- Adding extra features. For example, the developer thinks it will be useful to add extra features, but the tester is using the requirement document that lacks the new features.
2. Duplicate defect
By reviewing the defect report, developers might say the defect is a duplicate defect due to the following reasons:
- Testing a common feature, testers might find the same defect and thus it is duplicated. For example, a link present on the home page is also present on another page because the navigating page is the same.
- Reduce defect count. For example, if the same feature is displayed on two or more pages and fixing it on one page may fix it in all pages for the feature.
3. Defect cannot be fixed or won’t fix
Developers might say that the defect cannot be fixed or won’t fix. Why?
- If the technology itself is not supported. For example, if the programming language which is used to develop the software does not have the capacity or solution to fix the issue.
- If the defect is at the root of the product & is a minor defect, meaning it is not impacting the customer business workflow. If it is a critical defect, then the developer should indeed fix the issue. For example, if the ‘Search’ text field is not accepting more than 100 characters.
- When the cost of fixing a defect is more than the cost of the defect itself. For example, if a user is not able to add 500 items to a Shopping Cart in an eCommerce application.
- Because of inconsistent defects. For example, if a feature is working, but occasionally the same feature sometimes does not work.
4. Issue not reproducible or works for me
Developers might tell you that the issue is not reproducible or that it works for them well. That might be due to a build mismatch and/or not enough test data. For example, if the platform/Browser/OS is not mentioned in the defect report, then the developer will try to reproduce it on another platform, and it might just work fine for him. We need to make sure to deliver proper defect reports with all the relevant information for reproducing the defect.
5. I will fix the issue in a future release or postpone or put on hold
There are also scenarios in which developers might say they will fix the issue in a future release, postpone it or put in on hold, due to the following reasons:
- Finding a minor defect at the end of the release, and the developer might not have sufficient time. For example a spelling mistake on a link.
- If a customer is planning to do a lot of requirement changes.
These are 5 of the most common reasons I experienced while reporting defects. I would love to hear your thoughts and what reasons have you been getting from your developers?
Hope you enjoyed and happy bug hunting! 🤩