search

cowlinn / pe

0 stars 0 forks source link

Allowed to add reviews in the future #3

Open cowlinn opened 2 years ago

cowlinn commented 2 years ago

image.png

As a food reviewer, I'm not sure if I should be allowed to add reviews in the future? Perhaps it could be tagged to the current time of the system where you're not allowed to add future reviews

soc-se-bot commented 2 years ago

Team's Response

It can be useful for reviewers to put as a placeholder for future reviews. Checking if the date is a future date will impact testability and will require additional work on implementation. Thank you for the suggestion.

NotInScope: if the feature is implemented to work in a certain way but it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: image.png

I mainly disagree with the team's argument that this impacts testability, and significant additional work. Having implemented something similar myself for date validation, I believe it's actually quite trivial, and requires just one additional check in the parser, and maybe one or two more test cases? Especially if the team already currently uses the LocalDate library.

I added a screenshot of the team's response to a similar bug. I didn't wanna contest because I agree that what's considered a date in the past can become murky and a bit nit-picky. However, I still feel that some input validation should have been considered for the dates (apart from just accepting all legitimate dates). Some considerations should have been shared in the DG/UG even if they didn't want to write any code for this.

I'm not simply advocating for them to lose marks, frankly their app is very solid and I think they deserve as much credit as possible for the QA, because they've obviously done extensive testing. My wording could have definitely have been more firm, but I just feel it's a disservice to themselves if the teams view bugs as suggestions, then reject it under the guise of additional work or "unclear requirements". After all, any change requires some level of additional effort, the argument they've posited can be used for almost anything uh

With additional reference to my earlier bug above, perhaps these two bugs could be combined into one low or even veryLow feature flaw (shared amongst all the teammates for minimal impact on grades) that there was no input validation or consideration to only allow reasonable dates to filter out unreasonable inputs in both the very far past and the future.

Just my two cents :)