Closed benson1029 closed 4 months ago
The course website mentions that you can change the bug type.
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)
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.
@benson1029 to clarify, the additional information should be in your response. Don't edit the original bug report.
Ok, I will be putting this in my tester response. Thanks for the clarification!
I'm reposting this since additional context was requested.
I tested the commands
sort price
andsort salary
during the PE (both are "numerical" fields). I notice thatsort price
sorts the prices using string comparison whilesort salary
sorts the salaries in increasing numerical order. I proceeded to reportsort price
as atype.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 atype.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 atype.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.