nus-pe-bot
commented
2 years ago Team's Response
While we understand that it's likely they are the same contact, we currently have duplication detection for contacts by comparing their names. If we were to follow the sliding slope argument that we should look for minor mistakes that users can make like additional spaces or capitalizations, where would be no end to it and we would say is definitely not a bug within ANY contact management application.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Indeed, the application does have duplication detection based on EXACT name matches. However, this is half-baked duplicate detection, according to 2103 guidelines.
At the very least, the application should give the user a warning that extremely similar names (differing due to whitespaces or capitalization) have been encountered. Simply doing duplicate detection with exact name matches, and not accounting for capitalized letters or whitespaces, is a half-baked measure, and might result in user errors. This thus qualifies as a type.FeatureFlaw bug.
For instance, observe the following case (Entry 8 and 9 have the exact same fields, apart from John Doe having an extra whitespace in the index 9 entry) :
A user might want to edit the address and email of John Doe, but might edit the address of entry 8 and the email of entry 9. When the user later retrieves John Doe's information, he might get entry 8, which does not have the updated email address. Note how half-baked duplicate detection is a severe bug here.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: Half-baked duplicate detection will cause major inconvenience if the user were to add two highly similar names, and not realise that they have made such an error.
For instance, observe the following case (Entry 8 and 9 have the exact same fields, apart from John Doe having an extra whitespace in the index 9 entry) :
A user might want to edit the address and email of John Doe, but might edit the address of entry 8 and the email of entry 9. When the user later retrieves John Doe's information, he might get entry 8, which does not have the updated email address. Note how half-baked duplicate detection is a severe bug here, as the user might never realise that he has made such an error of having two instances of John Doe, when his contact list gets very large in the future.
This is not a rare occurrence, as it is not uncommon to accidentally include an extra whitespace or incorrect capitalization while typing fast.
It is possible to add persons with the exact same fields, but slightly different names. e.g. John Doe (index 8), John Doe (two spaces - index 9), john doe (small letters - index10)
It is highly likely that these are the same contacts, since all other fields are the same, and the names are same content-wise. Some elementary duplicate detection should have been included. The same problem exists for tasks titles, but it is not so much of a priority/issue for the context of tasks.