UG allows a phone number that app doesn't

[trpmy]

This phone number 98+765432 satisfies the logical constraints of the UG:

However, the app forbids it. This can be fixed both as a functionality bug or documentation bug, depending on preference. I think the code actually doesn't support the constraints given in the table, and what you meant to put in the UG was '+ can only be at the start of the phone number', which was a crucial oversight. But on paper, because there is a mismatch between "functionality" and advertised behaviour, I'm putting this nominally as a functionality bug.

ADDITIONALLY, the examples given doesn't do anything to disprove that an infix + wouldn't be allowed.

[nus-se-script]

Team's Response

We lower the severity to low as it is a rare case to have a + in the middle of a phone number.

We justify this as not in scope as it is unlikely for users to encounter this issue.

ADDITIONALLY, this can be easily fixed by mentioning it in the UG, therefore we change it to a documentation bug.

Items for the Tester to Verify

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: >We justify this as not in scope as it is unlikely for users to encounter this issue.

"Unlikely for users to encounter" isn't a valid reason to respond NotInScope.

ADDITIONALLY, this can be easily fixed by mentioning it in the UG

Then there is no reason to delay to a later release, nor should other works take priority over it, and ALSO this UG update was allowed during feature freeze, and the team never made such an update. Altogether, I believe NotInScope is the wrong response.

---

❓ Issue type

Team chose [type.DocumentationBug]
Originally [type.FunctionalityBug]

• I disagree

Reason for disagreement: Consulting the course page:

UG said 98+765432 is allowed (as per constraints). The app doesn't. Behaviour differs. Ergo, functionality bug.

Also, from my original report:

This can be fixed both as a functionality bug or documentation bug, depending on preference. I think the code actually doesn't support the constraints given in the table, and what you meant to put in the UG was '+ can only be at the start of the phone number', which was a crucial oversight. But on paper, because there is a mismatch between "functionality" and advertised behaviour, I'm putting this nominally as a functionality bug.

Because I was sympathetic to the app's behaviour, and because I wanted to give extra justification to make my choice more reasonable. I thought the type would've been somewhat of a non-issue, having assumed the team would be reasonable and sympathetic to not having to make everything technically correct. The team decided that this is a hill they want to die on, so I'm also taking the definition verbatim.

---

❓ Issue severity

Team chose [severity.Low]
Originally [severity.Medium]

• I disagree

Reason for disagreement: [replace this with your explanation]

---