nus-pe-bot
commented
2 years ago Team's Response
As mentioned in the guidelines above, there are 2 reasons why this should not be considered a bug:
- This problem can only happen in case of deliberate sabotage: the user has to deliberately manually edit the data file to bypass the restriction. If the user goes to that extent, he is likely an expert user who knows what he is doing, and indeed wants to bypass the restriction intentionally. And it is unlikely that a todo description exceeds 70 characters in the first place (look at your to-do list, how many items are longer than 70 characters?)
- "Allowing such flexibility can in turn allow the user to use the software in ways you didn't even anticipate", as mentioned in another part of the guidelines as well.
Reasons for downgrading severity from Low to Very Low:
Even if it is considered a bug, the severity should be Very Low, since the input being unusually long resulting in some part of the Todo description being cut off can be considered a cosmetic issue, as mentioned in the guidelines above.
To be considered a severity Low bug, it should cause an inconvenience as stated here:
But this bug does not cause any inconvenience to the user.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I believe that the explanation provided by the team does not provide enough rationale for this to be not considered a bug. Firstly, it is stated in the User Guide that the description must not be more than 70 characters in length. This means that the team has explicitly stated or enforced a restriction on the description length to the users, and so exceeding the stated limit of 70 characters should not be allowed by any way possible, even if this means editing the JSON file. The restriction set by the team can be seen in the screenshot below.
In the screenshot that the team provided on the guidelines, the guidelines are applicable to situations when the team does not explicitly state a restriction on the maximum length of a description, and the user attempts to input very long values to check if any part of the string or value gets cut off in the UI, or if it messes up the layout. This is not the case here, since the team did explicitly state a restriction on the maximum allowed length beforehand, and so this should still be a bug. Furthermore, the team stated that it is unlikely that a todo description exceeds 70 characters in the first place and so this is considered a case of deliberate sabotage. I do not believe this is the case. In the screenshot, it is true that a 30-digit phone number can be considered a deliberate sabotage, since 30-digit phone numbers do not exist in the first place. However, it is definitely possible that some users may want to have very long descriptions for their to-dos, since they want the description to be very detailed. Thus, it seems unreasonable that the team is assuming that a todo description that exceeds 70 characters is highly unlikely, which is their rationale for rejecting this bug.
Furthermore, the second explanation that they provided "Allowing such flexibility can in turn allow the user to use the software in ways you didn't even anticipate", as mentioned in another part of the guidelines as well. is not applicable here, since this explanation is talking about overzealous input validation, which is not the case here.
Last but not least, even if the above explanations do not provide enough rationale for this to be considered a bug, editing the description to be longer than 70 characters in the JSON file causes a problem for the users in the app, and so this should still be considered a bug. More details of this are provided in the explanation of why I disagree with the team choosing severity.VeryLow
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.Low]
- [x] I disagree
Reason for disagreement: When the user provides a description of more than 70 characters by editing the JSON file, some part of it gets cut off, and the user may want to see all parts of the todo description, since it provides him or her with the necessary details of the task.
Edited version of the JSON file, with a todo description of more than 70 characters:
The cutting off of the todo description in the application can be seen below:
According to the first screenshot of the guidelines that the team provided, it does qualify this bug as a Low severity level, since this problem does hinder the user, when the user wants to see every part of the description.
Although a todo description of more than 70 characters is not allowed in the app, editing the JSON file allows users to bypass this restriction.