nus-se-bot
commented
4 years ago Team's Response
This was the intended / expected behaviour of our app. We thought it was likely that cases where the user would enter a date past the last day of the month would usually occur in a case where a patient decides to book an appointment on the "last day of the month". In such cases, rounding down to the actual last day of the month is acceptable.
However, we agree it would have been good to give at least a warning message when such a case occurs, informing the user that they have made a mistake. Hence, we have downgraded it to a feature flaw of low severity, since such cases are rare and do not affect normal operation of the app. They also only pose a minor inconvenience since the user could easily edit the appointment -- they would have had to edit their input anyway.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Firstly, my apologies for the screenshot that failed to upload in the original bug report. Below is the 2nd screenshot I intended to upload which shows the result of my user input.
However, the team themselves has admitted that the user input is wrong and users should be told that they have made a mistake, instead of just accepting the invalid date input and changing the date according to certain assumptions about the user.
Secondly, the assumptions made about the user are inaccurate. The team has assumed that: cases where the user would enter a date past the last day of the month would usually occur in a case where a patient decides to book an appointment on the “last day of the month”. In such cases, rounding down to the actual last day of the month is acceptable. But his might not always be the case for invalid date inputs. In my case, the invalid date I entered was "31-02-2020", but typos occur pretty often, especially when the user is in a rush to add a lot of appointments, and I may have intended to type "31-01-2020" or "31-03-2020". So, I do not think this is a valid assumption about the user.
Hence, I still feel that this this is a valid bug.
:question: Issue type
Team chose [type.FeatureFlaw]
Originally [type.FunctionalityBug]
- [x] I disagree
Reason for disagreement: I think this is a functionality bug as the behaviour of the addappt command differs from normal expectations. I would expect an error message to be returned, stating that the date entered was invalid, but instead of that, my wrong user input was accepted and forcefully changed to become a valid date.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: I do not think this the severity is low because typos can occur pretty often and taking the target user into consideration, by forcibly changing the date into a valid one instead of informing the user about their mistake, it can result in a snowball of schedulling issues. Eg. According to system, patient supposed to appear on 29-02-2020 (last day of the month, assuming date input was 31-02-2020) but patient doesn't show up because he thought that his appointment was 31-03-2020. Thus, this bug is of quite a high severity .
Input: addappt 1 on/31-02-2020 12:30 dur/60 desc/Monthly health checkup. tag/Xray Note that date is invalid and this command is entered while on listpatients page. (I have reported a similar bug with invalid date input while not on the listpatients page and the outcome is different)
Proof of input:
Forces me to add the appt on 29 feb instead (look at result box for date-time field) and actually adds the appt even though date input was invalid (31 feb) ![Uploading Screenshot 2020-11-13 at 4.47.29 PM.png...]