“To err is human, but to really foul things up you need a computer.”

- Paul Ehrlich

Building test cases is about doing your best to find the worst in a program in order to deliver a quality product to the customer. Without a well-designed and executed test plan, the results can be catastrophic and very costly. For example, because of an error in the software, the first flight of the Ariane 5 rocket resulted in its complete destruction and the loss of four satellites at a cost of more than $370 million.

In the U.S. alone, software bugs cost the economy $59 billion back in 2002. Clearly, software defects must be found and corrected before unleashing new programs to the customer.

What is a Test Case?

A test case has an input, an action and an expected result. In using test cases, the tester is trying to break the application. The whole point of using test cases is to find defects. Hopefully, serious defects that crash the system are found before your application is released to the customer. These show stoppers, or defects that may delay release of the application, must be found and fixed in order to save time and money and prevent customer dissatisfaction.

Test cases must exercise every feature of the application to prevent defects from being released. Each test case needs to contain a set of test steps of a feature or function. At the end of the test the expected results are compared to actual results to determine if the application is working as it should.

A test case can have information that includes the test case name, goal, environment, steps to take, input and expected results. The following is an example of a test case description from a test case management tool.

A good test case consists of several ingredients: its chance of finding an error is high, it doesn’t copy other test cases, it’s most likely to find error or defects, it’s not too simple or too complex and it is obvious to a tester when an application failure has occurred.

  http://www.elementool.com/ebook/SoftwareTestCases.pdf