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!

Avoiding the “test it”

After a long time of hard trainings, studying complex methodologies, getting the best certifications in the market, we are hired by a company without well-defined testing concepts who wish to start a testing team. Cool, it is interesting the company get this view: we need a team who takes care of our application conformity with what was previously defined and other specific aspects when you choose to get a testing team.The problem is that is common (not because people are ignorante but aknowledged) listen the famous phrase: “application is deployed, test it now”. It is important not just the development team but all the project stakeholders know exactly how testing process works.
These days I have listen the following comment: “I don’t understand why we need a testing professional, we have program that does testing for us!” ok, I agree that it is much easier doing Unit Testing with softwares like JUnit and it is more intelligent using these kind of softwares on it. But JUnit isn’t necessary when the client ask for X and you delivery Y working properly…
Cool! We have a program who finds bugs alone, just clicking a button, why people from Microsoft didn’t do that on Windows? Come on, we know that is not, companies should start getting the testing culture, also universities should introduce Software Testing to the students, this topic is a subject inside the Software Engineering, when mentioned.
It is important to known that JUnit and other related tools are responsible for Unit Tests, which is just an artifact to show that the developer has his task well-delivered. Unit Test (or Component/Modular Test) is just one phase of the whole formal process of the Software Testing, preceded for the Work Product Review and proceeded to the Integration, System, User Acceptance, Regression phase, etc. 
Do you want to introduce a testing team in your company? So, here is a good tip: Try to understand how it works before, like that you know what you should supply and what to ask for to a Test Analyst. Firstly, it’s important to understand that testing isn’t a part of the development process, but a separated process, team, project and/or an apart organization, possibly sold separately from the rest of the development.
When I say that all the stakeholders should understand how testing works, I say all, inclusively clients. Should be understandable that when the project has time and budget involved, it’s common not to cover some functionalities not because people are incompetent but lack of this, for example. In this case not just validation test cases make senses to deliver a system working properly but is a good kick-off…

Blogging kick-off!

People, I am CTFL/ISTQB certified with more than 3 years of experience in Software Testing área, more exactly 2 years and 11 months off-shore projects to huge companies like General Motors, Carrefour, MERS and another considerable clients. In my whole experience I have been seeking to be in touch with all projects phases, since Word Product Review using Ambiguity Analysis to User Acceptance phase and in all areas like manual, automated and performance testing.
Around 3 years ago I did not know that I fell in love for Software Testing area and nowadays for that reason I am always looking for market tendencies updates and I do the best I can while I am at work. That is why I got a more critical view of the situation I am into, related to Software Testing, or not.