nus-pe-script
commented
7 months ago Team's Response
While we acknowledge the tester's suggestion that displaying event information within the list command could be beneficial for users, our team believes it's important to maintain the primary purpose of the list command, which is to provide a concise overview of all expenses, focusing on essential details like description, amount, date, and category. We've designed the viewEvent command specifically for users to delve into expenses associated with a particular event. This division of functionality allows the list command to remain dedicated to offering a comprehensive snapshot of all expenses, irrespective of their associated events, while the viewEvent command serves the specific purpose of exploring expenses within a selected event.
Thus, to keep the list command concise, we decided to omit event details.
In any case, we anticipate that users will not randomly associate expenses with events, as events are intended to organize specific groups of expenses. Consequently, the necessity for users to access information regarding which event an expense belongs to, and subsequently associate it with another event, is unlikely. Our expected use case involves users creating expenses and promptly tagging them to the appropriate event. From that point forward, users can conveniently access and manage expenses associated with a particular event using the viewEvent command.
The tester had the confusion because he/she was making haphazard association between expenses and events for testing purposes, which is highly unlikely in a normal use case scenario. This is thus a feature flaw that causes inconvenience only in very rare situations which should be categorised as severity low.
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: Feature Flaw: Not showing event tagging information under the list command, resulting in user not knowing that expenses can be and are tagged to an event
Using quotes from the team's responses:
"Our expected use case involves users creating expenses and promptly tagging them to the appropriate event". The UG also mentioned in the event command that it is to be used in conjunction with addExEv to add expenses to the event.
My interpretation of this is that since I am expected to tag the expense to the relevant event in a normal use case, I should normally expect that there IS an association between the expense and event. This seemingly contradicts the team's subsequent argument that I was "making haphazard association between expenses and events... which is highly unlikely in a normal use case scenario".
"In any case, we anticipate that users will not randomly associate expenses with events" - What if the user wants to check if he/she made a mistake, becuase mistakes do happen.
"Consequently, the necessity for users to access information regarding which event an expense belongs to, and subsequently associate it with another event, is unlikely" - I disagree. I would consider a user wanting to check if a certain expense has been associated with an event before (or to fix a wrongful association) an appropriate and normal use case scenario. I would also argue that this scenario happens more often than just "very rarely".
"We've designed the viewEvent command specifically for users to delve into expenses associated with a particular event" - The summarise /c command also allow users to view expenses associated with a particular category, but the list command also shows the associated category of each expense. So I don't get why the same is not extended to events.
"Primary purpose of the list command, which is to provide a concise overview of all expenses, focusing on essential details" - I would consider information about each expense tagged to an event essential and can be done in a concise manner (naming the event it is tagged to), just like how the team did with the categories. Without event tagging information in the overview of the list output, I will have to pour through all the events using viewEvent /i and manually track which expenses are associated and not, and to check if I have made any mistakes. This creates inconvenience on the occasional need to do it, which may happen more than just "very rarely". Furthermore, the significance of this inconvenice introduces the mistake of unknowingly reassigning the expense to another event (original bug report) or make the user choose to use the categories functionality in place of the event one, reducing the usefulness of the event feature.
Hence, combining both occasional (more than rare) inconvenience and the implication of reduction of usefulness to addressing abovementioned use case scenario, I would maintain the severity of Medium for this Feature Flaw.
Throughout the testing, I did not know that the expenses can belong and only belong to one event only, until I played around with the addexev command.
I believe the inclusion of whether the expenses belong to any event is important, especially when there is now suddenly a "expense moved to another event" message.
It can be included after the category part of the list command entries (and esp since they are already tagged to the category, i don't see why they can't also be tagged to an event)