Team's Response

Severity changed to low as it only causes mild inconvenience by not showing the correct error message, rather than make the product unusable. Besides, user will only input an invalid date in very rare situations.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

No error or response when scheduling with invalid date

Steps to reproduce: enter command schedule 2 m/Insurance Plan @ 2022-02-40 14:30

Expected: An error or response is printed to inform user that the date specified is invalid.

Actual: No error or response is provided. In this screenshot, upon pressing Enter, the response box does not change.

_{[original: nus-cs2103-AY2021S2/pe-interim#1925] [original labels: severity.Medium type.FunctionalityBug]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Severity is low as it only causes mild inconvenience by not showing the correct error message. User will only input an invalid date in very rare situations.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

[x] I disagree

Reason for disagreement: The issue described in the "original" bug report is not very clear.

original:

No error or response is provided. In this screenshot, upon pressing Enter, the response box does not change.

The bug report seems to be targeted towards the issue of the response box not changing.

Arguably, my issue is different, in that I was more specific, and pointed out that:

an uncaught exception appeared in the console,
the app does not respond in any way upon pressing enter (as mentioned in the specific bug report)

By assigning this bug report as a duplicate of that, instead of the other way round, the team is effectively masking the issue mentioned in 1.

However, since it cannot be fixed independently it is technically still a duplicate.

:question: Issue severity

Team chose [severity.Low] Originally [severity.High]

[x] I disagree

Reason for disagreement: Note: I previously rated this as severity.High, but I think that severity.Medium is more reasonable.

This is the guideline for severity as mentioned in the textbook:

Normal operations include entering the date, or time, or both, wrong as well.

All the bug reports regarding this are mentioning different issues that could happen that would trigger this error:

inputting an invalid day
inputting an invalid month
inputting an invalid year
inputting an invalid hour
inputting an invalid minute
a combination of the above

I disagree with the team that this will happen rarely. There are so many situations that cause this, as listed above, and it could be caused by typographical errors as well. I am of the opinion that this will happen quite often, and if the users know of this bug, it would only cause them occasional inconvenience. Therefore, the severity should be severity.Medium instead.

However, the key point here is not how rarely it happens. The issue is that the user would not know that there was a problem with the app. The user would just press enter, and since no error appeared, and the input did not turn red, they could potentially assume that the app was just lagging, or processing schedules slowly. They would assume that the app was unresponsive, as I did initially, before I noticed the error. Even I, as a Tester, pressed the "Enter" key quite a few times, thinking that the app was just slow, or my keyboard spoilt, before realising that there were issues with the app itself. If I had problems with it, a user with no knowledge about the internal workings of the app, would have problems with it as well.

This therefore makes it a worse problem than bugs where the error message does not match the error, in terms of damage caused; If those bugs warrant a severity.Low, this would definitely warrant a severity.Medium or higher.

onnwards / pe

inputting invalid time for schedule gives is unresponsive. #6