samuelfangjw / pe

0 stars 0 forks source link

Inconvenient to add items of the same type #2

Open samuelfangjw opened 3 years ago

samuelfangjw commented 3 years ago

Storemando does not allow items of the same name and location to be added.

However, if I buy 2 items on separate days and add them to my store with the same expiry date, i would expect them to be grouped together. Adding an item that is similar should instead increase the quantity available in the store as the current implementation unnecessarily inconveniences the user. The user should not have to remember what item he already has in the app and update it whenever he purchases more of the same item.

nus-pe-bot commented 3 years ago

Team's Response

Thank you for your suggestion.

Severity: We are changing the severity to VeryLow because we have the 'Edit' feature to modify the quantity of an item. The functionality of our product is not compromised.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: The team did not explain why this is NotInScope. I would argue that it is in scope since the add command is part of their feature set for v1.4, and adding an item that already exists seems like a very common use case, especially when purchasing perishable items that expire quickly.

In addition, the amount of implementation effort required to add such a feature is trivial, since the add command already checks for duplicates. In the same if block, one can retrieve the item and update the quantity, then return the command result.


:question: Issue severity

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

Reason for disagreement: Thank you for your response, however I disagree with the severity level chosen.

Firstly, this is a feature flaw not a functionality bug. From the module website, a feature flaw Some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. The team argues that The functionality of our product is not compromised, but whether or not the feature works is not relevant here (as it is not a functionality bug). Instead, the issue is whether or not the feature is less useful for the target audience because of the flaw mentioned.

By definition, a very low severity bug is A flaw that is purely cosmetic and does not affect usage e.g., a typo/spacing/layout/color/font issues in the docs or the UI that doesn't affect usage.. This does not seem to fit the issue described, where users are inconvenienced because a feature that they use regularly (adding an item that already exists) does not work as expected (not on the same level as a purely cosmetic bug that does not affect usage). Even though users can edit the item, they are inconvenienced when doing so. For example,

A user buys an item, but is unsure whether they already have the same item in their inventory.

Expected implementation: A user adds an item, and items are grouped together.

Actual (current implementation): User searches for the item by name, realises they have the same item, identifies the index and types the command to edit the item.

As shown, the current implementation is not ideal and unnecessarily inconveniences the user.

I believe the current severity of medium is appropriate. From the module website, a medium severity bug is A flaw that causes occasional inconvenience to some users but they can continue to use the product. In this case, the feature flaw causes occasional inconvenience to users every time they buy a new item, but they can still continue to use the application.