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"?

  • can you add a comment for why you're downvoting this question?
    – Mugen
    Commented Jun 21, 2019 at 6:38

3 Answers 3


When a bug is marking as "Will not Fix" it may have many probabilities.

  • We need to validate the severity/impact of the bug to the users. If the bug is really valid one but it wont have much impact on the user and business side then it can go in "Will not Fix" category
  • "Will not Fix" innocents the bug will not be fixed in the release instead it can be taken in future releases.

"As Designed" category will not come under Bug.

For "As Designed"

  • The functionality of the application is designed in such a way to behave. But the designed functionality can have some issues in terms of usability or business aspects. In such cases check with the module owner or refer the documentation for getting the idea on why it was designed like that.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.