Aug 4
More bug approvals and types of rejections that do not affect classification
Today we know that TLs reject a lot of bugs and have been causing a lot of frustration to testers who spend hours looking for bugs, even more so if the same bug is submitted by another tester in another later cycle. This responsibility falls on the TL every time, and the testers feel demotivated, which should not be the case. I had an idea that will help with the following points.
- Testers more motivated in submitting bugs to the platform
- More bugs sent to the customer
- Depending on the situation, the final decision will not belong to the TL alone
- More uniformity between approved bugs, and if rejected will not affect the tester depending on the case.
I would like to implement two functions in the platform that will work together to make this work.
1- When in doubt about a bug reported by the tester, the TL has the option to flag the bug for the customer to check and the final decision, only in this case, is the customer's, because there are bugs that are valid for one type of site / app, but not for others, so we cannot standardize all the bugs that happen in some situations, since each site / app works differently.
For the cases where the TL is really sure that it is not a bug, either because the tester did not follow the instructions, lack of configuration, forced bug, etc. he should reject it directly.
And cases that the TL sees that it is a bug or shows unintentional behavior in a clear way, it should be sent to the customer without the flagging, so that the tester gets paid when the TL approves and not by the customer, even if the customer rejects later.
2- Along with this, some reasons for rejections should not affect the quality of the tester, because because of the possibility of the customer rejecting, this does not reflect negatively on the tester, some reasons that should not affect the quality of the tester for example:
- The behavior or design of the product you describe is intentional, the customer deliberately implemented this piece of functionality to work the following way....
- This bug is not relevant to the customer and will not be fixed
- This device is not relevant to the customer and will not be fixed (If the device has not listed anywhere as out of scope, otherwise this would fall under did not follow instructions, which should affect the tester's rating)
All other reasons should continue to affect the quality of testers, such as duplicate, out of scope, did not follow instructions, known bug, forced behavior, inconsistent report, unanswered request, etc.
I know that rejecting bugs makes the company lose money, so why do we use this fact as another motivation and implement this suggestion? And then the bugs submitted by the testers, which will be in more quantity and have more chances of being approved than the ones that were rejected, because they will not be afraid of losing quality for that, and stop testing when any of their bugs are rejected for fear of taking a risk and having their quality further affected.
Everyone wins, the customer has more bugs on his product, the testers report more bugs because they are more motivated, and TLs does not bear all the responsibility for every bug rejected on the platform.
If losing money is a problem when you have to reject bugs, it means something should be done about it to be improved and I believe this is one of them
This idea may not be fully formulated yet, and there may be some problems that I don't see yet, but feel free to add your ideas and opinions down here.
Tester: erikarochapereira42
Closed