nus-pe-bot
commented
2 years ago Team's Response
Allowing duplicate clients was an intended behaviour, because it will be impossible to check whether two clients are the same person. For example, two clients from the same company may provide the same email and address, but use different phone numbers, we cannot just assume people with the same contact details are the same person. In this case, the two of them may want the seller to provide order details separately for their company's use.
As a result, we decided to allow duplicate clients. However, we forgot to change the user guide after changing the code, so we will accept this as a documentation bug. It has low severity because as stated in our ug, an "error message will be displayed", so the user will assume that duplicate clients cannot be added. Even they try to add duplicate clients, our app won't stop them from doing this, as expected.
Items for the Tester to Verify
:question: Issue type
Team chose [type.DocumentationBug]
Originally [type.FeatureFlaw]
- [x] I disagree
Reason for disagreement: I disagree. If that is the case, almost any other bugs can be classified as a documentation bug then.
This should remain as a feature flaw because I believe the choice of design, even if specified by the team as intended, is flawed. The choice to enable duplicate clients is in itself a faulty one. As an online seller (target audience specified by the team), it is not uncommon to be adding 10s of 100s of orders from new clients every single day. Hence you can imagine it is very easy to accidentally add an existing client with the exact same parameters if we are not careful, and in the case that we do use this application to order from our suppliers using the orders from the customers, we would have unnecessarily ordered multiple duplicate orders due to the application, causing real world complications and cost.
A workaround for cautious users whom want to avoid duplication would be to execute find first before adding, and that is just another unnecessary step you do not want your users to have to go through since duplicate detection is not added to the application.
Concerning the case that was raised,
"For example, two clients from the same company may provide the same email and address, but use different phone numbers, we cannot just assume people with the same contact details are the same person. In this case, the two of them may want the seller to provide order details separately for their company's use."
Even in this case, they are likely to have different names and different orders as well, thus the argument for why there cannot be duplicate order checks fails here. A suggestion can be to check for duplication using name, phone and email comparisons. Even if two people have the same phone number and same email because they are using their company contact details, they are likely to have different names as well. Even if we do not restrict adding duplicate clients, there should be some warning or message to inform the users that there is a near match case and they should
This duplicate detection is especially important in an application like this that handles a lot of orders everyday, and the lack of such functionality can be especially costly to the users, whether it be time and effort since they have to find every time before they add a new client or just straight up incurring financial losses because of additional duplicate orders. Either way it is not ideal and this is considered a major oversight by the team.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: I quote my explanation of why this should be a feature flaw rather than a documentation bug.
"I disagree. If that is the case, almost any other bugs can be classified as a documentation bug then.
This should remain as a feature flaw because I believe the choice of design, even if specified by the team as intended, is flawed. The choice to enable duplicate clients is in itself a faulty one. As an online seller (target audience specified by the team), it is not uncommon to be adding 10s of 100s of orders from new clients every single day. Hence you can imagine it is very easy to accidentally add an existing client with the exact same parameters if we are not careful, and in the case that we do use this application to order from our suppliers using the orders from the customers, we would have unnecessarily ordered multiple duplicate orders due to the application, causing real world complications and cost.
A workaround for cautious users whom want to avoid duplication would be to execute find first before adding, and that is just another unnecessary step you do not want your users to have to go through since duplicate detection is not added to the application.
Concerning the case that was raised,
"For example, two clients from the same company may provide the same email and address, but use different phone numbers, we cannot just assume people with the same contact details are the same person. In this case, the two of them may want the seller to provide order details separately for their company's use."
Even in this case, they are likely to have different names and different orders as well, thus the argument for why there cannot be duplicate order checks fails here. A suggestion can be to check for duplication using name, phone and email comparisons. Even if two people have the same phone number and same email because they are using their company contact details, they are likely to have different names as well. Even if we do not restrict adding duplicate clients, there should be some warning or message to inform the users that there is a near match case and they should
This duplicate detection is especially important in an application like this that handles a lot of orders everyday, and the lack of such functionality can be especially costly to the users, whether it be time and effort since they have to find every time before they add a new client or just straight up incurring financial losses because of additional duplicate orders. Either way it is not ideal and this is considered a major oversight by the team."
Though the team argue that this should be a low severity due to it being a documentation bug. Since I stand my ground that this is indeed a feature flaw instead, I will argue from the point of view of the severity of this feature flaw.
In fact, I would like to raise my severity to High instead of Medium.
In the CS2103T website (screenshot below), it is mentioned that High severity bugs are "A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.". I will argue that this lack of duplicate detection feature actually makes the application unusable for most busy online sellers with high volumes of clients and orders. They simply do not have time for a product that does not do a minimum of checking for duplicates in their systems. In that case, there will be no difference to using an excel to track the orders rather than this product. And using this product can be even costlier since they likely have to spend time and effort to learn, and even money if the team decides to commercialize it. I will argue that using such systems usually comes with some expectation that there is added functionality to help the users with their tasks, and duplicate detection is a minimum in this scenario of online sellers, thus this system is almost unusable for most online sellers with no value provided. (A whole feature/functionality missing essentially)
As per title, able to add the same client with the same exact name, phone number, email, address and orders.
Use case: As an online seller, I would want the system to help me with avoiding adding duplicate clients as I may have many clients and can accidentally add the client in multiple times. Adding in multiple duplicate customers can cause me to overorder my products or mess up my reports.