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

Answer: 
I can recommend this reading about [bug advocacy](http://www.testingeducation.org/BBST/bugadvocacy/) by Cem Kaner. 
There is also a [workbook](https://rads.stackoverflow.com/amzn/click/com/098981193X) 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.