ailanthustng / pe

0 stars 0 forks source link

[DG] Slight inaccuracy with on of the NFRs. #22

Open ailanthustng opened 4 years ago

ailanthustng commented 4 years ago

Screenshot 2020-04-17 at 15.33.09.png

Here it says "... up to 1000 tasks without a notieable sluggishness...". However, through my testing, there were only 20 odd tasks, yet it still had moments of laggy-ness and stuttering, especially when listing all or deleteing a task.

nus-pe-bot commented 4 years ago

Team's Response

Although delete and list commands are slightly slower to the rest of the (instantaneous) commands, these commands are still considered fast. The lag faced by the tester could be due to the tester's own hardware. As such, this is not within the scope of the application.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: These commands are considered fast in comparison to the other commands in the application. But based on itself, it's not fast, in fact, there was at least a second or two delay after each delete or list command.

I feel that an average student might have at least 20 tasks at any one time in a semester, and having this delay would greatly affect the user experience of the application. If 20 tasks can already cause a slight delay, what sort of delay can 100, or even 1000 tasks cause? (Even though 100 - 1000 is a rather unlikely number.)

Why I feel that this is a documentation bug is because the team should have reduced this figure and kept it realistic, and also to inform users/developers that there might be potential stutter if too many tasks are stored, after all its a NFR.

In addition, I feel that it's not right to simply blame the "testers" (in this case me) or "users" hardware as a problem to this lag. I'm using a 2018 MacBookPro of considerable specs. Since this is an application targetted at students, I believe majority of students will be using a spec-equivalent laptop. As such, they would also be likely to face this lag.

All in all, I'm not attacking the application. There's nothing wrong with the lag. What I'm doing here is that i'm informing the team that 20-odd tasks can cause that slight lag, hence a flaw in their documentation because I'm sure that 1000 tasks would cause an even greater lag. As such my suggestion is to reduce it to a more realistic figure.

Since this is part of the NFR, and the NFR is part of the DG. It is very much in the scope.

==============================================================================

Beyond just this problem, I want to add my two cents. Forgetting that I myself is a programmer, or a tester. Just looking that I'm a User and I faced this lag. I decide to give some feedback to the team to tell them that I experience this. Yet the response I get back is that the fault lies with "my hardware". This is definitely not right. How can one blame the user? Shouldn't the developer accept that this might be a mistake on their side?

Conclusion: the developer should not just brush away a problem/suggestion or even blame the user's hardware.


:question: Issue severity

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

Reason for disagreement: [replace this with your explanation]