search

daniellau88 / pe

0 stars 0 forks source link

Manual Testing Description #9

Open daniellau88 opened 3 years ago

daniellau88 commented 3 years ago

The description for the manual testing is not accurate. For corrupted data files, a clean slate of the program will be given instead.

image.png

Would be more accurate to mention that this only applies for missing files.

nus-pe-bot commented 3 years ago

Team's Response

No response provided.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Error in JSON not handled

Steps to Reproduce: Edit JSON start date of a task to be earlier than end date. list

Expected: "If your changes to the data file makes its format invalid, ModuleBook3.5 willdiscard all data and start with an empty data file at the next run." from the UG. But it did not start with an empty data file

Actual: No errors thrown . Used saved data

Screenshots:

Screenshot 2021-04-16 at 2.55.43 PM.png

[original: nus-cs2103-AY2021S2/pe-interim#994] [original labels: severity.High type.FunctionalityBug]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thank you for pointing this out, we discussed this issue among the developers weeks ago, we had our special reason to keep this feature.

Changed the severity from high to low: As stated in the marking scheme, "A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only." Editing the saved data is not considered a normal operation, and even you edit the JSON file in this manner, it will not cause any bug in our module book except that YOU MAY THINK the task becomes meaningless.

Changed the Bug Type from FunctionalityBug to FeatureFlaw: “If your changes to the data file make its format invalid, ModuleBook3.5 will discard all data and start with an empty data file at the next run.” Change the start time later than the deadline does not make the data file's format invalid. In fact, we do not have the definition of invalid tasks, we only have the invalid format of each field of a task. It is just "you are suggested not to change the start time later than the deadline", it is not because "the start time later than the deadline is an invalid format". So the behavior of our module book is indeed consistent with the user guide, as there is nothing wrong with that special format. I think you may mean: we do restrict a user from editing a start time and deadline in the main program, why we do not have this restriction on editing JSON file, why there is such inconsistency? This clearly belongs to a feature flaw.

Why I reject this bug report: Firstly, there is no bug related to this issue, and most importantly, it even causes no inconvenience to a user. As we stated in UG, "Advanced users are welcome to update data directly by editing that data file." As an advanced user, you should clearly know the meaning of each entry in the JSON file. Given that, if you feel any inconvenience caused by a task with its start time later than its deadline appears in the task list, you should not change it in the first place.

Secondly, We prevent a new user from editing a start time later than the deadline by setting a restriction in our parser, just in case they are not familiar with the notations "a/" and "b/" and misuse them. For an advanced user, we decided to give you full authority to edit a task, you can make use of this feature to achieve your own purpose, as long as it is in the correct format.

Thirdly, a task with a later start time has its own value. You can make use of this feature to achieve your own purpose. Here are some examples:

  1. Let's say you have two tasks, "Ventilation: keep your door open" from 12:00 to 16:00, "Walk your pet dog" from 13:00 to 15:00. If you sort the task list according to the deadline, "walk your pet dog" will appear first. But actually, you should open your door first. In the current version of the module book, we do not support the functionality of compare a start time with the deadline. If you are an advanced user, you want to make "Ventilation: keep your door open" in the front of "Walk your pet dog" without losing any information (and you do not want to separate the first task into "open the door" and "close the door"). You can simply edit the JSON file to startTime: 16:00, deadline: 12:00, and you will achieve the effect. This applied to all tasks that you do not need to physically present.
  2. Easier for the developer to test other features such as sort, when you change the deadline in JSON file, you do not need to care about the start time for every task, you can just adjust the deadline and the order will change. If we implemented this restriction, if you miss any start time, the entire file will be gone, and usually, a test on sort contains many tasks.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: Hi, this is not a duplicate as this is an error in the documentation.

For my issue, I am specifying that the word corrupted is unnecessary as it gives users the wrong idea of this manual testing. This manual test only works when the data file is missing (and not corrupted).

The behavior of corrupted files is specified in the UG as below.

image.png

For the other points, I also disagree and I would keep to my initial explanations.

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: [replace this with your explanation]

:question: Issue type

Team chose [type.FeatureFlaw] Originally [type.DocumentationBug]

Reason for disagreement: [replace this with your explanation]

:question: Issue severity

Team chose [severity.Low] Originally [severity.VeryLow]

Reason for disagreement: [replace this with your explanation]