search

freshcabbage123 / pe

0 stars 0 forks source link

Extreme difficulty in testing addContactEvent #9

Open freshcabbage123 opened 11 months ago

freshcabbage123 commented 11 months ago

Screenshot 2023-11-17 at 5.03.48 PM.png

Firstly the command given in the format is wrong: addContactEvent INDEX d/DESCRIPTION ts/START_DATE_TIME ts/END_DATE_TIME. It should have been te instead of ts for END_DATE_TIME. As a tester i am wondering why there is 2x /ts in the first place.

Secondly, the example given (addContactEvent 1 d/Team Meeting ts/2024-01-01 09:00 te/2024-01-01 11:00) is in the correct format with te but it uses a date in 2024 such that it is not easy to test the UI straight away as i cant see it straight away after clicking onto the person i want to see.

Screenshot 2023-11-17 at 5.07.36 PM.png

Lastly, this example is just very misleading as the week in which this example was created is not the same as when users create it. The definition of current week is misleading here.

These 3 points are related and cause extreme difficulty for a tester/user to verify that the feature is working hence medium difficulty.

nus-pe-script commented 11 months ago

Team's Response

As there are multiple bugs present in this bug report, the first bug will be chosen.

Firstly the command given in the format is wrong: addContactEvent INDEX d/DESCRIPTION ts/START_DATE_TIME ts/END_DATE_TIME. It should have been te instead of ts for END_DATE_TIME. As a tester i am wondering why there is 2x /ts in the first place.

Tester's concern is valid, and the typo can lead to a misunderstanding of the command. However, the user can quickly clarify the typo from the example below, as well as from the error message that is displayed when the user uses the command with the incorrect format.

Items for the Tester to Verify

:question: Issue severity

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

Reason for disagreement: It is not multiple bugs present. This is all within 1 short section for addContactEvent. The bug lies in the sheer difficulty of testing your application because at every step, there is an error/inaccuracy with the documentation which makes it very difficult to follow.

Firstly, when the user reads the format, it is already wrong which confuses the reader.

In the next step, the developers then double downs with an example in 2024 which the UI will not reflect as the UI will only show changes in the current week. This would confuse the user as this specific UI behaviour is not explained until much later after the original screenshot by the developers in the UG. At this point, the reader is confused and the tester has no idea what is going on.

In the third part, the example given is in a different week from the week where Practical Exam was held. As such, the tester will not be able to see the event list even though the documentation suggests that the tester could. It is also worth pointing out that readers and testers can only infer at this step that the UI only shows the changes in the current week.

They are not 3 separate bugs. The problem is the sequence of problems from the documentation that gives rise to the overall issue of testability. Furthermore, even if they were separate bugs which they are not, the dev team is supposed to pick the most severe bug which is the 3rd step. In the 3rd step, it will cause confusion to ANY user who attempts to use this application. That is because any user who uses the UG and application in future will not see the same UI changes if they were to use the same example from the UG. This is simply because the example is dated and not in the current week. As such, the 3rd step should not be talking about being able to double click to see Alex's events because that is simply not possible. Since it will definitely inconvenience all users, it should retain a medium severity.