Welcome Raja, and thanks for your question.
In my view, flaky tests are harmful by definition, for several reasons (some of which you also refer to):
- Few people enjoy investigating failures when there is a good chance the issue is in (the coding of) the test rather than in the SUT. After doing it for a while, it becomes very annoying. This can take a good deal of pleasure out of the job for several team members. This is bad.
- As more flaky tests accumulate, team members (unconsciously?) start protecting their sanity and start ignoring red test runs. This defeats the purpose of having an automated regression test. Also bad.
- Re-runs can hide bugs in the SUT. Perhaps even worse.
In my experience, flaky tests are usually the result of poor craftmanship. If it happens once, fixing it can help people learn to prevent it from happening again. Mistakes are a normal way of learning, no problem. But if they are not fixed OR the lesson is not learned and they keep popping up, it soon annoys.
So: Unless you are in the very unusual situation where it is impossible to prevent, flaky tests signify a poor job and should not be allowed. Let the person who made them fix them. Mentor the person for the technical side of things, but especially foster a culture where committing flaky tests is not okay. Deleting should be a last resort: If the test is valuable if it works, it should not be deleted because someone does not have the skill or the inclination to do a better job, otherwise its value is lost (and more flaky tests will follow …).
Does this correspond with your thinking?