BunnyHoppp / pe

0 stars 0 forks source link

Emergency Contact Number Format #6

Open BunnyHoppp opened 1 week ago

BunnyHoppp commented 1 week ago

Expected: Emergency contact number allows numbers that are 3 digits long.

Actual: 000 is not accepted even though it falls in the acceptable range.

image.png

image.png

Low severity since it is unlikely for emergency contact number to be 000, and users can use other dummy values if they don't have the emergency contact number but they have emergency contact name.

nus-pe-bot commented 1 week ago

Team's Response

Thank you for spotting this. In fact, "000" is not accepted since it is the dummy number chosen for patients with no emergency contact. Although we acknowledge that this is in fact a flaw, since we did mention that phone number is any number at least 3 digits long, which "000" is, we feel that this is NotInScope. This is because as mentioned by the tester, this is an extreme edge case. In fact, one could search up countries with 3 digit phone numbers, and will learn that less than a handful of countries have three digit phone numbers. For those that do, for example New Zealand, which has some local three digit phone numbers, these numbers do not start with 0. This means that it is more than unlikely that someone's phone number is "000". Hence, we feel that this flaw, although valid, is of extremely low priority and hence NotInScope.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Considering that 000 was suggested to be a dummy value as a phone number, users might use 000 as a dummy value for the emergency contact if they know the emergency contact person but not the emergency contact number. The UG did not state that 000 is already the dummy value for patients with no emergency contact and if users attempt to use 000, the error message suggests that the emergency contact number is not filled, and hence users might be wondering if they had read the UG wrongly or typed something wrong.

I believe that this functionality bug where 000 is expected to be accepted but is not accepted is a valid bug because it is reasonable for the user to use 000 as a dummy value given that it was a suggested dummy value earlier and this input is not considered an extreme behaviour. Otherwise, the UG could also have stated that 000 should not be used as a dummy value. Furthermore, accepting 000 should not take much effort, as you can just use a different dummy value in your implementation.

image.png