search

yucongkoo / pe

0 stars 0 forks source link

Clear command does not require confirmation from users #10

Open yucongkoo opened 10 months ago

yucongkoo commented 10 months ago

Steps to reproduce: Type in the clear command in the command box and press enter

Problematic behaviour: This command is a very severe destructive operation (all data will be lost and users will not be able to recover the lost data). As there might be users that did not read the user guide thoroughly, they might not be aware of this destructive command. This case especially applies to users that have certain programming/command line experience(a common scene now especially in Singapore), where they are very used to use the clear command to clear the terminal, they might expect that this command is used to clear the result display box and type it in instinctively., which will cause irreversible consequences.

Suggestions to improve: Have an additional confirmation step for the clear command, to ensure that users actually want to delete all their data.

nus-se-script commented 10 months ago

Team's Response

Tester is attempting to sabotage deliberately. Firstly, "clear" is a very hard command to "accidentally type". Secondly, if tester didn't read the user guide, it is on the tester. Thirdly, we stated in our UG that as long as "clear" is in the command, such a behavior is to be expected. Lastly, we have discussed this issue earlier and feel that it can be left for future as we have more higher priority issues to do such as fleshing out functionality for policy which is needed for a financial advisor. Hence it is either rejected or not in scope and my team lean more towards rejecting this as a bug report.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: > Tester is attempting to sabotage deliberately.

As a tester, I am supposed to do all the nasty things to the application, with the hope of discovering bugs/flaws in the early stage of development of a product, as these are the times that the bugs/flaws will cause least consequences. Besides, I do not agree that this is a deliberate sabotage, I think that this is indeed a possible situation, more of my stance stated in the following responses.

Firstly, "clear" is a very hard command to "accidentally type"

As stated in my original bug report, if a user has certain programming and command-line shell experience, clear is a very common command used in terminals to clear the terminal, it is not a rare case that users expected to use clear to clear the result display box. Rather than accidentally type, I would rather use the term instinctively type, where it was already a reflex to clear the terminal(with the intention of clearing the output box here), especially when the command often produces lengthy result that fills the output box.

Secondly, if tester didn't read the user guide, it is on the tester.

As a tester, I am playing a role of the users, and you can never force a user to read the user guide thoroughly before starting to use the product right? When was the last time that you actually read through a whole user guide before starting to use the product? More often, users would use the product with their limited knowledge, and use the user guide when they get stuck or want to find out something. Hence, even if I were to read the UG already, it is still my responsibility to put myself in the shoes of the users where they might not have done so.

Thirdly, we stated in our UG that as long as "clear" is in the command, such a behavior is to be expected

This has nothing to do of rejecting this feature flaw, as this just proves that this is not a functionality bug.

Lastly, we have discussed this issue earlier and feel that it can be left for future as we have more higher priority issues to do such as fleshing out functionality for policy which is needed for a financial advisor. Hence it is either rejected or not in scope and my team lean more towards rejecting this as a bug report.

I am not very sure why you had chosen to reject this bug rather than accept it as NotInScope, as rejecting it means that you do not agree that this is a potential flaw. I can understand that the team has higher priority tasks in the current iteration, but this is not a reason for the team to deny this potential flaw.

I think that requesting a confirmation from users before performing a very destructive operation is a common practice among all kins of operation. Deleting a GitHub repository, deleting a contact from your phonebook and so on require confirmation, even though the user intention of deletion was already clear. Hence, I think it is not very appropriate to totally reject his potential flaw.