nus-se-script
commented
1 week ago Team's Response
The behavior observed by the tester is expected and correct from the user's point of view. The developing team has programmed it such that there would be flexibility for users. The ability to add an expense with a value of $0 is intentional, as there are legitimate use cases for this functionality. Users may wish to add a placeholder event where no expense has been incurred yet but may be updated later (e.g., a planned purchase or future reimbursement). They may also want to record non-monetary transactions such as gifts received, promo discounts, or fully reimbursed items, which are still relevant for tracking purposes.
Moreover, it aligns with the user guide which specifies that the add-expense command requires AMOUNT to be a valid integer or double but does not restrict the value from being $0.
This ensures consistency with the system's documentation and expected behavior.
From the user experience consideration, preventing $0 inputs could limit the system's flexibility and inconvenience users who wish to record placeholder events or non-monetary transactions. From a user's perspective, allowing $0 inputs enhances usability rather than detracts from it. In conclusion, what the tester identified as a bug is actually expected behavior and serves valid use cases. Therefore, this issue is rejected as it aligns with the intended design of the system.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I understand that the dev team may have intentionally allowed $0 as a valid input to facilitate scenarios such as "recording placeholder events where no expense has been incurred yet but may be updated later" or "recording non-monetary transactions such as gifts received, promo discounts, or fully reimbursed items."
However, as a user and tester, I strongly believe this behaviour should still be classified as a bug. Here are my reasons:
1. Misalignment with the Product's Purpose The product is named SpendSwift. As a user/tester, the reasonable inference based on the name is that the application is centered around tracking actual expenditures to help users manage their spending effectively. The concept of adding $0 as an expense contradicts this core idea, as no money is spent, thereby not contributing to the application's primary purpose of budget tracking.
2. Lack of Features to Support Intended Use Cases If the development team’s intention is to allow users to "record placeholder events where no expense has been incurred yet but may be updated later," the application should incorporate features such as associating a date variable with these entries. This would allow users to differentiate between planned future expenditures and actual spending, enhancing the visualization and functionality for users. Without this feature, the functionality of adding $0 as an expense feels incomplete and unintuitive.
3. No Mention of Non-Monetary Transactions in UG The development team also mentions that users can record "non-monetary transactions," but this functionality is not explicitly documented in the User Guide. As a tester/user, I expect the User Guide to clearly communicate this feature if it is indeed part of the application's intended behavior. The lack of documentation, combined with the app’s description as a "budgeting tool designed for budget-conscious users" where you can "effortlessly track expenses," strongly implies that the tool is meant to track expenditures with amounts greater than $0, where money is actually spent.
4. There is a Simple Fix for Improved User Experience Preventing $0 as an input for the /a flag is a straightforward enhancement that requires minimal development effort. A simple condition to check whether the value of /a is greater than 0 during flag parsing would suffice. This small adjustment would ensure that the app aligns with user expectations of what constitutes an expense
Steps to reproduce Type in the following command: add-expense n/Lunch a/0 c/Food
Expected output There should some kind if error message or warning displayed to the user when adding a expense with amount $0.
Reasoning Since the command is about adding expense, only valid inputs with expenses should be added. $0 is not an expense since nothing is spent hence the command should highlight it to the user.
Actual output The expense is added succesfully.
Screenshot