kevinputera / pe

0 stars 0 forks source link

Calorie goal indicator value overflow #1

Open kevinputera opened 4 years ago

kevinputera commented 4 years ago

Screenshot 2020-04-17 at 2.31.04 PM.png

Please take a look at the image provided. If the daily consumption of calorie exceeds x + 2147483647, where x is the calorie goal, the numbers won't be synced up anymore

nus-pe-bot commented 4 years ago

Team's Response

Hi there.

A normal user would not consume so many calories in a single day that would result in this large value. Even competitor eaters and bodybuilders, etc eat at most 20-30k calories a day. Therefore, it is not possible for a normal user to consume so many calories in a single day.

To put into perspective the number of calories that you have entered, (approx. 10,000,000,000), a single McSpicy is about 528 calories. That means that a user who consumed 10,000,000,000 calories in a single day consumed 18939394 McSpicy burgers, which means eating 219 McSpicy burgers in a second, since there are only 86400 seconds in a day.

If we consider the maximum value of 2147483647 before the goal GUI no longer gets updated, that is equivalent to 4067204 McSpicy burgers and 47 McSpicy burgers in a second. As you can see, even the current maximum value is already very liberal and hence we do not expect users to cross it.

This is why we do not reflect updates to the exceeded calories after a certain point, in this case, as you mentioned. However, if a user really wants to see this information, it is still reflected in the graph. As such, functionality is not affected.

Therefore, we are labelling this bug as out of scope because our team is not expected to be handling such possibilities.

Cheers.

Severity (if any): low because this unlikely affects normal operation (if any)/brings minor inconvenience (if any)/affects a very minute group of users (if any). Note that this is explained despite us marking it as not in scope it, as the Github forum requires us to explain any changes to severity.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: > A normal user would not consume so many calories in a single day that would result in this large value. Even competitor eaters and bodybuilders, etc eat at most 20-30k calories a day. Therefore, it is not possible for a normal user to consume so many calories in a single day.

To put into perspective the number of calories that you have entered, (approx. 10,000,000,000), a single McSpicy is about 528 calories. That means that a user who consumed 10,000,000,000 calories in a single day consumed 18939394 McSpicy burgers, which means eating 219 McSpicy burgers in a second, since there are only 86400 seconds in a day.

If we consider the maximum value of 2147483647 before the goal GUI no longer gets updated, that is equivalent to 4067204 McSpicy burgers and 47 McSpicy burgers in a second. As you can see, even the current maximum value is already very liberal and hence we do not expect users to cross it.

Although I agree with you that it's unnatural to eat so many calories in a single day, I must say that we, as software engineers, should prevent such unnatural scenarios from happening in the first place. Even if we say that such consumption is not possible in real life, it is possible to use your app as such.

Another thing to consider: If we follow by the 20k-30k calorie/day figure you provided, why does your team allow 99999 as the input for a single food's calorie. Isn't it impossible in real life? In addition, why does your team allow 99999 as the input for the number of portions consumed for a single food. Isn't this also impossible in real life?

It was these huge numbers that allowed me to consume so much calorie in your app in the first place!

My point is that the team should actually consider all these cases when designing the app. I don't believe this bug is out of scope, as it relates to how your app's constraints are designed. This is very important.


This is why we do not reflect updates to the exceeded calories after a certain point, in this case, as you mentioned. However, if a user really wants to see this information, it is still reflected in the graph. As such, functionality is not affected.

It sounds weird to me that you're saying that it's fine for the two displyas to not be synced. I believe it's the developer's responsibility to ensure that two displays of the same data must always be synced! I believe that functionality is heavily affected; how would a user know which display is the correct one? he/she can of course calculate himself/herself, but doesn't that defeat the purpose of using your app in the first place (to remove manual labor of calculating)?


:question: Issue severity

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

Reason for disagreement: I think it's true that my initial report is inacurrate in a way that this might not be a severity.High bug. However, I think that this bug is at least severity.Medium.

As much as it's true that this bug won't affect the average user, I think that if this bug occurs, it will severly hinder usability.