search

louisjoety / pe

0 stars 0 forks source link

[JAR] Schedule Bug #5

Open louisjoety opened 1 week ago

louisjoety commented 1 week ago

image.png

While I acknowledge the flexibility in deadline, I feel that when an actual data is put in some error handling needs to be done when receiving an invalid date

Reason for severity: Cause minor inconviniences

nus-pe-bot commented 4 days ago

Team's Response

While the overall structured-ness of the deadline format is a valid concern, enforcing it however would lead to a loss of our current desired flexibility that we wish to provide to our users. Thus, based on the fact that the flexibility is part of our intended/desired behaviour, the team has decided to reject this bug.

image.png

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: image.png

I agree that retaining the flexible output structure is beneficial. However, my main point is that if a specific date is entered, the app should still recognize and handle it appropriately, rather than accepting invalid date inputs as this is seen as a suboptimal design of this feature from a tester perspective. Such inputs are often the result of user typos, and I feel that it is the tester's responsibility to ensure these errors are addressed effectively.

In practice, users are more likely to specify a clear deadline, as that is the purpose of a deadline, while scenarios without a specific date are rare. In my view, the dev team's current handling of deadline inputs appears to be a convenient way to overcome the issue of invalid date detection, which compromises the completeness of the feature.

Considering that the dev team has acknowledged it in their UG on this matter, I feel that in their next iteration they could explore the situation where a user inputs a deadline in an invalid specific date format and handle the error as well, all while retaining the flexibility on setting deadlines. This category should fall under a suboptimal design of this feature (as adherence to valid date time format should still be met). Therefore, I would like to rectify this matter as response.NotInScope rather than response.Rejected which was proposed by the dev team.