search

OVReader / pe

0 stars 0 forks source link

Multiple users in Upcycle #4

Open OVReader opened 1 year ago

OVReader commented 1 year ago

The entire application uses the term users. As shown in following pictures, by using the term add user, it is implying that Upcycle is a multi-user product which is a violation of project constraints.

image.png

Similarly for other commands:

image.png

Due to it being a violation of project constraints, severity will be set to high. If the term user is replaced with other terms like client, it would not have resulted in any ambiguity on multi/single user use.

nus-pe-script commented 1 year ago

Team's Response

Thanks for raising your issue!

This app is designed to use by only one user, which is the student/manager, who own a rental business not for all users aka customers of this business. And during the week 6 tutorial, we even asked our TA and professor if our app violates the constraints or not, and the answer is no. add-user is the command that the manager use to add customer to his/her business, so we strongly believe that we do not violate any constraint of tp

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Background information (provided due to discrepancy between DG target user and UG target user)

To begin, this bug is reported during PE Phase 1 - Part I where testers focus lies on UG and manual testing section of DG as mentioned in module website as shown below.

image.png

"target users" are interpreted as "rental business managers who keep track of all of their customers" as stated in the introduction of UG as shown in picture below.

Since the teaching team has confirmed that there is no violation, the severity of the bug reported should no longer be High.

However, the main issue for this bug lies in the product having multiple entities with the term "users". As previously explained, there are multiple "users" in this product. (Note: Not talking about multi-user). When using the term "user", it can bring in a lot of confusion and ambiguity. "User" can be interpreted as the following:

(1) Rental manager who are using the product

(2) Customers of rental manager stated by dev team "all users aka customers of this business" and "add-user is the command that the manager use to add customer". (Not sure the rationale for naming customers as "users" when they do not even interact with the product)

When testing the product, (2) was not explicitly stated and it is very natural to assume that "users" refer to (1), well since they are using the product. With "users" being interpreted as (1), features like add user and transaction between "users" will make the product look like multi-user product, although it is not intended as stated by dev team.

The main problem does not lie on the product being multi-user but rather the ambiguity caused by using the term "users" for (2) which is considered part of the product's feature. This issue becomes more prominent when using the transaction feature.

image.png

As shown in picture above, a transaction requires lender and borrower. A lender must own an item before it can be rented as shown in picture below.

image.png

However, here comes the following problems/questions from the POV of the end-user who are (1) using this product:

  1. If there is confusion between (1) and (2), "Why are my customers now the lenders for the items rented out? If that is the case, are they still considered "customers"?"

  2. "Why is there a need to input my name for USERNAME to add items when I am the only borrower"

  3. If end-user still thinks that "users" refer to (1), "Why is there multiple users to be added when I am the only one using the product/renting items out"

The above doubts/questions mentioned has led to confusion on how the features are supposed to be used which is caused by the ambiguity of the term "user". Hence, it is arguable that this is a valid FeatureFlaw bug that should be accepted. However, with the confirmation by the teaming team that no project restrictions are violated, the severity shall be revised to Medium instead. Medium severity should be appropriate since the product can still be used although with occasional inconvenience.