spinoandraptos / pe

0 stars 0 forks source link

Program crashes on inputting 0000 as the year for entries #2

Open spinoandraptos opened 8 months ago

spinoandraptos commented 8 months ago

image.png

This is a serious issue as the erroneous input of year 0000, in the event of a typo or deliberate sabotage, is not handled at all, causing a complete app crash. This can be detrimental to the experience of the clerk using the app and may also lead to other potential unforeseen harmful consequences.

soc-pe-bot commented 8 months ago

Team's Response

Thank you for finding this bug.
You are right, the program should have handled this more gracefully using exceptions.

But fret not, all previous details would have been saved, so no data is lost.
The clerk just has to restart the program.

It may confuse the clerk, but I wouldn't call it "detrimental", as no data is lost, and the clerk has nothing to lose. (At most 5 seconds of his time)
And since clerk knows that he has input 0000, he would likely not do that again, since it would mean he would have to restart the program.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: image.png


image.png


The UG did not specify it is not supported, and the program does not fail gracefully, hence the requirements for Not In Scope are not met here and should not be used.


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** ![image.png](https://raw.githubusercontent.com/spinoandraptos/pe/main/files/1a29fb07-ecd2-4645-b1b9-16d57044c416.png) ----- When the program crashes, I believe it is reasonable to say that the program will be unusable after the crash before restarting. All other severity levels state that the program may still be used after the bug has occurred, hence a program crash bug can only be parked under the severity.high category.