May 10
Can the bug assessment sheet be revised to cover more scenarios?
It is sometimes very confusing when the exact same bug behavior is accepted in one test and rejected in another test.
I say this because I had a very recent experience of this.
For instance, a case where the TL never mentioned certain exclusions in the chat but goes ahead to reject bugs (e.g. bugs reported on credit card encryption issues or bugs reproducible only on specific device or browser OS)
If some TLs cannot be clear on these kind of exclusions, then Test IO should be clear on such disputable issues (e.g. on reproducibility, I have also seen bugs where none other tester could reproduce positively, still get forwarded to customer because it was OS or device specific).
Up till this time, it’s still unclear why Test IO is permitting such inconsistencies on bug rejection reasons from some TLs even after a bug dispute (especially when exact same bugs have been approved in previous tests)
In such cases, the TL position should not be agreed-to in a bug dispute (especially when such exclusions were not made clear in the test scope, chat or Test IO academy but are valid bugs).
If Test IO did not state in the academy that certain bug scenarios be not reported anymore, then ALL TLs should ALWAYS state test-specific exclusions (not stated in out-of-scope section) in their opening comments via chat (e.g. in this test TL approves card encryption caching bug, in another test TL reject exact same card encryption caching issue). This is just one example. I could go on-and-on with other examples.
I would really appreciate Test IO to look into such disputable issues and to revise the bug assessment sheet to provide clarity and classifications for such bugs.
Completed
Hi, Orukpe! Thank you very much for your suggestion and for your willingness to help improve our platform. At the moment, our bug assessment sheet already includes a wide range of cases. We have carefully selected the most common and, in some cases, the more complex or frequently discussed scenarios, so that the majority of situations are covered. At the same time, we try to keep the sheet clear and easy to use. Adding too many additional cases could potentially make it more confusing for testers. It’s also important to note that many bugs can vary significantly depending on the specific context, which makes it difficult to assign a fixed type or severity in every situation. With experience, testers usually develop a stronger understanding of how to evaluate different cases effectively. For this reason, we are not planning to expand the bug scoring sheet at this time. However, this is not a final decision, and we remain open to revisiting it in the future if a suitable case arises. Thank you again for your thoughtful suggestion. We truly appreciate your feedback and always welcome new ideas.