nus-pe-bot
commented
3 years ago Team's Response
Consider this: If we were to check the validity of the location, we have to consider all different street names for the entire of Singapore. Hence, we did not include catching for location-type filters, because there is no way for us to keep track of all the road names in SG. Furthermore, what if new roads are added in the future?
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I was referring to the fact that multiple parameters can be entered (in the screenshot, two locations are used) and not produce an error (since it is in fact, not supposed to happen), not the fact that the location cannot be filtered. Perhaps a simple check for the number of parameters input or by detecting the number of "location" (it does not affect street names because they don't consist of "location") by the user would suffice; there is no need to check if the location was valid or not.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: Since is in easy mistake to make (and likely for a careless user to do), the severity should not be low, where the criteria states that the bug should occur only on rare occasions. I agree that it should not be high (since the program does not break) but I disagree that it should only be low. Perhaps a medium is more appropriate.
When typing the string with only one type of filter, the command excepts more than one parameter without generating en error, even though the command should be invalid. It gives the user who thought the command accepts more than one parameter major inconcinience as the information is not stored.
The string used in the app is shown below:
However, this is catched in another sequence: