Documentation describes type specificity, but does not enforce it for commands

[winston-lim]

Documentation accurately captures specificity as described here: https://datamall.lta.gov.sg/content/dam/datamall/datasets/LTA_DataMall_API_User_Guide.pdf, and yet allows querying for carpark-ids that do not conform to these standards. e.g. filter -id ** returns no search result, where it should return a format or type error

[soc-se-bot]

Team's Response

Hi, thank you for your bug report! Good catch - a format error should be returned

The team would like to contest the labelling here: what you are describing is a problem with specificity of error message:

As seen here in this example, it should be of severity Low, since the functionality of the program is not changed either way: either an error message is thrown (Invalid input), or no carpark is returned. Either way, no crashing of the app or incorrect carpark data is shown to the user, and functionality is not affected in any way (no carparks are displayed in either case). Thus, this should be a severity.Low bug (A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only) , and definitely not severity.High.

As an aside, the LTA documentation cannot be trusted - the LTA API returns data outside of the scope of what they described (additional lot types, negative integer values for lot availability etc.), and thus the rules defined in their documentation cannot be what is used to validate the app. However, we do agree that in this specific case, it may be useful to tell the user that the format is incorrect, so we will be accepting this bug. Thank you!

Items for the Tester to Verify

:question: Issue severity

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

• [x] I disagree

Reason for disagreement: I argue that this is definitely not a specificity of error message bug and am pushing with my original severity.High. The reasons are as follows:

• In this case, an error should have been thrown, but nothing was thrown - in fact the program actually executes code except that it returns an empty list
• In your DG, you specified a specific type specificity for parameters, and yet do not check for it which is a functionalBug
• This is not specific to just the filter command, this affects all commands that use the CARPARK_ID parameter

The main argument is therefore, this lack of handling an essential(in fact it is the only parameter of concern in this application) parameter which affects all the key commands find, filter, fav, unfav bumps this problem to a severity.High

---