0% found this document useful (0 votes)
21 views7 pages

How To Write Test Cases

A test case is a set of actions to verify a software application's functionality, including test steps, data, and expected results. It is essential to document test cases clearly to ensure they can be executed by different testers and to maintain consistency. Best practices for writing test cases include simplicity, user perspective, avoiding repetition, and ensuring full coverage of requirements.

Uploaded by

rajputuday987
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views7 pages

How To Write Test Cases

A test case is a set of actions to verify a software application's functionality, including test steps, data, and expected results. It is essential to document test cases clearly to ensure they can be executed by different testers and to maintain consistency. Best practices for writing test cases include simplicity, user perspective, avoiding repetition, and ensuring full coverage of requirements.

Uploaded by

rajputuday987
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

How to Write Test Cases

Sample Template with Examples

What is a Test Case?


A TEST CASE is a set of actions executed to verify a particular feature or
functionality of your software application. A Test Case contains test steps,
test data, precondition, postcondition developed for specific test scenario to
verify any requirement. The test case includes specific variables or
conditions, using which a testing engineer can compare expected and
actual results to determine whether a software product is functioning as per
the requirements of the customer.

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 are many possible
test cases:

● 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
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 Case # Test Case Description Test Data


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

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 (Application Under Test). This is documented as
below:

Test Case # Test Case Description Test Steps Test Data


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

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 the behavior of AUT for an
expected result. This needs to be documented as below

Test Case # Test Case Description Test Data Expected Result


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

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 Result Actual Pass/Fail


Case # Description Result
1 Check response Email: Login should be Login Pass
when valid email [email protected] successful was
and password is Password: lNf9^Oti7^2h successf
entered ul

Step 5) That apart your test case -may have a field like, Pre - Condition
which specifies things that must be in place before the test can run. For our
test case, a pre-condition would be to have a 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 the format of a standard login Test case

Test Case Test Scenario Test Steps Test Data Expected Actual Pass/Fail
ID Results Results
TU01 Check Userid = User As Pass
Customer Go to site user.name should Expected
Login with valid http://example.co Password = Login into
Data m pass99 an
Enter UserId application
Enter Password
Click Submit
TU02 Check Go to site Userid = User As Pass
Customer http://example.co user.name should not Expected
Login with m Password = Login into
invalid Data Enter UserId glass99 an
Enter Password application
Click Submit

This entire table may be created in Excel or any other specific


format . 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
● 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. Use Traceability Matrix to ensure
no functions/conditions is left untested.

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

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.

You might also like