Test Case Writing Guidelines

Contents 1 Introduction 2 What is a test case 3 Writing a good test case 3.1 Contents of test cases 3.2 Style Guide 3.2.1 Test case name 3.2.2 Description 3.2.3 Steps 3.2.4 Expected results 4 References

Introduction

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

<TBC>

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.

Examples:

• [ADM0110] Create user
• [PRJ0050] Track and process Invoiceable Expenses

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

Description

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

Examples:

• Test case: [PRJ0050] Track and process Invoiceable Expenses
  • Description: Check and process invoiceable expenses, namely, expenses that customers will be billed for.
• Test case: [ADM0020] Activate instance
  • Description: Activate a Community Edition (OCE) into a Professional Edition (OPS)

Steps

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.

Example:

• Login with Openbravo user
• Go to General setup->Application->Instance Activation
• Check that Subscription status is Inactive
• Click in "Register Online" button
• Select Testing as "Main Purpose"
• Click Ok

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.

Example:

• A "Process completed successfully" message is displayed.
• The Subscription Status is now Active.

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:

• Step_1
• Step_2
• Intermediate Expected Results
• Step_3
• Step_4

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

References

You can find some useful guidelines at Mozilla Guidelines

Category: Quality Assurance ERP