search

Emberlynn-Loo / pe

0 stars 0 forks source link

Missing specifications for add command #20

Open Emberlynn-Loo opened 4 months ago

Emberlynn-Loo commented 4 months ago

Expected Specifications for different parameters of add command to be listed such as names cannot have special characters etc.

Actual Only some specifications were listed, but not all, leaving users to have to manually find it by themselves.

Screenshot 2024-04-19 at 5.56.16 PM.png

nus-pe-script commented 4 months ago

Team's Response

The team has provided specifications in the Input Constraints section of the UG.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I acknowledge that while the constraints are in the UG, there are still missing specifications other than the example i gave of one of them (names cannot have special characters). For example

  1. tags can only be 1 word
  2. you specified that Name and Company must be alphanumeric but did not say the tags must also be alphanumeric. The user must try it out and read the error message in order to find out
  3. Tags must not be blank. It is specified for Name and Company, but not for address which could potentially make users think that address can be blank, only to find out from the error message that it cannot be blank. It is even specified that you can add 0 tags, users might accidentally misread and try t/, ony to find out that it does not work.
  4. Address must not be blank. It is specified for Name and Company, but not for address which could potentially make users think that address can be blank, only to find out from the error message that it cannot be blank.
  5. Email local-part must not be blank. It is specified for Name and Company, but not for address which could potentially make users think that the local-part for email can be blank, only to find out after getting the error message that it cannot be blank. Furthermore, the domain name is specified that it has to be at least 2 characters long, but the local-part does not say so. Therefore, it is reasonable for users to assume that the local-part could be blank. To rectify this, the very easy solution would have been to add the same thing for the domain name to the local-part and state that it must be at least 1 character.
  6. The add command itself is case-sensitive, users might try Add or aDD and have to get the error message itself to find out that it is not.
  7. Names are not case-sensitive. While it is mentioned that two contacts cannot share the same name, it is not mentioned that they can be spelled exactly the same but be capitalised different and be accepted.

Based on all the specifications above, it is definitely a bug. Users will have to manually try out all of these cases before discovering what the constrains are.

I would actually increase the severity to medium. This is because of the number of specifications that are missing for the add command. It is not only one, but 67of them. Some of them are important and not only used in a rare case. For example the fact that the names are not case-sensitive is definitely something that would cause confusion for users as it has been stated that same names are not allowed but they might be able to add in a person of the same name. This won't be something that open happens in a rare case as duplicate names are very common, particularly for chinese names like Tan. If the application does not correspond to what the user guide specifies the behaviour to be, that would definitely cause confusion and be an inconvenience to users. The case-sensitive command specification is also something that might occur more than just once. Since this is using CLI, novice users might type like it is a sentence and capitalise the first letter of the command, making it be 'Add' and therefore not working. Because it is not specified in the UG, they would be confused as to why it is not working and have to check through the entire feature formatting for the command, making this an inconvenience to them. The tags not being mentioned to be alphanumeric causes a lot of problems for using trying to understand the tag feature. For example theh edit command specifies that typing t/ is ok and will just delete all existing tags, however it is not mentioned that for the add command, this is not allowed. Because it is something that has already bee mentioned, it is not unreasonable to assume users might try it for the add command only to be very confused.

Therefore, due to the fact that there are so many specifications not written which does not properly guide users and that some of these could be important and common occurrences by users, causing them to be confused, I would label this as a medium severity bug. It would definitely cause occasional inconvenience to users as they would have to discover such specifications on their own which would slow them down as they'd have to find out what is wrong and not be able to refer to the UG to check. However, they can continue using the application.