Writing Test Cases

After writing test conditions, this is the next logical item one must go thru in a project. A test condition tells "WHAT" to test. A test case tells "HOW" to test. That means, we must provide step by step details in test case. This is like a recipe - you miss one vital step, the execution of test may go wrong.

Simple mantra you must follow when you write test cases - think that you are giving instructions to test the software, to an 8th grade kid. The kid knows English and knows how to operate computer; but does not know anything on how to test your application. 

Is it really possible to make a kid to test my application? Yes it is, provided the instructions are clear and simple. Have you ever called a customer support help desk to resolve a problem in your laptop? You might have observed that the help desk person asking a series of simple short questions and solving your problems in minutes. The trick is clear and simple document. Look at this following example. 

1. Open firefox browser.
2. Navigate to www.openmentor.net
3. Click on Word Games link.
4. Click on the link that says "Click Here to start"
5. Choose 4 from the list box shown.
6. Click Go.

If we give instructions like this, don't you think that you can make another person to test a software? This is the holy trick of getting work done by vendors and that too relatively junior testers, thus reducing the cost. If we do not do this kind of clear step details, we may require senior testers, who are costly. Every management would like to reduce the cost. If that needs to happen, a good set of test cases must be drafted.

In the industry, a test case is written in a document or in a spreadsheet with the following details.

Test case Id: A unique identifier for this test case, across the project or company.
Test case name: Usually this will be the test condition that you wrote before.
Pre-condition: The pre-requisite that must exist before we do this test.
Test Steps: Simple step by step such as clicks, types, navigation etc to carry out the test.
Test Data: The data yo must choose or type in any forms.
Expected Results: What is the expected outcome when we do these steps with the given data.

Usually people ask me this question - why should we write this much, when I know how to do it? Remember, you or any other person in the project, may be moved to a different project tomorrow. In that case, should other person re-invent the wheel? So better put all the things you remember in testing this product, in a paper. Also, you be the thinker that adds more value; let the test execution be done by other juniors. It also helps in assessing whether we have missed any permutation or combination in testing. If everything is just remembered by you, no one knows how many tests you remember and how many you do not. So better to document every test case.

Writing test cases will take more time. Agreed. But it is usually for one set of test cases; after that, you copy-paste the same text and make modifications in steps or data and expected results. It is not usually all text in all test cases are typed fully by you. Once a pattern of test is identified and typed, rest is all making minor modifications to that text. 

In the next posting, we will see examples of test cases and a few techniques like boundary value analysis etc.