View source | Discuss this page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Add page
Show collection (0 pages)
Collections help


Test Case Writing Guidelines



This document is intended to guide QA people in order to create good test cases. Good test cases are an important part of any quality assurance process.

A test case should be concise, clear and concrete. Easy to follow by test executor or automation people. And in a wider approach, a set of good test cases will cover some functionality on the system.

What is a test case

As an standard definition, we will say that a test case is:

A set of test data and test programs (test scripts) and their expected results. A test case validates one or more system requirements and generates a pass or fail

Writing a good test case

A good test case should follow two basic aspects, the Contents and the Style.

Contents of test cases


Style Guide

Using our Test Case Management tool Testlink, you can observe there are four main fields.

Test case name

This field is the main way to identify a test case. It is a short, direct description about what the test is intended for.


Note the prefix. It is very important that every test case has an unique prefix, so it can be linked to a Test Suite.


This field should explain what is the test case about, in order to complement the Name.



Steps are probably the most important field of a test case. It describes in a detailed sequence what have to be done in order to achieve the test case results.


Steps need to be precise, non ambiguous and easy to follow. It should be clear what is an user action (i.e. Click on a button) and data entry from system responses.

Expected results

As a consequence of the execution of the test cases, something has to be observed in the application. That will lead test executor to decide whether execution was successful or not.


Note: For some test cases you could be forced to include expected results as part of the Steps. It is nothing wrong with that. Expected results field should be completed, though. The rationale is that every step in Steps section will have some impact on the system. So if you have something like:

Then the final Expected Results should be the result of executing Steps 3 and 4, assuming intermediate results were successful.


You can find some useful guidelines at Mozilla Guidelines

Retrieved from ""

This page has been accessed 24,738 times. This page was last modified on 21 January 2010, at 06:24. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.