A Tester when reports a software bug/defect in the application under testing, s/he feels that it is a genuine defect that needs attention and should be fixed. But to the tester’s shock and surprise, s/hefinds out that bug is rejected by the development team.
I am pretty sure, majority of the Software Testers and QA professionals might have faced this situation some time or the other in their software testing career. And this can be quite frustrating too; especially if the tester feels that the software defect is a serious one and has got potential to cause severe damage to the client/end-user if the software is shipped with the defect. As a seasoned tester, I see no point in being frustrated or swearing at the programmer or being angry or deliberately unhelpful in case your defect is rejected. Let’s try to find the answers to why it happens and how can we avoid it. And before we do so, we have to keep a point very clear in our minds — To Deliver a High-Quality Product is the Team’s responsibility and not just QA’s.
Reasons for Getting Defects Rejected
Defect rejection related to requirements — For any reason, if you did not understand the requirement clearly, you would definitely look out for the misinterpreted requirement in actual implementation and when you would not find it, it would be a bug according to you, which will finally get rejected. This can happen because of either or all points mentioned below:
- No documented requirement that mentions the change details and results expected.
- Changes to a particular requirement were not notified to the tester or missed out.
- The requirement is yet to be developed completely but tested started early.
- The defect is in an area of the application not within the scope of development e.g. external systems, third-party content, etc.
- The faulty system is out there in production since the beginning or for a long time.
Defect rejection related to the test data — The test data used by you is unrealistic. Your bug refers to some dummy test data in the application. This bug would not exist when the real data is set up in the application.
Defect rejection related to the test environment — An application is a combination of many hardware and software requirements, and when a proper test environment is not used or something is missing from the test environment, the application crashes and a critical bug reported. If the program really didn’t work at all, developers would probably have noticed. Therefore, either you are doing something differently from them, or your environment is different from theirs. Since they haven’t noticed, it must be working for them. Ultimately the bug gets rejected.
Defect rejection related to the issue description — When the developer is unable to understand what you were trying to convey via reported defect, expect it to be rejected because they are also loaded with other tasks and if they do not find proper description, no matter how critical the defect is, it’s expected to be marked as Rejected.
- The steps described in the description are not supposed to be carried out by users.
- The Title (Summary) and Description of the bug report are mismatched.
- It is not possible to understand your bug description (due to incomplete information provided or other reasons).
- If your bug is a duplicate bug — it describes a problem that is due to another bug. When this other bug would be fixed, the problem mentioned in your bug report would not exist.
States for a Rejected Defect
Invalid defect — Development team often rejects a defect by marking it as an invalid one, and this happens mostly due to the Requirement misunderstanding or unclear acceptance criteria.
Duplicate defect — By reviewing the defect report, developers might find the defect is a duplicate defect if the core reason for two or more defects is the same.
Defect cannot be fixed or Won’t fix it— if the programming language which is used to develop the software does not have the capacity or solution to fix the issue or if the bug is out there in production since the beginning or for a long time and customers are fine with it as there is a workaround. Developers in these cases might say that the defect cannot be fixed or won’t be fixed.
Defect not reproducible or works for me — Developers might reject a defect if it is not reproducible or that it works for them well. This can happen due to a build mismatch, faulty test environment, and/or not enough test data. Also, this can be a result of inconsistency. For example, if a feature is working, but occasionally the same feature sometimes does not work.
Postponed or Deferred — in this case, a defect is not actually rejected but developers fix the issue in a future release or postpone or put it on hold.
This can also happen in case the developer does not have sufficient time and the issue reported is a non-critical or low business-impacting one.
Ways to Prevent Defects From Getting Rejected
The first aim of a defect report is to let the programmer see the failure with their own eyes. If you can’t be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves. Description of a defect is to explain the defect to the developer, including:
- Abstracted summary of behavior ( expected v/s actual )
- Justifications of why do you think it is a defect.
- Attach any relevant spec links, requirement links to support your claim.
- Test Environment used including hardware and software configuration.
- Clear and precise steps to reproduce the defect, with defined priority/severity.
- Attach test evidence like issue screenshot or video recording, error/exception logs, etc.
Undoubtedly defect reports should be high-quality and precise documents, and this will not only save your efforts but also create a good relationship between you and the developers.
Even then if your bug is rejected, I suggest to perform following steps:
- Read your bug report carefully and try to reproduce the bug.
- Then, analyze the reason for the bug rejection, establish whether it is a valid bug or not.
- If it really an invalid bug, treat this event as a learning experience.
- If you think that it is a valid bug, you should confidently take further action in support of your bug report.
- Either way, you would become more mature as a tester.
DRR: Defect Rejection Ratio
There are many metrics to measure the effectiveness of testing. One such metric is the Defect Rejection Ratio, which is the percentage of rejected bug reports divided by the total submitted bug reports. I personally recall feeling a sense of satisfaction when I would see minimal bugs being rejected for any reason, and for every bug rejected, I would go through in-depth and analyze what went wrong.
Testing By Itself Does Not Improve Quality
Test results are definitely an indicator of quality, but then, they don’t improve it, unless the defects found as a result of testing are fixed by developers so that the software can perform actually the way it is expected to. Also going forward, please do not just focus on the bug count. Focus on qualitative bugs with proper details because ultimately what matters is how you helped in improving the quality of the product and not how many bugs you reported.
If you like what you read, please give a clap and/or share your thoughts in the comments section below as I learn just as much from you as you do from me.