nus-pe-bot
commented
9 months ago Team's Response
In the UG, it is stated that only alphanumeric values for name field, thus there is no mismatch between the UG and the actual product's behaviour.
First I would like to elaborate on why numbers are allowed in name. Given that EzContact is used to help insurance agents manage customer's contacts, it helps the user to identify and approach customers, not helping the customer to do any form of insurance paperwork and documentation. With this reason, the product should give user more flexibility in naming their customers (i.e. user can name a customer Jonathan JB101 to indicate this customer works in JB101).
I do agree with the tester that purely numeric names are very unlikely to happen even in the scenario given above and it good to check for this during validation. However, I do think that it does not bring much impact to our current product. It is also hard to draw the line on how many alphabets and numbers a name should have as there is no "correct" solution for it and finding a sensible constraint for this requires a lot of effort and testing. Thus, we plan to approach this matter in future increments as it has lower priority compared to our other works on the product.
(Changed to feature flaw : Purely numeric name is allowed according to the UG with screenshot above)
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: Considering the app's context, it seems quite rare that a customer would have a purely numerical name. It might be beneficial to include a check to prevent numerical inputs for names. This enhancement could align well with the app's goal of organizing customer information effectively and reducing the hassle for agents. While I understand the scope of development is broad, perhaps considering this refinement could further improve the usability of the app for its intended purpose. considering this suggestion! Additionally, implementing a check to validate whether an inputted name is purely numeric generally doesn't require extensive testing and validation.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** Alphanumeric implies both alphabets and numbers so I don't think there is anything in the UG that states that "Purely numeric name is allowed" Additionally, I think "Behavior differs from the User Guide" and "A legitimate user behavior is not handled e.g. incorrect commands, extra parameters". **Behavior differs from the User Guide**: Your user guide states that EzContact is an "application that can help you organize your customers' information and reduce the hassle of having to remember everything". However, if a number is stated as a customers name, it does not reduce the hassle as stated. **A legitimate user behavior is not handled**: Having purely numeric names is not handled.
Contact names can be purely numeric without any alphabets which seems quite unlikely based on your products' use. Although this does not cause any harm and is very minor, it may be helpful to check for this! Maybe you can include a check to see if there are a certain number of alphabets included!