Test Case Notes by Deepak Mitra

What is a Test Case?

Test cases 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 requires basic writing skills, an attention to detail, and a good understanding of the
application under test (AUT).

Typically, test cases for a given module or part of an application, are grouped into a test suite.
More often than not, a test session will include many test cases as there will usually be more
than one specific scenario to be tested.

A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly.

The process of developing test cases can also help find problems in the requirements or design
of an application.

Test Case Template

A test case can have the following elements. Note, however, that a test management tool is
normally used by companies and the format is determined by the tool used.

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 that you are testing. For example, if you’re testing the login
page, include “Login Page” in the title of the test case. In some cases, if the tool you’re using
doesn’t already do this, it might makes sense to include a unique identifier in the title of the test
case as well, so the identifier can be referenced instead of a long title

Include a Strong Description

The description should tell the tester what they’re going to test. Sometimes this section might
also include other pertinent information such as the test environment, test data, and
preconditions/assumptions. A description should be easy to read and immediately communicate
the high-level goal of the test.

Include Assumptions and Preconditions

1
 Test Case Notes by Deepak Mitra

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

Test cases should be simple. Keep in mind, the person who wrote the test case might not be the
same person who executes the the test itself. The test steps should include the necessary 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. Write the
test case so that anyone can go in and perform the test.

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.

Writing Good Test Cases

As far as possible, write test cases in such a way that you test only one thing at a time. Do not
overlap or complicate test cases. Attempt to make your test cases ‘atomic’.

 Ensure that all positive scenarios AND negative scenarios are covered.

Language:

 Write in simple and easy-to-understand language.

 Use active voice instead of passive voice: Do this, do that.
 Use exact and consistent names (of forms, fields, etc).
 Characteristics of a good test case:
 Accurate: Exacts the purpose.
 Economical: No unnecessary steps or words.
 Traceable: Capable of being traced to requirements.

2
 Test Case Notes by Deepak Mitra

 Repeatable: Can be used to perform the test over and over.

 Reusable: Can be reused if necessary.

What Fields Need to be Included in a Test Case?

 Test Case ID: Unique Test Case Identification Number.

 Purpose: A short sentence about what is being tested.
 Prerequisite: Conditions that must be met before the test case can be run. For example,
the user must be logged in.
 Test Data: List of variables and possible values used in the test case. Examples: loginID
= {Valid loginID, invalid loginID, valid email, invalid email, empty} password = {valid,
invalid, empty}
 Test Steps: Detailed steps for test case execution.
 Expected Results: How the application should perform after executing the above testing
steps.
 Actual Results: How application actually behaved after executing the above testing
steps.
 Result: Does the test “Pass” or “Fail”.
 Comments: This is where the tester can add additional helpful information like
screenshots and descriptions to provide the developers with the information they will
need to correct any defects found.

Note: This is a standard test case format. Specific fields may vary from company-to-company.

Test Scenario Vs Test Case

Test scenarios are rather vague and cover a wide range of possibilities. Testing is all about
being very specific.

For a Test Scenario: Check Login Functionality there many possible test cases are:

 Test Case 1: Check results on entering valid User Id & Password

 Test Case 2: Check results on entering Invalid User ID & Password
 Test Case 3: Check response when a User ID is Empty & Login Button is pressed, and
many more

This is nothing but a Test Case.

How to Create a Test Case

3
 Test Case Notes by Deepak Mitra

Let’s create a Test Case for the scenario: Check Login Functionality

Step 1) A simple test case for the scenario would be

Test Case # Test Case Description

1 Check response when valid email and password is entered

Step 2) In order to execute the test case, you would need Test Data. Adding it below

Test Test Case Description Test Data

Case #

1 Check response when valid email and Email: [email protected]:

password is entered lNf9^Oti7^2h

Identifying test data can be time-consuming and may sometimes require creating test data
afresh. The reason it needs to be documented.

Step 3) In order to execute a test case, a tester needs to perform a specific set of actions on the
AUT. This is documented as below:

Test Test Case Description Test Steps Test Data

Case #

4
 Test Case Notes by Deepak Mitra

1 Check response when valid email and 1) Enter Email Email: [email protected]
password is entered Address
Password: lNf9^Oti7^2h
2) Enter
Password

3) Click Sign in

Many times the Test Steps are not simple as above, hence they need documentation. Also, the
author of the test case may leave the organization or go on a vacation or is sick and off duty or
is very busy with other critical tasks. A recently hire may be asked to execute the test case.
Documented steps will help him and also facilitate reviews by other stakeholders.

Step 4) The goal of test cases is to check behavior the AUT for an expected result. This needs
to be documented as below

Test Test Case Description Test Data Expected Result

Case #

1 Check response when valid email and Email: [email protected] Login should be
password is entered Password: lNf9^Oti7^2h successful

During test execution time, the tester will check expected results against actual results and
assign a pass or fail status

Test Test Case Test Data Expected Actual Pass/Fail

Case Description Result Result
#

1 Check response Email: [email protected]: Login Login was Pass

when valid lNf9^Oti7^2h should be successful
email and successful
password is
entered

Step 5) That apart your test case -may have a field like, Pre - Condition which specifies things
that must in place before the test can run. For our test case, a pre-condition would be to have a

5
 Test Case Notes by Deepak Mitra

browser installed to have access to the site under test. A test case may also include Post -
Conditions which specifies anything that applies after the test case completes. For our test
case, a postcondition would be time & date of login is stored in the database

The format of Standard Test Cases

Below is a format of a standard login Test case

Test Test Test Steps Test Data Expected Actual Pass/Fail

Case Scenario Results Results
ID

TU01 Check Go to Userid = User should As Pass

Customer site http://demo.cdac.com admin Login into an Expected
Login with Password = application
Enter UserId
valid Data password
Enter Password

Click Submit

TU02 Check Go to Userid = User should As Pass

Customer site http://demo.cdac.com admin not Login into Expected
Login with Password = an
Enter UserId
invalid Data password application
Enter Password

Click Submit

This entire table may be created in Word, Excel or any other Test management tool. That's all to
Test Case Design

While drafting a test case to include the following information

 The description of what requirement is being tested

 The explanation of how the system will be tested

The test setup like a version of an application under test, software, data files, operating system,
hardware, security access, physical or logical date, time of day, prerequisites such as other
tests and any other setup information pertinent to the requirements being tested

 Inputs and outputs or actions and expected results

6
 Test Case Notes by Deepak Mitra

 Any proofs or attachments

 Use active case language
 Test Case should not be more than 15 steps
 An automated test script is commented with inputs, purpose and expected results

The setup offers an alternative to pre-requisite tests

 With other tests, it should be an incorrect business scenario order

 Best Practice for writing good Test Case Example.

1. Test Cases need to be simple and transparent:

Create test cases that are as simple as possible. They must be clear and concise as the author
of the test case may not execute them.

Use assertive language like go to the home page, enter data, click on this and so on. This
makes the understanding the test steps easy and tests execution faster.

2. Create Test Case with End User in Mind

The ultimate goal of any software project is to create test cases that meet customer
requirements and is easy to use and operate. A tester must create test cases keeping in mind
the end user perspective

3. Avoid test case repetition.

Do not repeat test cases. If a test case is needed for executing some other test case, call the
test case by its test case id in the pre-condition column

4. Do not Assume

Do not assume functionality and features of your software application while preparing test case.
Stick to the Specification Documents.

5. Ensure 100% Coverage

Make sure you write test cases to check all software requirements mentioned in the
specification document.

6. Test Cases must be identifiable.

Name the test case id such that they are identified easily while tracking defects or identifying a
software requirement at a later stage.

7. Implement Testing Techniques

7
 Test Case Notes by Deepak Mitra

It's not possible to check every possible condition in your software application. Software Testing
techniques help you select a few test cases with the maximum possibility of finding a defect.

Boundary Value Analysis (BVA): As the name suggests it's the technique that defines the
testing of boundaries for a specified range of values.

Equivalence Partition (EP): This technique partitions the range into equal parts/groups that tend
to have the same behavior.

State Transition Technique: This method is used when software behavior changes from one
state to another following particular action.

Error Guessing Technique: This is guessing/anticipating the error that may arise while doing
manual testing. This is not a formal method and takes advantages of a tester's experience with
the application

8. Self-cleaning

The test case you create must return the Test Environment to the pre-test state and should not
render the test environment unusable. This is especially true for configuration testing.

9. Repeatable and self-standing

The test case should generate the same results every time no matter who tests it

10. Peer Review.

After creating test cases, get them reviewed by your colleagues. Your peers can uncover
defects in your test case design, which you may easily miss.