search

ZhangHuafan / pe

0 stars 0 forks source link

Bug: startTime and endTime not within the working hours are accepted #7

Open ZhangHuafan opened 5 years ago

ZhangHuafan commented 5 years ago

This may seriously produce invalid interviewing timeslots. Screen Shot 2019-11-15 at 1.02.24 PM.png Screen Shot 2019-11-15 at 1.03.24 PM.png

nus-pe-bot commented 4 years ago

Team's Response

Dear Tester,

We refer to the user guide under the constriants specified for timeslots:

The start duration and end duration of a s/SLOT must follow these constraints:

A start duration and end duration must be in 24-hour format.

The range of start durations and end durations available for input must be within Working Hours.

The start duration must be earlier than the end duration, and be in increments of duration. The time elapsed from the start duration to end duration must also follow the number of minutes as specified by the value of duration in User Preferences. Otherwise, scheduled data will not be displayed properly in the user interface. See Duration of Timeslot for more details.

We also quote from the user guide under the section "Duration of Timeslot": The indicated timeslots, in adding or importing interviewers/interviewees, has to be one of these unique timeslots and cannot take any other values. Failure to do so will result in an inaccurate display of schedules.

In this case, we do not disallow the adding of interviewers whose available timeslots are in incorrect format - it is expected behaviour. However, as explicitly stated in the user guide, doing so will lead to a situation where “scheduled data will not be displayed properly in the user interface”. The section “Duration of Timeslot” also states that the user must strictly provide timeslots that match the “duration” parameter in the user preferences, or risk an inaccurate display of schedules. The production of invalid interviewing timeslots you mentioned would be that situation where “scheduled data will not be displayed properly”. This is expected behaviour, and we therefore reject this bug.

Thank you.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Dear Developer,

I was confused about the statement "The range of start durations and end durations available for input must be with Working Hours", and the"Working Hours" clearly states as "10:00 - 21:00". Therefore, referring to the User Guide, it is a major bug that invalid availability duration is allowed.

Besides, since you have set the constraints for working hours, it is indeed useful and expected to check whether the input availability duration is within this range. This will prevent the issue you declared: "scheduled data will not be displayed properly in the user interface". Leaving the "improper results" to be handled by the user may make your application less helpful and useful. Therefore, this could also be counted as FeatureFlaw.