search

maj0-0 / pe

0 stars 0 forks source link

Error message does not match the one stated in the DG #4

Open maj0-0 opened 10 months ago

maj0-0 commented 10 months ago

image.png

The DG states that if add n/Joshua is entered, an error message 'error message is thrown indicating that compulsory field p/ and e/ are missing'

However the error message just states that the format is invalid, and does not mention which fields are missing. It can be implied from reading the rest of the UG and seeing which commands are compulsory, however it would be beneficial to include in the error message!

soc-pe-bot commented 9 months ago

Team's Response

First of all, the expected part is just to help tester understand what behaviour they should expect from that action, they are never meant to define what the error message should be. These information should be based off the UG.

I do agree with the tester that the error message can be further specified. However, I believe that after reading through our UG, the user can easily understand that the optional field are missing from the error message given.

Thus, the priority of this change is significantly lower than the features we have implemented, and the effort of implementing this does not match the value it provides. This is my reasoning for putting it not in scope.

(Functionality Bug -> Feature flaw : There is no mismatch between the UG and product behaviour thus I changed it to feature flaw instead, as the tester focuses on the specificity of the error message)

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Here is why I think that this issue is in fact in scope.

  1. Consistency with Documentation: Since it is already stated in the documentation that the error message will indicate compulsory fields, it should also be included in the actual implementation.

  2. Enhanced User Experience: I think providing a clear and specific error message, like you have stated in your documentation, would help users be informed on exactly what's missing in their command. It makes your product more user-friendly and accessible on first use.

  3. Priority: I think specific error messages to cover possible scenarios should be of higer priority so that each feature feels more "complete" within the wrapping up of the milestone, and it does not have to be editted again.

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** Based on the definitions of functionality bugs and feature flaws from the website, I believe this issue should be classified as a functionality bug rather than a feature flaw. 1. **Behaviour Differs from the User Guide**: The Developer Guide (DG) explicitly states that entering the command `add n/Joshua` will result in an error message indicating that compulsory fields `p/` and `e/` are missing. However, the actual error message simply states, "invalid command format!" without specifying which fields are missing. This discrepancy between the documented behaviour in the DG and the actual behaviour of the software qualifies as a functionality bug. 2. **Expectation of Specific Error Messages**: A fundamental aspect of user-friendly software is providing clear and informative error messages. If the DG specifies that the error message will indicate missing compulsory fields, then the software not doing so is a deviation from expected behaviour. This again points to a functionality bug, as the software is not behaving as specified in the documentation. 3. **Handling of Legitimate User Behaviour**: The issue also involves the handling of a legitimate user behaviour—entering a command with missing compulsory fields. The software's failure to provide a clear and specific error message in this scenario can be seen as a shortcoming in handling legitimate user input, aligning with the definition of a functionality bug. Given that the actual software behaviour differs from the documented behaviour in the DG, and considering the expectations set for error messages, this issue aligns more closely with the definition of a functionality bug.