How should I determine whether to use Response.NotInScope or Severity.Low?

[RunjiaChen]

My feature enables someone to open a new window from the GUI, however, since the new window does not close by itself, the user can deliberately sabotage the application and make it lag my opening multiple tabs all at once. In my UG, I have stated explicitly that users have to close the window

I have actually provided a reminder to the user to close the window(albeit in a less imperative way, using the word "may" instead of "must")

Right now, the tester assigned a Severity.High response, as he states that it can cause lag.

May I ask if its valid? He was not actually able to cause lag to the system, as he simply stated that the hypothetically it can cause lag.

In the case that it's a valid issue, would be it be more appropriate to lower the severity or go for Response.NotInScope?

For the case of Response.NotInScope, there has been reminders for users to close the window once the function has completed execution, as stated in the evidence above.

For the case of lower severity, the user can simply close the window, and its very rare for users to open so many windows at a time without closing it.

[aureliony]

I would say it depends on the purpose of the window. If creating many windows is a beneficial feature to the user (e.g. for multitasking), it would affect many users and I'd consider it high or medium. On the other hand, if creating many windows is not useful to users, and it is relatively "difficult" to create so many windows, then only a very small percentage of users would have this issue, so it can be considered Low. If you can argue that the bug is due to a limitation of JavaFX or the operating system, making it impossible to fix from the developer's pov, then it's NotInScope.

[damithc]

@RunjiaChen feel free to discuss this here and get opinions from other classmates. I teaching team will add our inputs if necessary, but the teaching team will not give decisions on specific bugs during this phase, as we do not want to pre-empt the decisions testers and the dev team need to make during the first three phases of the PE. Only if the tester and the dev team can't agree on a bug, the teaching team will make a decision in the last phase of the PE.

[RunjiaChen]

@aureliony hmm, my feature is to make adding contacts easier. You can create many windows, but the UG asks the user to close the window once they have added the contacts, does this fulfil the first condition of notInScope?

I actually tried to create 1000 windows just to stress test the application, but there was no lag observed, so can it be counted as a bug? (Are "hypothetical" bugs considered bugs to begin with?"

[itstrueitstrueitsrealitsreal]

https://github.com/nus-cs2103-AY2223S1/pe-dev-response/issues/4146 My team had a similar issue, and we took this as a precedent for it.

Our line of argument centered around how it is rare for a user to open multiple instances of the application, how the application still retains the latest changes made to the application, which should be the expected behaviour.

Failing that, arguing it as a low severity documentation bug is reasonable.

[RunjiaChen]

@itstrueitstrueitsrealitsreal, thank you for your input! Can I ask if your feature is actually a popup window as well? For your issue, it seems that the tester tried to open 2 instances of the application at once. My feature is a popup window from the application (like the help window), the user can open multiple popup windows at once. The popup windows do not interact with the data of the application in any way. Do you think I will be able to use a similar argument as your response? Thank you!

[itstrueitstrueitsrealitsreal]

Nah, mine was a bug reported about how multiple instances of the app might be used, leading to one instance potentially overwriting the data of the other instance.

Your case seems like deliberate sabotage on the user's part though...

[RunjiaChen]

@damithc Hello Prof, may I double check regarding the definition of a bug? Because in this case, the tester was not able cause lag within the application (He made the claim that it can cause lag). Similarly, if AB3 were to start lagging after adding (say a few million contacts), is it still the fault of the developer?

[damithc]

@damithc Hello Prof, may I double check regarding the definition of a bug? Because in this case, the tester was not able cause lag within the application (He made the claim that it can cause lag). Similarly, if AB3 were to start lagging after adding (say a few million contacts), is it still the fault of the developer?

@RunjiaChen It is not just a simple yes or no question (such as 'is it the fault of the developer?'). Rather, it is a matter of figuring out the suitable type, severity, and response labels. Those choices depend on the possibility/probability/frequency of the said problem happening, the damage it can cause, etc. My comment here is somewhat related -- it tells you what kind of questions to ask yourself when dealing with a bug report.

For example, a possible question related to your case is "Is it be better if the window auto-closes?"