meowwtama / pe

0 stars 0 forks source link

Does not meet NFR 5, 7 #16

Open meowwtama opened 4 months ago

meowwtama commented 4 months ago

Screenshot 2024-04-19 at 5.29.35 PM.png

Since the application does not automatically close the window opened by the addbystep command, it is reasonable to believe that the continuous pop ups of these windows (say i created 100 contacts details using the addbystep) without closing the windows, will cause lag. In this case, the side windows opened do intefere with the main window and commands will take a long time to process.

soc-se-bot commented 4 months ago

Team's Response

This is a feature flaw, as the window not closing on its own after the user has completed entering his/her details makes it more of a hassle for users, since they need to manually close the window. Thus, I would argue that the feature is not "complete" without the automatic closure of the window.

That being said, we have actually included in our UG how exactly to use it, where "automatically closure" is not expected for our app.

image.png

Given that the addbystep feature is actually supposed to teach users how to properly format the command, it is not likely that the user will continuously rely on the addbystep a few hundred times, as they would have familiarised themselves with the format by then. It is very rare for users to open so many tabs, and leave accidentally leave all of them open. The hypothetical severity should be low.

While opening multiple windows may hypothetically cause lag, I would argue that AB3 is actually not resource intensive, even with multiple windows open. Here is a screenshot of my activity monitor when opening addbystep 100 windows for LookMeUp

image.png

It is very unlikely for a modern day laptop to lag due to too many windows being opened in LookMeUp

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I feel that the bug report should not be rejected, but can be reclassified as NotInScope for consideration in the subsequent iterations. I do not think that this report is entirely incorrect.

Screenshot 2024-04-25 at 11.57.26 PM.png

Let us consider the scenario where the user does not close his monitor after use, and that he is an active user of your application. Since the window does not close automatically, with continuous use of the addbystep function, the number of windows will accumulate and this will go well beyond the 100 windows tested. Thus, it does have the potential to cause lag.

The next assumption stated was users will be using your application is a modern day laptop. What if the user decides to use your application on a very old laptop with an outdated processor? Since the assumption that the user is using a "modern day laptop" is not stated in your UG or DG, we should not make that assumption. Thus, for some users, having many tabs open can cause lag.

Your application may not be resource intensive as per the current iteration, but that does not mean that it won't be in the subsequent iterations with new updates. In the future when your application gets more resource intensive, it will aggravate the potential lag issues. Coupled with the situations I mentioned earlier, the potential for lag will drastically increase and thus violate NFRs 5 and 7.


## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.DocumentationBug`] - [x] I disagree **Reason for disagreement:** This is a documentation bug because in this bug report, I am disagreeing with the NFRs stated in the DG, not the functions provided by your group's application.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** The implications caused by lag (more than 10 minutes) does not just cause minor inconveniences to the user and thus does not qualify for a Low severity. In fact, causing the application to lag (more than 10 minutes) would make the application unusable, thus qualifying for High severity.