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: 
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.
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.