nus-pe-bot
commented
5 days ago Team's Response
Hi! Thank you for the bug report. We understand your concerns with regards to phone number input validation. Our team did not set up any further constraints than the one we currently have in place (must have at least 3 numbers) as we believe that doing so would fall under overzealous input validation.
While it is true that the E.164 Limitation would lend to a phone number with a maximum of 15 digits, our target audience / users (medical staff) often meet people from many different walks of life, which lends to them having many different numbers. There are many instances where our user may want to record a number longer than 15 digits for a patient or doctor. For example, Dual-Tone Multi-Frequency Tones (DTMF) are not restricted to the E.164 limit because they are part of in-call communication. Similarly, many customer service systems are designed to accept long inputs and the maximum length of such numbers are not restricted by phone standards. In the event that the patient / doctor to be recorded can only / would only like to be contacted via such methods, the user / medical staff would have to record their contact details accordingly.
In the event that a patient or doctor wishes to record their phone number where relevant under such schemes, we do not wish for our application to prevent this. When faced with such long numbers, the user is free to record it under the phone number tab while including any relevant details in the remarks column to facilitate future contacting of the patient / doctor.
Our team sees your point and agrees that there can be value in validation of phone numbers, however, given the constraints and context of the project, we do not believe this to be a vital and crucial feature to implement first, over other functionality that may be more important. Validation of phone numbers is a much more complex process that involves factoring in countries, personal context and background, or alternatively may involve generations of OTPs / acknowledgement messages -- which we believe is not a priority.
Hence, coupled with the fact that the input did not crash the app, corrupt the data, or make the app unusable, we believe that this should be considered NotInScope.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: The defense provided by the development team regarding phone number input validation is flawed and overlooks key points about usability, accuracy, and the integrity of the application. First, the user guide explicitly reserves the phone number field for actual phone numbers. It does not suggest that this field can accommodate non-phone-number information, such as DTMF tones or extended sequences that are not compliant with phone number standards. Allowing users to input such values without restrictions creates ambiguity about the intended purpose of the field and undermines the system's ability to standardize and manage critical data effectively. Users rely on the system to enforce clear and precise validation rules to prevent errors and ensure data consistency, especially for something as universally defined as phone numbers.
Furthermore, the justification that medical staff might need to record longer inputs for communication purposes is inconsistent with the field's intended use and the constraints of real-world scenarios. Phone numbers globally adhere to established standards, such as the E.164 format, which imposes a 15-digit maximum for valid phone numbers, inclusive of country codes. Any communication requirements beyond this scope, such as DTMF inputs, should be recorded in auxiliary fields like remarks, rather than compromising the integrity of the phone number field. By allowing excessive inputs, the system introduces the risk of data entry errors, reduces the reliability of the contact information stored, and creates complications for downstream functionalities, such as automated dialing or integration with external systems.
Contrary to the team’s assertion, phone number validation is not a "low-priority" feature. It is a fundamental aspect of ensuring data quality, which is essential for the proper functioning of an appointment or contact management system. Ignoring proper validation can lead to downstream issues, such as incorrect communication with patients or doctors, wasted time for staff resolving errors, and ultimately diminished user trust in the software. Basic phone number validation—restricting inputs to logical lengths and ensuring numeric values—does not require complex implementations such as OTPs or personalized acknowledgments, as the team suggests. A simple rule to enforce the 15-digit maximum ensures compliance with international standards and aligns with the field’s designated purpose.
When a 16 digit phone number is used to create a doctor using the following command, doctor creation was successful. However, the longest phone number in the world (inclusive of country code) is only 15 digits. Users might have entered 1/2 extra digits by mistake but the command does not guard against this behaviour as it should.
createD n/test p/1234567890123456 e/x@gmail.com a/test