soc-pe-bot
commented
11 months ago Team's Response
Thank you for your feedback. As mentioned "Priority should only contain numbers", therefore "." is not a number. While "1.1" is indeed a number, we state explicitly that "Priority should only contain numbers", rather than saying that "Priority should only be numbers" which appears to be what the interpretation is here, as every character contained in priority should be a number. However, we do acknowledge that we should have specified that it should be an integer as per your suggestion.
However, we believe it should be of type Severity.Low as it is unlikely that the user would input a decimal number in the priority field. This appears to be an outlier case unless an act of sabotage to our system is being carried out. Thank you for pointing it out!
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement:
Do note that the main issue highlighted is that the application DOES NOT run in when there is invalid data. There is no error message or any prompts whatsoever. This would actually make the product unusable in the event of invalid priority number. Suppose the application still runs, it would be severity low or medium. But since the applicationn DOES NOT run I feel that it should be severity medium or high, hence defaulting to medium.
Below are a few additional notes:
I disagree to the point "it is unlikely that the user would input a decimal number in the priority field.". In terms of ranking people by priority, below is a common scenario:
I have Person A ranked: 10
I have Person C ranked: 11
I now have Person B, which I would like to rank between Person A and Person C. This would lead me to adding the number 10.5 as the priority.
You should also note that this is commonly implemented in most ranking systems as they take advantage of the fact that there are infinite rational numbers between any two rational numbers.
Hence it is not an act of sabotage.
Additionally:
I agree that "." in itself if not a number, but as together as "1.1" is has indeed become a decimal number. Note that a decimal number is still a number, thus should be accepted based on your error message.
If the user provides a priority value is "Priority should only contain numbers, and it should be at least 1 digit long" like "1.1" This is a number. The application will not start and throw an error instead. Perhaps should limit to integers only? I believe that correct behaviour should be similar to when duplicated entries and found. The application should start with no data. This is a flaw that causes occasional inconvenience to some users when they accidentally type in the wrong number format but they can continue to use the product.