nus-se-bot
commented
22 hours ago Team's Response
Thank you for your feedback. However, after deliberation by the team, we conclude that this issue does not constitute a Low severity and should be a NotInScope issue.
The phrasing "Multiple entries allowed only if client has a car" is logically sound because it accurately describes the intended behavior in a concise manner.
-
Conditional Clause Structure:
The phrase establishes a clear condition: the allowance of multiple entries is contingent upon the client having a car.- "Only if" sets up an exclusive relationship: multiple entries are permitted exclusively for clients with cars. This means clients without cars cannot have any entries, aligning with the application's design and functionality.
-
Emphasis on Eligibility:
The statement implicitly addresses two key rules:- A client must have a car to have issues at all.
- If the client meets this condition (having a car), they may have multiple issues.
By phrasing it this way, the condition and the permission are combined logically and succinctly, avoiding unnecessary redundancy or over-explanation.
-
Consistency with Application Behavior and throughout the UG:
The current phrasing directly mirrors how the application operates:- For clients without cars, no entries are allowed (fulfilling the "only if" clause).
- For clients with cars, multiple entries are permitted (satisfying the condition).
This is consistent with all the other portions of the UG that state issues are associated with the car.
-
Alternative Phrasing Would Be Redundant or Less Precise:
We considered an alternative phrasing, such as "Clients with cars can have multiple issues, while clients without cars cannot have any issues."- This is longer, less concise, and introduces redundancy by repeating concepts already implied in the conditional clause. It also makes the parameters portion of the feature needlessly cluttered.
- It also lacks the precision of "only if," which succinctly captures exclusivity.
-
Reader Logic:
Most readers, when parsing the statement, will naturally understand that the conditional "only if" ties the eligibility (having a car) to the permission (allowing multiple entries). This avoids ambiguity and ensures alignment with logical reasoning.
Rationale for lowered severity
For the above reasons, we have lowered the severity to VeryLow.
Rationale for Not In Scope
We chose to classify this issue as Not In Scope rather than rejecting it outright, as we recognize that while the phrasing is accurate, logically sound, and succinct, it might still cause some readers to second-guess themselves in isolated cases, without additional context. Classifying it as Not In Scope allows us to acknowledge the reporter's perspective and highlight that the feedback has been considered, even though it does not indicate a functional issue or an actual bug.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: The team's response does not adequately address the crux of the issue, and their justification for the phrasing being "logically sound" fails to recognize how it introduces unnecessary ambiguity and confusion for users.
Firstly, while the team argues that the phrase “Multiple entries allowed only if client has a car” establishes a clear condition, this is not entirely accurate. The inclusion of “multiple” unnecessarily suggests that singular entries may be allowed for clients without cars, which is inconsistent with the actual system behaviour, where no entries are permitted for such clients. This phrasing misleads users into potentially testing or assuming functionality that does not exist, which wastes their time and creates confusion. The assertion that "only if" logically ties eligibility and permission fails to account for how users may misinterpret the presence of "multiple" as implying exceptions for single entries.
Secondly, the response claims that the current phrasing mirrors the application's behaviour and avoids redundancy, yet this is contradicted by the ambiguity introduced by "multiple." The team’s insistence on retaining this phrasing ignores the fact that an alternative such as “Issues are only allowed for clients with a car” is both clearer and more precise. It directly reflects the system behaviour without the added confusion of whether singular issues are permissible for clients without cars. Contrary to the team's argument, the alternative is not redundant but instead eliminates unnecessary complexity and improves clarity for users.
Thirdly, the rationale provided for “NotInScope” classification is weak. The team admits that the phrasing might cause some readers to second-guess themselves, yet they downplay the significance of this confusion. A user guide is meant to provide clear and unambiguous instructions, and the fact that some readers might misinterpret the phrasing demonstrates a failure in the UG's effectiveness. By labelling this as “NotInScope,” the team dismisses a valid usability concern and misses an opportunity to improve clarity with minimal effort.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** The issue cannot be classified as VeryLow because it directly affects usage. A VeryLow flaw only applies to situations where there is no impact on usage at all. In this case, the phrasing in the UG causes confusion for users trying to understand the system’s functionality, leading to potential misinterpretations about what is and is not allowed. This goes beyond a cosmetic or trivial documentation error—it directly affects how users interact with the product. The team themselves acknowledge that the phrasing “might still cause some readers to second-guess themselves in isolated cases, without additional context.” This perfectly aligns with the definition of a Low severity flaw, which refers to an issue that appears in rare situations and causes minor inconvenience to usage.
Description UG says that "multiple entries" of issues allowed if client has a car. But low severity since it is stated that the issues are for the car.
Steps to reproduce Try adding issues via edit to client with no car
Expected Able to add at least 1 issue if client has no car.
Actual Client cannot add any issues. UG should state issues only allowed if client has a car.
Screenshots