How to write Test Cases?

In Manual Testing, Testers will test the Application  by executing the Test cases manually  without requiring  any automation tools.  Manual testing will take significant time to cover all the requirements. So, it is very important to write test cases effectively to cover all the requirements while keeping number of test cases at  minimum level.  Let us  see how to write test cases  for testing an application.

What is  Test Case ?

Test case is “Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.” The  purpose of Test Case  is to divide the software function into small units of function that is testable with input, and producing result that is measurable.

i-e  A test case is a feature/function description that should be executed with a range of input, given certain preconditions, and the outcome measured against expected result.

These are the  fields commonly present in the Test Cases :

  • Test case id
  • Test Case Description
  • Procedure / Test Steps
  • Test data
  • Expected result
  • Actual result
  • Status ( Pass/ Fail)
  • Comments

Test cases should be simple and easy to understand for Developers.

Test Case ID :

This ID should be Unique throughout the Testing Application and not to change at any moment.

Test Case Description:

Explain the function under test. Clearly state exactly what attribute is under test and under what condition.

Prerequisites– Every test needs to follow a sequence of actions, which lead to the function under test. It could be a certain page that a user needs to be on, or certain data that should be in the system . For example  registration step should be completed before start testing login.

Procedure/Steps:

Sequence of steps to execute the specific function.

Test data:

Specify the data used for a particular test or if it is a lot of data, mention the path of a file where this data is stored.

Expected Result:

Clearly specify the expected outcome in terms of the page/ screen that should appear after the test, changes that should happen to other pages, and if possible, changes that should happen to the database..

Actual Result :

State the actual result of the function execution. Especially in case the test case fails, the information under ‘actual result’ will be very useful to the developer to analyse the cause of the defect.

Comments:

In this section you can add your reviews, suggestions and ideas to developers for the bug how we fix that.  Especially this section made to communicate with developers.

Test case writing procedure

  • Get as much information about the application as possible through available documentation (requirement specs, use cases, user guides) , tutorials, or by exercising the software itself (when available)
  • Determine a list of features and different user roles.

 

Say for example, if you are writing Test Cases for testing  this Timesheet Application.

First you should understand the features available in this timesheet application by reading the help files and other available documents about this timesheet application.

You should know about different user roles (e.g user, admin) involved in this application.

Once you gather all the details about this application, you can start writing test cases. Find below one sample, and you can show/test your test case writing skills by adding more test cases thro’ the comments section.

  • Test case id – LG01 (LG refer as Log In)
  • Test Case Description -Check Case sensitivity in  Log In Functionality
  • Procedure
  1. Load login screen by visiting http://qualitypointtech.net/timesheetdemo/index.php
  2. Enter valid username and password in Upper case.
  3. Click “Login button”
  • Test data – Username as user || Password as USER
  • Expected result – Alert box like CAPS LOCK on to warn the user
  • Actual result – But its not visible and accessing with uppercase letters.
  • Status ( Pass/ Fail) – Fail
  • Comments –  Password is an user’s choice so we can’t restrict so we have to give the warn or alert box or format that password should be like this.
Like wise, for each and every action we have to write test cases.

At the time crunch of any project, the testers simply go with the Adhoc Testing and Exploratory testing.