How to report an issue as "Excessive incorrect downgrading/rejecting/ duplicate-flagging"

[yiwen101]

I am wondering how could we, in our rebuttal for unscrupulous attempt at gaming the system, signify clearly to the moderator that we deem this as qualifying for being ""Excessive incorrect downgrading/rejecting/ duplicate-flagging" on top of including these lines in our rebuttal?

I was irritated by a bug found by a tester, who abusively modified the data file to engineer the irregular behavior of the app, and reported this as a severity high bug.

This must be penalized, as otherwise, the acceptance of this implies 1 Every single team project, past, now and future, will be qualified for this "severity high" bug that "happen frequently" and "prevent the potential user from using the app", as it is literally impossible to store data "locally and human editable" and could withstand arbitrary modification at the same time. 2 PE will downgrade into an endless and meaningless game of abusing other's system.

[cyr123456789]

[yiwen101]

The irritation does not come from the invalidity bug the tester raise, but from how the how the tester is being "Excessive incorrect downgrading/rejecting"

Firstly, the reported issue is with clear evidence not a bug: "It's great if you handled such 'invalid data in the JSON file' situations. But I don't think we want to enforce it as a requirement or consider it as a bug, especially because we didn't mention such a requirement earlier."

This is fine. What irritating are the next two:

Secondly, the severity is extremely inflated.

The frequency this issue will happen will be extremely low given that this issue only happens when advanced user with with reasonable intention and skill to modify data file directly, and make mistake in the process.

The severity of this issue is also low, as we repeatedly warn the user to make a copy of the original data file before modification (which should be the expected behavior of advanced user anyway, even without the warning). So even when this issue happen, it will only cause a small inconvinence. It would not block user from using the app.

This makes me question the intention of putting this as severity high.

Thirdly, the way the tester inject bugs in the storage is indeed intentional and malicious. No reasonable advanced user with reasonable skill and intention of modifying the data file directly will put null(unquoted) randomly in the data file when it clearly contradicts to the format and pattern the data is stored.

Why so hastily hinting at my "low standard of work as a software engineer" before you know more detail of the case?

The irritation does not come from the invalidity bug the tester raise, but from how the how the tester is being "Excessive incorrect downgrading/rejecting"

[damithc]

The irritation does not come from the invalidity bug the tester raise, but from how the how the tester is being "Excessive incorrect downgrading/rejecting"

@yiwen101 "Excessive incorrect downgrading/rejecting" refers to developer response, not bug reports. Testers are not downgrading/rejecting, they are reporting things they think are bugs. If you feel like the tester is rejecting or downgrading, you may not be looking at the tester's role in the right way.

Firstly, the reported issue is with clear evidence not a bug: "It's great if you handled such 'invalid data in the JSON file' situations. But I don't think we want to enforce it as a requirement or consider it as a bug, especially because we didn't mention such a requirement earlier."

To be safe, refrain from referring to previous semester forums. Things may have changed since then, although this statement is still correct.

Secondly, the severity is extremely inflated.

If this is the case, this can only hurt tester's accuracy. It doesn't hurt the receiving team, provided you downgrade the severity to the correct level. So, not really a reason to get upset about.

Thirdly, the way the tester inject bugs in the storage is indeed intentional and malicious.

Not commenting on this specific case but in general it is a good thing when testers do all sorts of nasty things to the product and report what they observe. This is because developers tend to (subconsciously) test their own products 'gently' while testing also need to be 'destructive' at times. Many such observations can be considered and discarded but some may point towards bugs or where the product can be more resilient.

One of the takeaway from this phase of the PE is to train yourself not to get upset over bug reports. It is not the natural reaction but that's why it needs training. It's like having too many food options at a buffet. Sure, it takes extra time to consider all options, but in the end, you just eat what you want and ignore the rest. Likewise, just reject the bug reports that are not really bugs. In our context (not in a real project), you can also be thankful that the tester wasted time reporting non-bugs, thus possibly reducing the real bug count, and your penalty.

No reasonable advanced user with reasonable skill and intention of modifying the data file directly will put null(unquoted) randomly in the data file when it clearly contradicts to the format and pattern the data is stored.

Considering the above, you may be able to reject such bugs, in which case only the tester lose accuracy, no harm to your team. In a real project scenario (not in our tP/PE context), it is best not to assume the user will not do this and that. For example, it is also possible that an amateur will think of themselves as an 'advanced user', try to modify the data file, and mess it up. While it is fine not to cater for everything user might do, it is also good to be able to survive or gracefully fail no matter what the user throws at your application.

[yiwen101]

The irritation does not come from the invalidity bug the tester raise, but from how the how the tester is being "Excessive incorrect downgrading/rejecting"

@yiwen101 "Excessive incorrect downgrading/rejecting" refers to developer response, not bug reports. Testers are not downgrading/rejecting, they are reporting things they think are bugs. If you feel like the tester is rejecting or downgrading, you may not be looking at the tester's role in the right way.

Firstly, the reported issue is with clear evidence not a bug: "It's great if you handled such 'invalid data in the JSON file' situations. But I don't think we want to enforce it as a requirement or consider it as a bug, especially because we didn't mention such a requirement earlier."

To be safe, refrain from referring to previous semester forums. Things may have changed since then, although this statement is still correct.

Secondly, the severity is extremely inflated.

If this is the case, this can only hurt tester's accuracy. It doesn't hurt the receiving team, provided you downgrade the severity to the correct level. So, not really a reason to get upset about.

Thirdly, the way the tester inject bugs in the storage is indeed intentional and malicious.

Not commenting on this specific case but in general it is a good thing when testers do all sorts of nasty things to the product and report what they observe. This is because developers tend to (subconsciously) test their own products 'gently' while testing also need to be 'destructive' at times. Many such observations can be considered and discarded but some may point towards bugs or where the product can be more resilient.

One of the takeaway from this phase of the PE is to train yourself not to get upset over bug reports. It is not the natural reaction but that's why it needs training. It's like having too many food options at a buffet. Sure, it takes extra time to consider all options, but in the end, you just eat what you want and ignore the rest. Likewise, just reject the bug reports that are not really bugs. In our context (not in a real project), you can also be thankful that the tester wasted time reporting non-bugs, thus possibly reducing the real bug count, and your penalty.

No reasonable advanced user with reasonable skill and intention of modifying the data file directly will put null(unquoted) randomly in the data file when it clearly contradicts to the format and pattern the data is stored.

Considering the above, you may be able to reject such bugs, in which case only the tester lose accuracy, no harm to your team. In a real project scenario (not in our tP/PE context), it is best not to assume the user will not do this and that. For example, it is also possible that an amateur will think of themselves as an 'advanced user', try to modify the data file, and mess it up. While it is fine not to cater for everything user might do, it is also good to be able to survive or gracefully fail no matter what the user throws at your application.

I see. Thank you for your prompt and kind response.

"One of the takeaway from this phase of the PE is... It is not the natural reaction but that's why it needs training... the rest."

I appreciate how enlightening the response is. Thank you again for not only correcting my wrong cognition about testing, but also guide me to adopt growth mindset and benefit from the event.