Validation is important, but not exclusive!

When Test Cases are written from Use Cases (and others related) in the Test Plan creation should be considerate that, at least, all the system flow are being covered. These Test Cases are called Validation Tests. Commonly these tests are that kind of flows that the developers leave just “working” but not covering all the possibilities. A programmer is “hating” this kind of comment, but agrees. I am not looking down their profession and I do not have reasons to do that, but in a tight schedule, it is complicated to do a bright code following all those design patters suggested by market.
Seeing this factor, the tester generally appears as a bad guy but we always hear the kind of comment from them: “it was working well until he takes hand of the system”, of course that this is a pessimist view of the situation because all of us know that the tester comes to value the final product of the company, isn’t it?!
You, tester, want some more reasons to be “hated”? Start to “validate” those flows upside down, do exactly the opposite that it was written by the analyst. When the first guy had this idea, the Negative Test was discovered.
"Negative test cases are designed to test the software in ways it was not intended to be used, and should be a part of your testing effort." In other words, the application was not intended to do that but you should do that. For example, a Test Analyst takes 15 minutes to execute every Test Case in each Test Suite, basic way of counting Tester per hour. Some hours should be dedicated to the Negative Tests also.
When the study of Software Testing starts it is natural people gets engaged to the rules, it is an area with a lot of complex methodologies, techniques and methods. Even though, the famous “Error Guessing” technique are welcome, in other words, the system should be surfed trying to get as much defects as possible, based on the professional experience.
Formally, the “test it” is just “apply an error guessing technique”, a lot of techniques are being formalized per necessity. Every task applied to the system intended to find error in the execution phase is necessary and welcome, well, if the execution phase has been finished, “play” with your final system, your client appreciates!