TEST CASES

What is a Test Case?

Test cases for software help guide the tester through a sequence of steps to
validate whether a software application is free of bugs and working as required
by the end user. Learning how to write test cases for software requires basic
writing skills, attention to detail, and a good understanding of the application
under test.

A test case is a document, which has a set of test data, preconditions,

expected results and postconditions, developed for a particular test scenario
in order to verify compliance against a specific requirement.

Test Case acts as the starting point for the test execution, and after applying
a set of input values, the application has a definitive outcome and leaves the
system at some end point or also known as execution postcondition.

A well-written test case should allow any tester to understand and

execute the test.

When writing test cases, it’s important to put yourself in the user’s shoes and
include all the necessary details. Putting forth the extra effort to write good
test cases upfront will save you time and effort further down the road.

Writing test cases – especially a high volume of them at one time – can be a
time consuming task.

How to write test cases for software:

Use a Strong Title

A good test case starts with a strong title. As a best practice, it’s good to name
the test case along the same lines as the module which you’re testing. For
example, if you’re testing the login page, include “Login Page” within the title
of the test case.

Include a Strong Description

The description should tell the tester what they’re going to test and include
any other pertinent information such as the test environment, test data, and
preconditions/assumptions.

Include Assumptions and Preconditions

You should include any assumptions that apply to the test and any
preconditions that must be met prior to the test being executed. This
information can include which page the user should start the test on,
dependencies on the test environment, and any special setup requirements
that must be done before running the test. This information also helps keep
the test steps short and concise.

Keep the Test Steps Clear and Concise

The test steps should include the data and information on how to execute the
test. This is perhaps the most important part of a test case. Keep this section
clear and concise, but don’t leave out any necessary details.

Include the Expected result

The expected result tells the tester what they should experience as a result of
the test steps. This is how the tester determines if the test case is a “pass” or
“fail”.

Make it Reusable

A good test case is reusable and provides long-term value to the software
testing team. When writing a test case, keep this in mind. You can save time
down the road by re-using the test case instead of re-writing it.

Sample of a Test Case

Title: Login Page – Authenticate Successfully on gmail.com

Description: A registered user should be able to successfully login at

gmail.com.

Precondition: the user must already be registered with an email address and
password.

Assumption: a supported browser is being used.

Test Steps:

1. Navigate to gmail.com
2. In the ’email’ field, enter the email of the registered user.
3. Click the ‘Next’ button.
4. Enter the password of the registered user
5. Click ‘Sign In’

Expected Result: A page displaying the gmail user’s inbox should load,
showing any new message at the top of the page.

----------------------------------------------------------------------------------------------
Typical Test Case Parameters:

 Test Case ID
 Test Scenario
 Test Case Description
 Test Steps
 Prerequisite
 Test Data
 Expected Result
 Test Parameters
 Actual Result
 Environment Information
 Comments

Example:

Let us say that we need to check an input field that can accept maximum of
10 characters.

While developing the test cases for the above scenario, the test cases are
documented the following way. In the below example, the first case is a pass
scenario while the second case is a FAIL.

Scenario Test Step Expected Result Actual Outcome

Verify that the input Login to Application should Application
field that can accept application and be able to accept all accepts all 10
maximum of 10 key in 10 10 characters. characters.
characters characters
Verify that the input Login to Application should Application
field that can accept application and NOT accept all 11 accepts all 10
maximum of 11 key in 11 characters. characters.
characters characters

If the expected result doesn't match with the actual result, then we log a
defect. The defect goes through the defect life cycle and the testers address
the same after fix.