blackmirag3 / pe

0 stars 0 forks source link

Inaccurate max limit for expense amount #9

Open blackmirag3 opened 4 months ago

blackmirag3 commented 4 months ago

Screenshot 2024-04-19 at 5.28.29 PM.png

Via manual editing of expenses data file and setting a number above the limit prescribed in UG (1,000,000,000,000.00) , the programme still saves a number higher than 1,000,000,000,000.00. Could the UG be expressing the max limit wrongly?

nus-pe-script commented 4 months ago

Team's Response

Thank you for identifying the discrepancy between the documented upper limit of 1000000000 and the application's actual behavior, which allows for higher input values. While it is indeed an inconsistency that warrants correction, the severity of this issue can be considered low for several reasons.

Firstly, this inconsistency does not directly affect the core functionalities or the operational stability of the application. The application’s ability to handle values larger than 1000000000 without crashing or behaving unpredictably suggests that the system is robust enough to manage these inputs, which mitigates the immediate impact of the error.

Secondly, the nature of this bug suggests that it is unlikely to be encountered by a majority of users under normal usage conditions. The use of values exceeding 1000000000 is not typical for most practical applications, indicating that the frequency of this issue arising during regular use would be relatively low.

Moreover, since the application does handle larger numbers effectively, the primary issue here is aligning the documentation with the application’s capabilities, rather than addressing a functional flaw within the app itself. The correction required is therefore limited to updating the documentation to reflect the actual behavior of the application or adjusting the application to enforce the documented limit.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: While the inaccurate UG description may not be severe (which you guys argued well and I agree with!), the feature which the bug pertains to is well within the scope of the project. The UG ought to accurately align with the programme, as you guys mentioned, and in fact forms the premise of the bug. While slight, this is clearly an error in documentation that is relevant as of v2.1.

Hence I feel that the bug is still within scope and is something you guys should have accounted for.

Course website: response.NotInScope: It is a valid issue but not something the team should be penalized for e.g., it was not related to features delivered in v2.1 or lower priority than the work already doen in v2.1.


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]