nus-se-script
commented
1 year ago Team's Response
Even if we add a case-insensitive check, testers might raise issues, such as, California and CA are the same locations, but the app allows duplicates. We deeply understand that there is no end to such issues, and these kinds of issues can always be raised, so we will reject them.
The above is just a practical argument. In principle, it's the users' responsibility to enter the correct location in the correct way, e.g., the first letter is capitalized. There are many adversarial scenarios possible, e.g., users enter CC as a location, which is not even valid; and since the product has no internet access for this iteration, there is no way to check if the user input is correct, valid, or actually another name of one existing location in the list.
One example would be email validation. Even if the email passes through your regular expression checks, it can still bounce back, i.e. it can be an email that's not even registered. We feel that we can only exclude certain very obvious invalid cases, and we can add support for more invalid cases in the future. However, asking us to invalidate all the invalid cases is not feasible, as there will always be cases that are invalid and we do not know.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
Even though the user may enter "Tokyo" and "tokyo", I don't think they should be treated as separate location.