search

MarcusTXK / pe

0 stars 0 forks source link

Unable to add friend of same name #8

Open MarcusTXK opened 3 years ago

MarcusTXK commented 3 years ago

Expected:

Actual:

Steps to reproduce:

  1. Input person David Li /create p:91119111 e:notor@notor.com t:Loves Dancing g:1 with the default data loaded.

Screenshots:

image.png

nus-pe-bot commented 3 years ago

Team's Response

For most people, you would not deliberately save two contacts with the exact same name, because it is easy to confuse yourself. Most people will include additional details to differentiate them within the name itself to avoid confusion. Hence to prevent confusion we have prevented saving contacts with the same name.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Considering the purpose of their product, which is to help mentors manage large groups of mentees easier, it is likely that this problem might appear for some of the users (the larger the group they are managing with the application, the higher the probability of this occurring), and will cause inconvenience as the product will no longer be able to be used/the user must think of creative ways to add both of their mentees with the same names in (which may cause further problems, such as the stored names now differing from the official registered name in e.g. Luminus, making harder for the mentor to manage the mentees). The team themselves acknowledge this in their response by stating that "most people" will not face this problem, but are unable to say it is the case for everyone as is it a perfectly valid scenario, albeit more uncommon.

Restricting the creation of users solely based on name adds unnecessary and potential problematic limits to the application for their target users. Two individuals with different phone numbers, emails, tags, notes and who belong in different groups should not be considered the same person just because of their name. I feel this is unreasonable and there should be a better way in place for the app to differentiate individuals rather than based solely on their names. (eg. Using unique fields such as email and phone numbers (or perhaps by comparing all of the fields of a person) could have been used instead to differentiate individuals.)

Imagine if a module/tutorial rejects a student from enrolling due to another student sharing the same name already being present in a module/tutorial. This would be highly unfair and unrealistic in the real world. Hence this is indeed a valid feature flaw of the product, as it causes inconvenience to their target user.

:question: Issue severity

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

Reason for disagreement: In the rebuttal stated, the team themselves acknowledges that "most people" (and not all) will not save two contacts with the same name and I do not disagree that this is a less common problem. However, this also means that the team acknowledges that some users will try to save two contacts with the same name. While it is less common, I have had friends with the exact same name, so it is a valid scenario. This falls in line with the definition of Medium severity, where it is a flaw that causes occasional inconvenience to some users but they can continue to use the product (perhaps by finding some weird workaround).

Considering the purpose of their product, which is to help mentors manage large groups of mentees easier, it is likely that this problem might appear for some of the users (the larger the group they are managing with the application, the higher the probability of this occurring), and will cause inconvenience as the product will no longer be able to be used/the user must think of creative ways to add both of their mentees with the same names in (which may cause further problems, such as the stored names now differing from the official registered name in e.g. Luminus, making harder for the mentor to manage the mentees).

Restricting the creation of users solely based on name adds unnecessary and potential problematic limits to the application for their target users. Two individuals with different phone numbers, emails, tags, notes and who belong in different groups should not be considered the same person just because of their name. I feel this is unreasonable and there should be a better way in place for the app to differentiate individuals rather than based solely on their names. (eg. Using unique fields such as email and phone numbers (or perhaps by comparing all of the fields of a person) could have been used instead to differentiate individuals.)

Imagine if a module/tutorial rejects a student from enrolling due to another student sharing the same name already being present in a module/tutorial. This would be highly unfair, unrealistic and inconvenient in the real world. As such this is a valid feature flaw and should be considered as a Medium severity.