Will Not Fix in testing
What Will Not Fix means in testing
How does a decision not to fix a bug usually come about?
A tester found a bug and wrote a report; the manager decided that it is not a bug, or that it is a bug but does not need to be fixed.
How should a tester react to this?
It would seem that time was spent finding the bug and writing the report, and it is not even put into the Ice Box for the future.
If a tester respects their work and/or cares about the quality of the product, should this hit their motivation?
Answer: it should not.
There is no need to react to it in any way. At most, you can ask about the reason if it was not given.
The task of a tester is not to get every bug fixed
but to provide up-to-date information about the quality of the product.
The task of management is to calculate which bugs are financially worthwhile to fix and which are not.
Let me give a rather grotesque example.
You have discovered that the software fails to start in nine cases out of ten.
At the same time, the entire development department is busy repainting the icon from red to green.
The manager studies your bug and decides not to fix it.
What is wrong with the manager?
The manager is fine, but he knows something the tester does not know yet.
In the country of the client a law is coming into force that all icons must be green; without this the software will not be bought.
To have time to change everything before the law is adopted, the entire department must work for six months.
The employees of the client contrive to start the software in the rain, on odd Wednesdays, at three in the morning, and then it
fails to start only in half of the cases.
The module responsible for startup will be rewritten next year anyway as part of the planned move to
a new technology.
And so on…
That is exactly why the bug is sent to Will Not Fix. Your task as a tester is to report the state of affairs.
Once the bug is filed, other employees will be able to see that the problem is known and that it has officially been decided
not to fix it.
Article author: Arthur Isaev