nus-pe-script
commented
2 years ago Team's Response
In this version we do not support the same student being in multiple mods. Further a person TAing multiple mods and at the same time having a student common is highly unlikely, thus this issue doesn't warrant a high severity.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I don't agree that such a feature is not in scope, as it fundamentally deals with how duplicate students are being validated and checked within the application, which is fundamental and core to the app's use. Just as how the team has implemented and allowed for multiple tags, it could be a minor extension to simply allow a student to e.g. have multiple modules he/she is under.
I believe this in itself is a bug to the team's design on how duplicate student entries are checked for, and as such a feature flaw.
Even if noted by the team that this will be incorporated in the future, any future extensions, fixes, or notice that the team has this under consideration, should at least be noted within the UG/DG given that it can be deemed as a crucial flaw of the application with a severe implication on the usage if the problem does arise (no matter how commonly it occurs) - which is not the case as there is no documentation noted by the team. As such, this feature flaw does not fall under notinscope.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: I do acknowledge the team's justification that the occurrence is not very common!
But I think the severity of the bug should not solely rely on how common it will occur, but should give consideration to how the application behaves when the bug does arise e.g. does the app crash or fail to work? - In this case I have allocated a high severity given as in the event the scenario discussed in the initial bug report does occur, the app would totally fail to allow the TA to record details of the student in both modules, with no other means of circumventing nor documentation by the team, which then goes against the actual value proposition of the app in the first place. As such, I do still think lean towards a high severity given the nature of the bug dealing with a fundamental core design/validity check for duplicacy.
At best, in consideration of the team's view that the frequency is not common, I would think the severity could be brought down to a medium.
The application does not seem to account for keeping information of the same student in multiple modules with the same TA. As seen in the UG, only one module code can be added for a single student, and students cannot be duplicated (i.e. I cannot store two records of the same student in different modules).
If I am the TA of the same student in different modules, I will not be able to conveniently store information about this student.