nus-pe-script
commented
3 days ago Team's Response
Thanks for raising this issue. However, we will be labelling this as not in scope. Firstly, it's common practice in the industry to provide a summary of errors rather than detailing every single error. For example, in systems like iCloud Drive, the reason for file upload failure is not even shown. This approach is still widely accepted as it avoids overwhelming the user by displaying EVERY single error line which in turn will clutter the user interface and lead to a poor user experience. Providing a summary of the key areas where errors occurred is a balanced approach that maintains usability while still informing the user of issues. Our team believe that we did the sensible and sufficient thing where we provide the correct format of student's data as an example and the ranges of input that the student's data should stay within.
Secondly, the team understands that in the UG, for errors in CSV file, the line with the error is printed and shown to the user. For clarity, the error message only display the first error the parser encounters and stops parsing. In the case for JSON and TXT files, the team decided that in view of a tight deadline, a suitable error message will be displayed instead of allowing the program to crash. Thus, we labelled this as not in scope.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:**   As you can see from the points highlighted in the above screenshot, the team's response mentioned that "providing a summary of the key areas where errors occurred" is a balanced approach. However, the team does not tell anything about where the errors occurred. Simply mentioning how many students' data was corrupted (a summary of the errors) or simply indicating which lines were causing the errors (again, a summary of the key areas where the errors occurred, don't even have to tell which part of the syntax caused the error) would have helped serve their case and their reasoning would be sound. However, the team did neither of the two, they simply tell that the data file has invalid data and provide the correct syntax to input. This does not talk about the extent of errors or narrow down the errors even by a bit, there is no "summary" of the errors in this case. It simply mentions that there is "invalid data", not even what makes this data "invalid". For this reason, I believe that the severity should remain medium as it is a flaw which causes occasional inconvenience to users. It might pop up quite frequently since the app allows users to use file inputs for students' data, and any incorrect formatting by first time users would cause this error message to pop up and the user might have no idea how to go about solving this.  An additional detail missing in the error message is that it talks about the range for the gpa and preferences fields but provides no information about the correct format for the id field
I changed the gpa of the first person in the test.txt list to an invalid value. I observed that the program pointed out that there is an error with the contents of the file. However, it did not mention how many students' (or fields') data was corrupted. It did not mention which field was corrupted as well. In cases of large datasets, the program not pointing out to the user where the error is, can cause much inconvenience to the user since they have to find out the source of the error themselves by manually going through each student and field. A more specific error message would be useful