Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
Often times we file a bug and later see that it's marked as "As Designed" by the developer. Sometimes it gets marked as "Will Not Fix".
When a bug is marked "Will Not Fix" then it is supposed to give credit to the tester and an acknowledgement that the bug was valid but it was decided not to fix it.
What is the thinking process that can be used to decide whether a bug should go to "Will Not Fix" vs "As Designed"?
When a bug is marking as "Will not Fix" it may have many probabilities.
"As Designed" category will not come under Bug.
For "As Designed"
I can recommend this reading about bug advocacy by Cem Kaner. There is also a workbook by him. It provides useful help in how you can learn to 'defend your bug', but it also teaches about understanding your context in what is and what might not be important (to fight for).
For both the Won't Fix and As Designed there could be different reasons why the rejection might be valid, but also many reasons why that might be invalid!
It is your job also to check that. And be aware that the As Designed can be true from a developers point of view, but it might still be wrong behaviour for different other reasons, e.g. the design can be wrong as well. In general I agree with other comments that this deferral shouldn't be a one man band decision. And I expect some feedback on those decisions as well, not only a status change on the issue. It might be the correct call, but it would help if in return you would learn why.
As a comment: I don't think I like earn credits for finding bugs as a valid metric or idea to stimulate testers to do their work... but that is a different discussion.
Disclaimer: I am an online instructor for the mentioned 'bug advocacy' course.
A decision about a bug MUST ALWAYS BE MADE by the core team: project manager, architect, analyst, test lead... whatever they may be called in the organization.
"Will not fix" acknowledges the presence of the bug. It is quite dangerous to choose this option, if a very careful analysis is not done regarding its impact (delay of the delivery date, money, safety...).
"As designed" means that it was the intended behavior. This status must be supported by a clear proof that there is a requirement present giving the details of that behavior.
However, if a behavior is not documented in any way, then an internal decision must be made - again by the core team.
Option 1. Add the proper requirements to describe the behavior.
Option 2. Remove the behavior.
Option 3. Just leave the behavior in the fog - do nothing. Really not recommended.
