nus-se-bot
commented
3 years ago Team's Response
First of all, the tester has issued the wrong bug type. According to the tester's description of the 'bug' which states that a certain behaviour is not specified in the user guide, this should be a documentation 'bug' instead of a functionality 'bug'.
Secondly, only the 'list' command has the functionality to display all the modules in all semesters which is stated in our UG. Displaying all the modules in all semesters is not a specified functionality of the 'progress' command according to our UG. Thus the tester should not expect the list of all the modules in all semesters to be displayed when the 'progress' command is executed as it is not an intented functionality of the command. The list of modules display only the modules belonging to the current semester (which is Y1S1) is the intended and correct behaviour of our app as the user is currently in Y1S1 as shown from the screenshots provided by the tester, and hence the modules displayed should only be from Y1S1 when the user is executing any command other than the 'list' command while currently being in Y1S1.
Thirdly, whether the list of modules displayed only contains modules belonging to the current semester or modules from all semesters does not affect the functionality of the 'progress' command in any way since the sole functionality of the 'progress' command is meant to display the user's average CAP required for the user's remaining modules to meet his or her target.
Thus our team believe that this is not a bug.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Thank you for the response.
From what I read from the User Guide, I expected the list would not be changed, because there's nothing to suggest otherwise. This means that the actual behavior differs from User Guide. Hence, it falls under functionality bug.
Note that in the response, the developers acknowledge that the sole functionality of the progress command is to display the user’s average CAP required for the user’s remaining modules to meet his or her target. Therefore, the progress command should not change anything besides the display, but in fact, the progress command also changes the list shown. This contradicts the claimed sole functionality of progress command and therefore the behavior should be documented, which in this case isn't.
:question: Issue type
Team chose [type.DocumentationBug]
Originally [type.FunctionalityBug]
- [x] I disagree
Reason for disagreement: As stated in reasons for disagreement of rejection:
From what I read from the User Guide, I expected the list would not be changed, because there's nothing to suggest otherwise. This means that the actual behavior differs from User Guide. Hence, it falls under functionality bug.
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.Low]
- [x] I disagree
Reason for disagreement: As progress is one of the key features of MyMods, the mentioned case above where the list changes after entering progress command can happen although very rarely and will cause some inconvenience for the user if the user expects for the list to not change. Therefore, it should be correct that this is of severity.Low.
The details of what list will be displayed after entering
progresscommand is never specified in the user guide. I originally expected it to not change the list displayed, but it turns out that you always go back to current semester's list. The behavior is not stated in the user guide and therefore left a bit of confusion.Steps to reproduce:
start y1s1.list(Assuming having other modules in other semester(s) besides y1s1)progressExpected (not changing display list):
Actual (transits back to only modules in current semester, but not specified in user guide):