nus-cs2103-AY2324S2 / forum

17 stars 0 forks source link

A Tricky Tester Response Scenario (context added) #955

Closed benson1029 closed 4 months ago

benson1029 commented 4 months ago

I'm reposting this since additional context was requested.

I tested the commands sort price and sort salary during the PE (both are "numerical" fields). I notice that sort price sorts the prices using string comparison while sort salary sorts the salaries in increasing numerical order. I proceeded to report sort price as a type.FunctionalityBug (without mentioning sorting by salary).

Now, the team rejected the bug and claimed that string comparison is intended, quoting the UG that sorting is done in lexicographical order (they mentioned this in the UG). However, this behaviour contradicts with a user story in the DG.

Now I'm in a disadvantaged position since I did not mention the inconsistency between sorting by price and salary during the PE.

My options right now: Option A: Argue the bug as a type.FeatureFlaw (since it contradicts with the DG). (I did not mention the DG in the original bug report. Am I allowed to add this information in?) Option B: Proceed to argue the inconsistent behaviour of sorting by salary and report that as a type.FunctionalityBug. (I did not mention the sorting by price in the original bug report. Am I allowed to add this information in?) Option C: Continue arguing that sorting by price should be done in increasing numerical order and thus it should be a type.FunctionalityBug. (Is this reasonable?)

In particular, may I check what is the allowable extent of quoting additional information during the tester response phase?

If all of my options do not work, I feel that there is a loophole in this PE so that teams can write ambiguous documentation and reject bugs testers have reported by suddenly claiming that the behaviour is intended.

Will appreicate any advice on this. Thanks!

Link to the issue (for reference): https://github.com/nus-cs2103-AY2324S2/pe-dev-response/issues/4739.

aureliony commented 4 months ago

The course website mentions that you can change the bug type. image

So I would argue that it's a feature flaw, as that seems to be the most accurate and valid (Sorting price by lexicographical order instead of numerical order doesn't make sense). What the DG says doesn't really matter, at its core it's a feature flaw. (My own opinion as a fellow student)

damithc commented 4 months ago

Option A: Argue the bug as a type.FeatureFlaw (since it contradicts with the DG). (I did not mention the DG in the original bug report. Am I allowed to add this information in?)

@benson1029 Yes, you can add more info in this phase. The teaching team will consider that information when making the decision, also keeping in mind that the dev team did not see this additional information. So, the value of adding more information at this phase is not as high as if you had that information in the original bug report, but it can still help your cause.

damithc commented 4 months ago

@benson1029 to clarify, the additional information should be in your response. Don't edit the original bug report.

benson1029 commented 4 months ago

Ok, I will be putting this in my tester response. Thanks for the clarification!