search

spinoandraptos / pe

0 stars 0 forks source link

Unable to support large number of data entries (even when <1000) #8

Open spinoandraptos opened 10 months ago

spinoandraptos commented 10 months ago

image.png

When data txt file is changed directly to include up to 999 entries manually, possible due to new data results that are sent in by reserve rangers, the program fails to read in all the entries and fails to start up. This is a very serious problem as once again wildlife data is often in large entry sizes, and the program needs to be able to support that for it to have effective scientific value.

This is especially when the NFR of DG says the app should hold easily hold up to 1000 entries.

image.png

soc-pe-bot commented 10 months ago

Team's Response

Thank you for bringing this to our attention.
The error you have encountered is because the WildWatch.txt is missing a whitespace after the last "/", for entries without a REMARK field.
This occurred because the tester altered the saved text file manually, without realising that whitespace has to be appended after "/" at the end.
This would not happen in proper use of our program, where the user will input the entries via interaction with CLI, and not directly altering the saved file.

As of our current iteration, we do not encourage manual alteration of the saved file.

But then again, the program should have gracefully ended, with the corrupt file message, instead of ending abruptly.
We need to thus improve on the exception handling of the FileStringParser class.

image.png

Please test using this saved file that indeed has more than 1000 entries.
WildWatch.txt

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: image.png

image.png

Thanks to the dev team for identifying the bug does not arise from the number of entries but from the wrong text input format in the data text file, really appreciate that.

Nonetheless, the UG did not specify that manual alteration of the saved file is disallowed, and in addition, the program does not fail gracefully. Hence, the conditions for not in scope are not met, and should not be used.

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :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/d06c0e96-d524-4efa-9c7c-af8eab4a8be6.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. And in this event, the program will truly be unusable even on restarting as it will keep crashing on startup before the data text file is corrected.