search

shotnothing / pe

0 stars 0 forks source link

`find` command behavior different from UG #4

Open shotnothing opened 1 week ago

shotnothing commented 1 week ago

In the UG,

image.png

find indicates accepting one keyword, and another optional keyword (i.e. 1..2).

However, the app allows me to find 1..* keywords, i.e.

find david li so

Hence the correct notation is

find KEYWORD [MORE_KEYWORDS]...

Severity Justification
The average user might unnecessarily inconvenience themselves by limiting themselves to 2 keywords (unlike the actual behavior/AB3 behavior), thus being a hinderance caused by incorrect documentation.

Hence, severity.Medium : A flaw that causes occasional inconvenience to some users, but they can continue to use the product.

nus-pe-script commented 1 week ago

Team's Response

Thank you for your feedback. While we appreciate the tester’s observations regarding the behaviour of the find command and understand that the intended behaviour of the find command "accepts one keyword, and another optional keyword", we believe this issue does not indicate a bug but rather an undocumented feature.

The tester’s statement that the app “allows me to find 1.. keywords” implies that this is an undocumented feature. This undocumented feature should be fine and not affect users as it is both intuitive and aligned with the documented description so that users can easily utilize the command as described in the UG without any inconvenience to find contacts with names of one or another optional keyword (usually referring to, first name, and family name).

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Hi! Thank you for your response!

I disagree with the view that this is an undocumented feature.

The feature is the find command, and it is documented, just wrongly as the ... was omitted, thus causing a difference in behavior between the app and the UG.

If the behavior of find being 1..2 is expected, then I believe it to be a: type.FunctionalityBug: A functionality does not work as specified/expected. Otherwise, I believe it to be a DocumentationBug.

With reference to the textbook:

image.png

I believe such a mismatch is considered a valid bug.

As to the severity if 1..2 is expected, there is no error/invalid message when the user enters more than 2 keywords, thus in the case of typos where additional keywords are added, they will be part of the filter rather than being prompted as a mistake to the user.

E.g. find Diana Joy Joe

I intended to find Diana and Joe, but accidentally added Joy. Thus, anyone with the name Joy will come up in my filter, which is not the expected behavior (as a user I would expect some sort of invalid number of keywords error/warning since I only expect to be able to enter up to 2 words).

severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

For severity.Low, there are two components to this this severity:

As having a typo where an additional word is added is an uncommon but reasonable occurrence, I believe it meets the first component.

Having an additional unintended word can lead to a misleading result that unintendedly has the extra word in it, with no obvious way to realize that I made a typo. As such, it also meets the second component.

As such, I believe the original severity of severity.Low is justified.