search

WM71811 / pe

0 stars 0 forks source link

Add command can add a future date without notifying user that it is a future date #2

Open WM71811 opened 3 years ago

WM71811 commented 3 years ago

User may mistakenly input a future instead of current date, so adding future date to "track diet" may not be corresponding to user guide's descriptions, and no error or warning or advice to the user is shown Screenshot 2020-11-13 at 4.31.21 PM.png input: add -n cake -d 12-12-2020

nus-se-bot commented 3 years ago

Team's Response

Thank you for the suggestion, we would add this to our product in future iteration. However, we believe that this is more of a feature flaw than a functionality bug, and doens't affect usage of the user. Therefore, we change the bug type to FeatureFlaw and severity to VeryLow

Items for the Tester to Verify

:question: Issue type

Team chose [type.FeatureFlaw] Originally [type.FunctionalityBug]

Reason for disagreement: [replace this with your explanation]

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Medium]

Reason for disagreement: Thank you for the team's reply.

I think that the severity is not very low since as stated in UG and shown in screenshot of the UG below, the purpose of McGymmy is to record the food intake, that means, record what has already been consumed. I think that ensuring no future date is entered is a functionality missing from the main feature of adding food items with the date of consumption. This is because with the description of the feature, it should be the case that only food that has been consumed can be added, which then means only date that is the current date or is past already should be entered. Thus, entering a future date should be treated as an error by the application, taking into account what the purpose of the application is. Based on the aim of the application, I think that it is an "imcomplete feature" as this functionality of detecting future dates as invalid is missing.

Screenshot 2020-11-20 at 4.43.37 PM.png

Moreover, very low severity means that it "does not affect the usage of the product at all", but if we consider the case where the user did a mistake in entering the date and then entered a future date, I think that an expected behavior of the application would be to give a warning or error message, just as the situation when the date is an invalid date, since this application is used to record what the user has consumed, and entering a future date violates this purpose. Not giving warning or error message to the user may also lead to a result where the user may not find out that the date entered is wrong. Considering the expected behavior, not handling future dates in an expected way may cause "occasional inconvenience" to some users, since the record of food intake would be inaccurate.

Hence, I disagree with the team's decision and think that the not dealing with the future dates in this main feature of the application would cause "occasional inconvenience" to some users, so the severity should not be very low, but medium.