How to Write Test Cases: The Ultimate Guide with Examples

Last Updated:January 8, 2020

In this in-depth hands-on tutorial on How to Write Test Cases, I have covered the
details of what is a Test Case, Its standard definition and Test Case Design
techniques.

What is a Test case?

A test case has components that describe input, action and an expected response, in
order to determine if a feature of an application is working correctly.

A test case is a set of instructions on “HOW” to validate a particular test

objective/target, which when followed will tell us if the expected behavior of the
system is satisfied or not.

How to write test cases

List of Tutorials Covered in this Test Case Writing Series:

How to Write:

Tutorial #1: What is a Test Case and How to Write Test Cases (this tutorial)
Tutorial #2: Sample Test Case Template with Examples [Download] (must read)
Tutorial #3: Writing Test Cases from SRS Document
Tutorial #4: How to Write Test Cases for a Given Scenario
Tutorial #5: How to Prepare Yourself for Test Case Writing
Tutorial #6: How to Write Negative Test Cases

Examples:

Tutorial #7: 180+ Sample Test Cases for Web and Desktop Applications
Tutorial #8: 100+ Ready-to-Execute Test Scenarios (Checklist)

Writing Techniques:

Tutorial #9: Cause and Effect Graph – Dynamic Test Case Writing Technique
Tutorial #10: State Transition Testing Technique
Tutorial #11: Orthogonal Array Testing Technique
Tutorial #12: Error Guessing Technique
Tutorial #13: Field Validation Table (FVT) Test Design Technique

Test Case Vs Test Scenarios:

Tutorial #14: Test Cases Vs Test Scenarios

Tutorial #15: Difference Between Test Plan, Test Strategy and Test Case

Automation:

Tutorial #16: How to Select Correct Test Cases for Automation Testing
Tutorial #17: How to Translate Manual Test Cases into Automation Scripts

Test Management Tools:

Tutorial #18: Best Test Management Tools

Tutorial #19: TestLink for Test case Management
Tutorial #20: Creating and Managing Test Cases Using HP Quality Center
Tutorial #21: Executing Test Cases Using ALM/QC
Domain Specific Cases:

Tutorial #22: Test Cases for ERP Application

Tutorial #23: JAVA Application test cases
Tutorial #24: Boundary value analysis and Equivalence partitioning

Let's continue with the first tutorial in this series.

Recommended Tools:

Before continuing to the test case writing process, we recommend downloading this
test case management tool. This will ease your test cases writing process mentioned
in this tutorial:

#1) TestRail

=> Download TestRail Test Case Management Tool

Test case 728

#2) TestMonitor

Top-level online Test Management. Revolutionary easy.

TestMonitor is an end-to-end test management tool for every organization. A simple,

intuitive approach to testing. Whether you’re implementing enterprise software,
need QA, building a quality app or just need a helping hand in your test project,
TestMonitor has you covered.

TestMonitor

=> Visit TestMonitor Website

What You Will Learn: [show]

What is a Test Case and How to Write Test Cases?

Writing effective cases is a skill. And you can learn it from experience and
knowledge of the application under test.

For basic instructions on how to write tests, please check the following video:

The above resources should give us the basics of the test writing process.

Levels of the test writing process:

Level 1: In this level, you will write the basic cases from the available
specification and user documentation.
Level 2: This is the practical stage in which writing cases depend on the
actual functional and system flow of the application.
Level 3: This is the stage in which you will group some cases and write a test
procedure. The test procedure is nothing but a group of small cases, maybe a
maximum of 10.
Level 4: Automation of the project. This will minimize human interaction with
the system and thus the QA can focus on the currently updated functionalities to
test rather than remaining busy with Regression testing.

Why do we Write Tests?

The basic objective of writing cases is to validate the test coverage of an

application.

If you are working in any CMMi organization, then the test standards are followed
more closely. Writing cases brings some sort of standardization and minimizes the
ad-hoc approach in testing.
How to Write Test Cases?

Fields:

Test case id
Unit to test: What to be verified?
Assumptions
Test data: Variables and their values
Steps to be executed
Expected Result
Actual result
Pass/Fail
Comments

Basic Format of Test Case Statement

Verify
Using [tool name, tag name, dialog, etc]
With [conditions]
To [what is returned, shown, demonstrated]

Verify: Used as the first word of the test statement.

Using: To identify what is being tested. You can use ‘entering’ or ‘selecting’ here
instead of using depending on the situation.

For any application, you need to cover all types of tests as:

Functional cases
Negative cases
Boundary value cases

While writing these all your TC's should be simple and easy to understand.

************************************************
Tips for Writing Tests

One of the most frequent and major activities of a Software Tester (SQA/SQC person)
is to write Test scenarios and cases.

There are some important and critical factors that are related to this major
activity. Let us have a bird’s eye view of those factors first.

Important Factors Involved Writing Process:

a) TCs are prone to regular revision and update:

We live in a continuously changing world and the same holds good for software as
well. Software requirements change directly impact the cases. Whenever requirements
are altered, TCs need to be updated.

Yet, it is not only the change in the requirement that may cause revision and
update of TCs. During the execution of TCs, many ideas arise in the mind and many
sub-conditions of a single TC may be identified. All this causes an update of TCs
and sometimes it even leads to the addition of new TCs.
Moreover, during regression testing, several fixes and/or ripples demand revised or
new TCs.

b) TCs are prone to distribution among the testers who will execute these:

Of course, there is hardly such a situation in which a single tester executes all
the TCs. Normally, there are several testers who test different modules of a single
application. So the TCs are divided among the testers according to their owned
areas of the application under test.

Some TCs which are related to the integration of application may be executed by
multiple testers while the other TCs may be executed only by a single tester.

c) TCs are prone to Clustering and Batching:

It is normal and common that TCs belonging to a single test scenario usually demand
their execution in some specific sequence or in the form of a group. There may be
certain pre-requisites of a TC which demand the execution of other TCs before
running itself.

Similarly, as per the business logic of the AUT, a single TC may contribute to
several test conditions and a single test condition may consist of multiple TCs.

d) TCs have a tendency of inter-dependence:

Test Cases have a tendency of inter-dependence

This is also an interesting and important behavior of the TCs denoting that they
can be interdependent on each other. From medium to large applications with complex
business logic, this tendency is more visible.

The clearest area of any application where this behavior can definitely be observed
is the interoperability between different modules of the same or even different
applications. Simply speaking, wherever the different modules a single application
or multiple applications are interdependent, the same behavior is reflected in the
TCs as well.

e) TCs are prone to distribution among the developers (especially in Test-driven

development environment):

An important fact about TCs is that these are not only to be utilized by the
testers. In the normal case, when a bug is under fix by the developers, they are
indirectly using the TC to fix the issue. Similarly, if the test-driven development
is followed, then TCs are directly used by the developers in order to build their
logic and cover all the scenarios in their code which are addressed by TCs.

test cases writing tips

Tips to Write Effective Tests:

Keeping the above 5 factors in mind, Here are a few tips to write effective TCs.

Let's start!!!
#1) Keep it simple but not too simple; make it complex but not too complex:

This statement seems a paradox. But, I promise that it is not so. Keep all the
steps of TCs atomic and precise. Mention the steps with the correct sequence and
correct mapping to the expected results. The test case should be self-explanatory
and easy to understand. This is what I mean to make it simple.

Now, making it a complex means to make it integrated with the Test Plan and other
TCs. Refer to the other TCs, relevant artifacts, GUIs etc. where and when required.
But, do this in a balanced way. Do not make a tester to move to and fro in the pile
of documents for completing a single test scenario.

On the other hand, do not even let the tester to document these TCs in a very
compact manner. While writing TCs, always remember that you or someone else will
have to revise and update these.
#2) After documenting the Test cases, review once as Tester:

Test cases

Never think that the job is done once you have written the last TC of the test
scenario. Go to the start and review all the TCs once, but not with the mindset of
a TC writer or Testing Planner. Review all TCs with the mind of a tester. Think
rationally and try to dry run your TCs.

Evaluate that all the Steps and see if you have mentioned these clearly in an
understandable way and the expected results are in harmony with those steps.

Ensure that the test data specified in TCs is feasible not only for actual testers
but is according to the real-time environment too. Ensure that there is no
dependency conflict among TCs and verify that all the references to other
TCs/artifacts/GUIs are accurate. Otherwise, the Testers may be in great trouble.
#3) Bound as well as ease the Testers:

Do not leave the test data on testers. Give them a range of inputs especially where
calculations are to be performed or application's behavior is dependent on inputs.
You can let them decide the test data item values but never give them the liberty
to choose the test data items themselves.

Because, intentionally or unintentionally, they may use the same test data again &
again and some important test data may be ignored during the execution of TCs.

Keep the testers at ease by organizing the TCs per the testing categories and the
related areas of an application. Clearly, instruct and mention which TCs are inter-
dependent and/or batched. Likewise, explicitly indicate which TCs are independent
and isolated so that the tester may manage his overall activity accordingly.

At this point, you might be interested to read about boundary value analysis which
is a test case design strategy that is used in black box testing. Click here to
know more about it.
#4) Be a Contributor:

Be a Contributor

Never accept the FS or Design Document as it is. Your job is not just to go through
the FS and identify the Test Scenarios. Being a QA resource, never hesitate to
contribute to business and give suggestions if you feel that something can be
improved in the application.

Suggest to developers too, especially in TC-driven development environment. Suggest

the drop-down lists, calendar controls, selection-list, group radio buttons, more
meaningful messages, cautions, prompts, improvements related to usability, etc.

Being a QA, don’t just test but make a difference!

#5) Never Forget the End User:
Never Forget the End User

The most important stakeholder is the ‘End User' who will finally use the
application. So, never forget him at any stage of TCs writing. In fact, the End
User should not be ignored at any stage throughout the SDLC. Yet, my emphasis so
far is just related to my topic.

So, during the identification of test scenarios, never overlook those cases which
will be mostly used by the user or the cases which are business critical even if
they are less frequently used. Keep yourself in the shoes of End User and then go
through all the TCs and judge the practical value of executing all your documented
TCs.

************************************************
How to Achieve Excellence in Test Case Documentation

Being a software tester, you will surely agree with me that coming up with a
perfect Test Document is really a challenging task.

We always leave some scope for improvement in our Test Case Documentation.
Sometimes, we are unable to provide 100% test coverage through the TCs and at
times, the test template is not up to par, or we lack in providing good readability
and clarity to our tests.

As a tester, whenever you are asked to write test documentation, do not just start
away in an ad-hoc manner. It is very important to understand the purpose of writing
test cases well before you work on the documentation process.

Achieve Excellence in Test Case Documentation

The tests should always be clear and lucid. They should be written in a way that
offers the tester ease to conduct the complete testing by following the steps
defined in each of the tests.

In addition, the test case document should contain as many cases as required to
provide complete test coverage. For Example, you should try to cover the testing
for all the possible scenarios that can occur within your software application.

Keeping the above points in mind, let me now take you through a tour about How to
Achieve Excellence in Test Documentation.
Useful Tips and Tricks

Here, I am going to provide you some useful guidelines that can give you a leg up
in your test documentation from the others.
#1) Is your Test Document in Good Shape?

The best and simple way to organize your test document is by splitting it into many
single useful sections. Divide the entire testing into multiple test scenarios.
Then divide each scenario into multiple tests. Finally, divide each case into
multiple test steps.

If you are using excel, then document each test case on a separate sheet of the
workbook wherein each test case describes one complete test flow.
#2) Do not Forget to Cover the Negative Cases

As a software tester, you need to think outside the box and draw up all the
possibilities that your application comes across. We, as testers, have to verify
that if any unauthentic attempt to enter into the software or any invalid data to
flow across the application should be stopped and reported.

Thus, a negative case is as important as a positive case. Make sure that for each
scenario you have two test cases- one positive and one negative. The positive one
should cover the intended or normal flow and the negative one should cover the
unintended or exceptional flow.
#3) Have Atomic Test Steps

Each test step should be an atomic one. There should not be any further sub-steps.
The more simple and clear-headed a test step is, the easier it would be to proceed
with the testing.
#4) Prioritize the Tests

We often have stringent timelines to finish up testing for an application. In this

case, we may miss testing some of the important functionalities and aspects of the
software. In order to avoid this, you should tag a priority with each test while
documenting it.

You can use any encoding for defining the priority of a test. It is generally
better to use any of the 3 levels, high, medium and low, or 1, 50 and 100. So, when
you have a strict timeline, you should complete all the high priority tests first
and then move to the medium and low priority tests.

For Example – for a shopping website, verifying access denial for an invalid
attempt to log into the app can be a high priority case, verifying the display of
relevant products on the user screen can be a medium priority case and verifying
the color of the text displayed on the screen buttons can be a low priority test.
#5) Sequence Matters

Confirm whether the sequence of steps in the test is absolutely correct. A wrong
sequence of steps can lead to confusion. Preferably, the steps should also define
the entire sequence from entering the app until exiting the app for a particular
scenario that is being tested.
#6) Add Timestamp and the Tester Name to the Comments

There may be a case where you are testing an application, someone is making
modifications in parallel to the same app or someone may update the app after your
testing is done. This leads to a situation where your test results can vary with
time.

So, it is always better to add
comments so that a test result
application at that particular
column added separately to the
timestamp of the test.
#7) Include Browser Details
a timestamp with the tester's name in the testing
(pass or fail) can be attributed to the state of an
time. Alternatively, you can have an ‘Executed Date’
test case which will explicitly identify the

As you know, if it’s a web application, test results can differ based on the
browser on which the test is executed. For the ease of other testers, developers or
whoever is reviewing the test document, you should add the browser name and version
to the case so the defect can be replicated easily.
#8) Keep two separate sheets – ‘Bugs’ & ‘Summary’ in the Document

If you are documenting in an excel, then the first two sheets of the workbook
should be Summary and Bugs. The Summary sheet should summarize the test scenario
and the Bugs sheet should list all the issues encountered during testing. The
significance of adding these two sheets is that it will give a clear understanding
of the testing to the reader/user of the document.
So, when the time is restricted, these two sheets can prove to be very useful in
providing an overview of the testing.

The test document should provide the best possible test coverage, excellent
readability and should follow one standard format throughout.

We can achieve excellence in test documentation by just keeping few essential tips
in mind as the organization of test case document, prioritizing the TCs, having
everything in proper sequence, including all mandatory details to execute a TC, and
providing clear & lucid test steps, etc. as discussed above.

************************************************
How NOT to Write Tests

We spend most of our time writing, reviewing, executing or maintaining these. It is

quite unfortunate that tests are also the most error-prone ones. The differences in
understanding, organization testing practices, lack of time etc. are some of the
reasons why we often see tests that leave a lot to be desired.

There are a lot of articles on our site on this topic, but here will see How NOT to
write test cases – a few tips that will be instrumental in creating distinctive,
quality and effective tests.

Let’s read on and please note that these tips are for both new and experienced
testers.

how not to write test cases

3 Most Common Problems in Test Cases

Composite steps
Application behavior is taken as expected behavior
Multiple conditions in one case

These three have to be on my top 3 list of common problems in the test writing
process.

What’s interesting is that these happen with both new and experienced testers and
we just keep following the same flawed processes never realizing that a few simple
measures can fix things easily.

Let’s get to it and discuss each one in detail:

#1) Composite Steps

First of all, what is a composite step?

For instance, you are giving directions from Point A to point B: if you say that
“Go to XYZ place and then to ABC” this is not going to make a lot of sense, because
here we find ourselves thinking – “How do I get to XYZ in the first place”- instead
starting with “Turn left from here and go 1 mile, then turn right on Rd. no 11 to
arrive at XYZ” might achieve better results.

The exact same rules apply to tests and its steps as well.

For Example I am writing a test for Amazon.com – place an order for any product.

The following are my test steps (Note: I am only writing the steps and not all the
other parts of the test like the expected result etc.)

a. Launch Amazon.com
b. Search for a product by entering the product keyword/name into the “Search”
field on the top of the screen.
c. From the search results displayed, choose the first one.
d. Click on Add to Cart on the product details page.
e. Checkout and pay.
f. Check the order confirmation page.

Now, can you identify which of these is a composite step? Right- Step (e)

Remember, tests are always about “How” to test so it is important to write the
exact steps of “How to check out and pay” in your test.

Therefore, the above case is more effective when written as below:

a. Launch Amazon.com
b. Search for a product by entering the product keyword/name into the “Search”
field on the top of the screen.
c. From the search results displayed, choose the first one.
d. Click on Add to Cart on the product details page.
e. Click on Checkout in the shopping cart page.
f. Enter the CC information, shipping, and billing information.
g. Click Checkout.
h. Check the order confirmation page.

Therefore, a composite step
individual steps. Next time
part and I am sure you will
realize.
#2) Application behavior is
is the one that can be broken down into several
when we write tests, let’s all pay attention to this
agree with me that we do this more often than we
taken as expected behavior

More and more projects have to deal with this situation these days.

Lack of documentation, Extreme programming, rapid development cycles are few

reasons that force us into relying on the application (an older version or so) to
either write the tests or to base the testing itself on. As always, this is a
proven bad practice- not always really.

It is harmless as long as you keep an open mind and keep the expectation that the
–“AUT could be flawed”. It is only when you do not think that it is, things work
badly. As always, we will let the examples do the talking.

If the following is the page you are writing/designing the test steps for:

tips for test cases

Case 1:

If my test case steps are as below:

Launch the shopping site.

Click on Shipping and return- Expected result: The shipping and returns page is
displayed with “Put your info here” and a “Continue” button.

Then, this is incorrect.

Case 2:

Launch the shopping site.

Click on Shipping and return.
 In the ‘Enter the order no’ text box present in this screen, enter the order
no.
Click Continue- Expected result: The details of the order related to shipping
and returns are displayed.

Case 2 is a better test case because even though the reference application behaves
incorrectly, we only take it as a guideline, do further research and write the
expected behavior as per the anticipated correct functionality.

Bottom line: Application as a reference is a quick shortcut but it comes with its
own perils. As long as we are careful and critical, it produces amazing results.
#3) Multiple Conditions in one case

testing meme

Once again, let’s learn from Example.

Take a look at the below test steps: The following are the test steps within one
test for a login function.

a. Enter valid details and click Submit.

b. Leave Username field empty. Click Submit.
c. Leave the password field empty and click Submit.
d. Choose an already logged in username/password and click Submit.

What had to be 4 different cases is combined into one. You might be thinking-
What’s wrong with that? It is saving a lot of documentation and what I can do in 4,
I am doing it in 1- isn’t that great? Well, not quite. Reasons?

Read on:

What if one of the conditions fails – we have to mark the entire test as
‘failed’. If we mark the entire case ‘failed’, it means all 4 conditions are not
working, which isn’t really true.
Tests need to have a flow. From precondition to step 1 and all through the
steps. If I follow this case, in step (a), if it is successful, I will be logged
onto the page, where the “login” option is no longer available. So when I get to
step (b) – where is the tester going to enter the username? You see, the flow is
broken.

Hence, write modular tests. It sounds like a lot of work but all it takes for you
is to separate things and use our best friends Ctrl+C and Ctrl+V to work for us. :)

************************************************
How to Improve Test Case Efficiency

The software testers should write their tests from the earlier stage of the
software development life cycle, best during the software requirements phase.

The test manager or a QA manager should collect and prepare the maximum possible
documents as per the below list.

test case efficiency

Document Collection for Test Writing

#1) User Requirements Document

It is a document that lists the business process, user profiles, user environment,
interaction with other systems, replacement of existing systems, functional
requirements, non-functional requirements, licensing and installation requirements,
performance requirements, security requirements, usability and concurrent
requirements etc.,

#2) Business Use Case Document

This document details the use case scenario of the functional requirements from the
business perspective. This document covers the business actors (or system), goals,
pre-conditions, post-conditions, basic flow, alternate flow, options, exceptions of
each and every business flow of the system under requirements.

#3) Functional Requirements Document

This document details the functional requirements of each feature for the system
under requirements.

Normally, functional requirements document serves as a common repository for both

the development and testing team as well as to the project stakeholders including
the customers for the committed (sometimes frozen) requirements, which should be
treated as the most important document for any software development.

#4) Software Project Plan (Optional)

A document which describes the details of the project, objectives, priorities,

milestones, activities, organization structure, strategy, progress monitoring, risk
analysis, assumptions, dependencies, constraints, training requirements, client
responsibilities, project schedule etc.,

#5) QA/Test Plan

This document details the quality management system, documentation standards,

change control mechanism, critical modules, and functionalities, configuration
management system, testing plans, defect tracking, acceptance criteria etc.

The test plan document is used to identify the features to be tested, features not
to be tested, testing team allocations and their interface, resource requirements,
testing schedule, test writing, test coverage, test deliverables, pre-requisite for
test execution, bug reporting and tracking mechanism, test metrics etc.,
Real Example

Let us see how to efficiently write test cases for a familiar and simple ‘Login’
screen as per the figure below. The approach of testing will be almost the same
even for complex screens with more information and critical features.

Test Case efficiency 2

#1) The first approach for any test case process will be to get a screen prototype
(or wire-frames) as above, if available. This may not be available for some of the
functionalities and depends on the criticality of designing a prototype in the
earlier stages of development.

But, if an SRS (Software Requirements Specification) document is available for the

project, most of the screen prototypes are developed by the project team. This kind
of screen simplifies the tester's job and increases the efficiency of tests.

#2) Next, the functional requirements specifications. It depends on the

organization process, it will be available in a suite of multiple documents.

So, decide the best document for writing cases, either it may be a user requirement
document or a functional requirements specifications (or even an SRS document if it
can be understandable comfortably by the testing team) which will give a complete
functional flow of the selected feature to be tested.

#3) Once the screen prototype and functional specifications are in place, the
tester should start writing the cases with the following approach and criteria.

UI Tests: The controls/fields which are visible to the user. There are static
control and dynamic controls available for the feature to be tested. For Example,
in the login screen above, the ‘User Name & Password’ texts are static fields which
require no user interaction, just for displaying the text only.

Functional Cases: On the other hand, Login button and the Hyperlinks (Forgot
Password? & Registration) are dynamic fields which require user interaction by
clicking on the controls, which will do some action afterward.

Database Cases: Once the user enters the username and password, the tests may
be written to check the related database for, whether the username & password is
checked in the right database and table and also the user has the permission to
login to the application under test.

Process Tests: This is related to the process (not the actions associated with
the visible controls available on the screen) associated with the feature and the
functionality. For Example, clicking Forgot Password link in the above sample
screen may send an Email to the user. So, maybe an Email needs to be tested for the
proper process and confirmation.

4) Finally, keep the “BAOE mantra”, means i) Basic Flow ii) Alternate Flow iii)
Options and iv) Exceptions for the complete coverage of the functional flow and
feature to be tested. Every concept should be applied to positive and negative
tests.

For Example, let us see the simple BAOE approach for the sample login screen above.

Basic Flow: Enter the URL path of the Login in any browser and enter the
information required and login to the application.
Alternate Flow: Install the application on a mobile device and enter the
information required and login to the application.
Options: What are the options available to come to the same login screen? For
Example, after login to the application, clicking ‘Logout’ may bring the same
screen or if the session timeout or session expired, the user may come to the login
screen.
Exceptions: What are exceptions if my tests are negative? For Example, if wrong
credentials are entered in the Login screen, whether the user will get an error
message or no action associated.

With all this information in hand, let us start writing the TCs for the login
screen, in a format with the complete coverage and traceability and with detailed
information. The logical sequence and numbering of identifying the ‘Test Case ID’
will be very useful for a quick identification execution history of test cases.

Also read => 180+ sample ready to use test cases for web and desktop applications.
Test Case Document

Test Case efficiency 1

Test Execution History

Test Execution History 2

Note: The test columns are not limited to the below sample test document, which can
be maintained in an excel sheet to have as many columns as required for a complete
traceability matrix viz., priority, purpose of testing, type of testing, error
screenshot location etc.,

Also read => Sample test case template with examples.

test cases

For the ease of simplicity and readability of this document, let us write the steps
to reproduce, expected and actual behavior of the tests for the login screen in
detail below.

Note: Add Actual Behavior column at the end of this template.

No. Steps to Reproduce Expected Behaviour
1. Open a browser and enter the URL for the Login screen. The Login screen
should be displayed.
2. Install the app in Android phone and open it. The Login screen should be
displayed.
3. Open the Login screen and check the texts available are correctly spelled.
‘User Name’ & ‘Password’ text should be displayed before the related text
box. Login button should have the caption ‘Login’. ‘Forgot Password?’ And
‘Registration’ should be available as Links.
4. Enter the text in the User Name box. Text can be entered by mouse click
or focus using tab.
5. Enter the text in the Password box. Text can be entered by mouse click or
focus using tab.
6. Click the Forgot Password? Link. Clicking the link should take the user to
the related screen.
7. Click the Registration Link Clicking the link should take the user to the
related screen.
8. Enter the user name and password and click the Login button. Clicking the
Login button should take to the related screen or application.
9. Go to the database and check the correct table name is validated against the
input credentials. The table name should be validated and a status flag should
be updated for successful or failure login.
10. Click the Login without entering any text in the User Name and Password
boxes. Click the Login button should alert a message box ‘User Name and
Password are Mandatory’.
11. Click the Login without entering text in the User Name box, but entering text
in Password box. Click the Login button should alert a message box ‘Password is
Mandatory’.
12. Click the Login without entering text in the Password box, but entering text
in User Name box. Click the Login button should alert a message box ‘User Name is
Mandatory’.
13. Enter the maximum allowed text in the User Name & Password boxes. Should
accept the maximum allowed 30 characters.
14. Enter the User Name & Password starting with the special characters. Should
not accept the text starting with special characters, which is not allowed in
Registration.
15. Enter the User Name & Password starting with blank spaces. Should not accept
the text stating with blank spaces, which is not allowed in Registration.
16. Enter the text in the password field. Should not display the actual text
instead should display asterisk * symbol.
17. Refresh the Login page. Page should be refreshed with both User Name and
Password fields blank.
18. Enter the User Name. Depends on the browser auto fill settings, previously
entered user names should be displayed as a dropdown.
19. Enter the Password. Depends on the browser auto fill settings, previously
entered Passwords should NOT be displayed as a dropdown.
20. Move the focus to Forgot Password link using Tab. Both mouse click and
enter key should be usable.
21. Move the focus to Registration link using Tab. Both mouse click and enter
key should be usable.
22. Refresh the Login page and press Enter key. The Login button should be
focussed and the related action should be fired.
23. Refresh the Login page and press Tab key. The first focus in the Login screen
should be the User Name box.
24. Enter the User and Password and leave the Login page idle for 10 minutes.
Message box alert ‘Session Expired, Enter User Name & Password Again’ should
be displayed with both User Name & Password fields cleared.
25. Enter the Login URL in Chrome, Firefox & Internet Explorer browsers. Same
Login screen should be displayed without much deviation on the look and feel and
alignment of text and form controls.
26. Enter the Login credentials and check Login activity in Chrome, Firefox &
Internet Explorer browsers. The action of Login button should be one and the same
in all the browsers.
27. Check the Forgot Password and Registration link is not broken in Chrome,
Firefox & Internet Explorer browsers. Both the links should take to the
relative screens in all the browsers.
28. Check the Login functionality is working properly in Android mobile Phones.
The Login feature should work the same way as it is available in the web
version.
29. Check the Login functionality is working properly in Tab and iPhones. The
Login feature should work the same way as it is available in the web version.
30. Check the Login screen allows the concurrent users of the system and all the
users are getting the Login screen without delays and within the defined time of 5-
10 seconds. This should be achieved using many combination of operating system and
browsers either physically or virtually or can be achieved using some performance /
load testing tool.
Test Data Collection

When the test case is being written, the most important task for any tester is to
collect the test data. This activity is skipped and overlooked by many testers with
the assumption that the test cases can be executed with some sample data or dummy
data and can be feed when the data is really required. This is a critical
misconception that feeding sample data or input data from the mind memory at the
time of executing test cases.

If the data is not collected and updated in the test document at the time of
writing the tests, the tester would spend abnormally more time to collect the data
at the time of test execution. The test data should be collected for both positive
and negative cases from all the perspective of the functional flow of the feature.
The business use case document is very much useful in this situation.

Find a sample test data document for the tests written above, which in turn will be
helpful on how effectively we can collect the data which will ease our job at the
time of test execution.
Sl.No. Purpose of Test Data Actual Test Data
1. Test the proper user name and password Administrator (admin2015)
2. Test the maximum length of user name and password Administrator of the
Main System (admin2015admin2015admin2015admin)
3. Test the blank spaces for the user name and password Enter blank spaces using
space key for user name and password
4. Test the improper user name and password Admin (Activated) (digx##$taxk209)
5. Test the user name and password with uncontrolled spaces between. Admin
istrator (admin 2015)
6. Test the user name and password starting with special characters $
%#@#$Administrator (%#*#**#admin)
7. Test the user name and password with all small characters administrator
(admin2015)
8. Test the user name and password with all capital charactersADMINISTRATOR
(ADMIN2015)
9. Test the Login with the same user name and password with multiple systems
concurrently at the same time. Administrator (admin2015) - for Chrome in the
same machine and different machine with operating system Windows XP, Windows 7,
Windows 8 and Windows Server.

Administrator (admin2015) - for Firefox in the same machine and different machine
with operating system Windows XP, Windows 7, Windows 8 and Windows Server.

Administrator (admin2015) - for Internet Explorer in the same machine and different
machine with operating system Windows XP, Windows 7, Windows 8 and Windows Server.
10. Test the Login with the user name and password in the mobile application.
Administrator (admin2015) – for Safari and Opera in Android Mobiles, iPhones
and Tablets.

************************************************
Importance of Standardizing the Test Cases

In this busy world, no one can do repetitive things day in and day out with the
same level of interest and energy. Especially, I am not passionate about doing the
same task again and again at work. I like managing things and saving time. Anyone
in IT should be so.

All IT companies execute different types of projects. These projects can either be
product based or service based. Out of these projects, most of them work around
websites and website testing. The good news about it is, all websites have many
similarities. And, if the websites are for the same domain, they have several
common features too.

Test case reuse

The question that always baffles me is that: “If most applications are similar, for
example: such as retail sites, which have been tested a thousand times before, “Why
do we need to write test cases for yet another retail site from scratch?” Won’t it
save a ton of time by pulling out the existing test scripts that were used to test
a previous retail site?

Sure, there might be some small tweaks that we might have to do, but overall it is
easier, efficient, time & money-saving too and thereby always helps to keep the
interest levels of the testers high. Who likes to write, review and maintain the
same test cases repeatedly, right? Reusing the existing tests can solve this to a
great extent and your clients will find this smart and logical too.

So logically, I started pulling the existing scripts from similar web-based

projects, made changes and did a quick review of them. I also used color coding to
show the changes that were made, so that the reviewer can only focus on the part
that has been changed.
Reasons to Reuse Test Cases

#1) Most functional areas of a website are almost- login, registration, add to
cart, wish list, checkout, shipping options, payment options, product page content,
recently viewed, relevant products, promo code facilities etc.

#2) Most of the projects are just enhancements or changes to the existing
functionality.

#3) Content management systems that define the slots for image uploads with static
and dynamic ways is also common for all websites.

#4) Retail websites have CSR (Customer Service) system too.

#5) Backend system and warehouse application using JDA are also used by all
websites.

#6) The concept of cookies, timeout and security are common too.

#7) Web-based projects are frequently prone to requirement changes.

#8) The types of testing needed are common like browser compatibility testing,
performance testing, security testing

You see, there is plenty that is common and similar.

Having said that reusability is the way to go, sometimes the modifications
themselves may or may not take more or less time. Sometimes one may feel it is
better to start from scratch than to modify so much.

This can be easily handled by creating a set of standard test cases for each of the
common functionality.
What is a Standard Test in Web Testing?

Create test cases that are complete – steps, data, variable, etc. This will
ensure that the non-similar data/variable can simply be replaced when a similar
test case is required.
The entrance and exit criteria should be properly defined.
The modifiable steps or the statement in the steps should be highlighted in a
different color for quick find and replace.
The language used for the standard test case creation should be generic.
All the features of each website should be covered in the test cases.
The name of the test cases should be the name of the functionality or the
feature that the test case is covering. This will make the finding of the test case
from the set much easier.
If there is any basic or standard sample or GUI file or screenshot of the
feature, then it should be attached with the relevant steps.

By using the above tips one can create a set of standard scripts and use them with
little or required modifications for different websites.

These standard test cases can be automated too, but once again focusing on
reusability is always a plus. Also, if automation is based on a GUI, reusing the
scripts across multiple URLs or sites is something I personally never found
effective.

Using a standard set of manual test cases for different websites with minor
modifications is the best way to carry a website testing. All we need is to create
and maintain the test cases with proper standards and use.
Conclusion

Improving Test Case Efficiency is not a simply defined term, but it’s an exercise
and can be achieved through a matured process and regular practice.

The testing team should not be tired of getting involved in the improvement of such
tasks as it is the best tool for greater achievements in the quality world, this is
proven in many of the testing organizations worldwide on mission-critical projects
and complex applications.

Hope you would have gained immense knowledge on the concept of Test Cases. Watch
out our series of tutorials to know more about test cases and feel free to express
your thoughts in the comments section below!

Next Tutorial
Recommended Reading

Functional Testing Vs Non-Functional Testing

Portability Testing Guide with Practical Examples
Types of Software Testing: Different Testing Types with Details
QA Testing Tools
Alpha Testing and Beta Testing (A Complete Guide)
What is System Testing - A Ultimate Beginner's Guide
ISTQB Testing Certification Sample Question Papers With Answers
How to Write Software Testing Weekly Status Report

Categories Manual Testing, Software Testing Templates

Post navigation
How to Write Software Testing Weekly Status Report
How To Get Software Testing Job Quickly
799 thoughts on “How to Write Test Cases: The Ultimate Guide with Examples”
Comment navigation
← Older Comments

sachin

i am a new software tester. please anyone provide me TCs with example….

thank u
Reply
kiran

Write TC for
Innsurance company has to send mail to policy holders but condition is
1. Mail has to send 5 days before due date
Reply
Naseem Ahmad

how to write TCs in live project.

pls give me format in my regards id

thanks
Reply
pavithra

hi i am new to testing,please any body send me some sample TC documents , it

will be very useful for me.
Reply
pavi

hi,please anyone send me some TC document

my id- pavithra.anus50@gmail.com
Reply
VENKATESH

Please send me if anyone sent you.

Reply
 Gururaj

Hi Tiger,
I am looking for a testing job.

Kindly help me to learn real time like writting TCs and preparing test
stratgies.

please forward TCs for ATM Machine application and how to rate severity and
priority in defect tracking

Regards
Gururaj
Reply
narasimha

hi friends this is narasimha

how to extract the real time test scripts
can any one help me
Reply
Kannagi

Hi Frnds,
Can u please write the TC for ATM.
Reply
Aniket

Its very useful content….

Reply
Aniket

Its very benifacial information.

Reply
Prasanna

If possible please send the TCs format to my mail id. my mail id is

prassyravula@gmail.com
Reply
ismail

pls help me how to write TC and how to thinking test scenarios pls send my mail
id Mohdismail1805@gmail.com
Reply
gokul

Hi Vijay,
thanks for giving TC information.
it was very help full.
Reply
Ajay

Hi
Suppose I m executing TC but unfortunately I skip some Error but Client got
that error and inform to our team then
what step I will take N how it will b resolve
Reply
pramod

Hello
 may i get some sample TCs with example and explaination.
Reply
VENKATESH

Please send to me
Reply
pramod

send on pramod.wanjari@yahoo.com
Reply
Raju

Nice and good artical.

Reply
wasim ashraf

how to test scanerio of a website and its functionality.how does it

work??????????
Reply
Satyanarayan Nohanty

With a payroll clerk about the payment of sales commission,youwerw told that
most sales persons are paid a basic plus 3 percent of sales if more then 100 units
of the product are sold,4 percent of sales if more yhan 125 units of the products
are sold.
A sales person can elect to sign a special contract called type A
contrat,however where by no sales commissin is paid until sales exceeds 125 units
of the product.With type a contracts,sales commision are then pain at the rate of 6
percent of sales.
input data:
Basic =10,000/-
1 unir==1000/-

can anyone help me what to write TCs with this documents

Reply
Rakesh

I’m a fresher and I got a job as Test Trainee and my domain and job description
is
Domain
IT – Testing to deliver TC execution, defect logging & TC writing.

Job description

Perform daily test execution towards identifying defects/issues and help

deliver on timeEnsure workflow completion and accuracy to meet high volume and
aggressive deliverable timelines Meet Service Level Agreements / Key Performance
Indicators as per the GuidelinesProvide support through adherence to Standard
Operating Procedure (SOP) for various project enhancements & ongoing project
efforts.

How well I can go for it any future for my domain :) Thanks in Advance :) :)
Reply
abu

pls sent me sample TC

abufarook92@gmail.com
Reply
Omar
 very usfel
Reply
TakeJob Job Portal

Asking questions are in fact pleasant thing if you are not understanding
something totally, but this article presents pleasant understanding even.
Reply
Sucheta

What is a TC ? Can anyone tell me with an example. How to write TCs?

Reply
Vinayak

Pls. give me anyone standard flow of writing TCs with any example,pls it’s very
urgent.
This is my email ID gaikwad.vin89@gmail.com
Reply
Shiva Balaji

Here we involved actual result and pass/fail criteriacolumn in TC, but i’ve sen
that we involve actual result and pass/fail criteria in test report only.

Kindly clarify this doubt.

Reply
sasi

Hello
may i get some sample TCs with example and explaination.
Reply
Nikhilesh

we write same TC for automation testing as well ? like as we write for manual
testing
Reply
Jane

Your series of articles on writing TCs is excellent. They are clearly written
and provide sound advice.

My question is how do you transfer a comprehensive TC, written in Excel, to

Microsoft TC Manager.

Thanks for your help,

Jane
Reply
Vino

Hi ,

can any one give some sample TCs with example and explaination please. i am new
in manual testing
Reply
Nikita D. Talele

Hi vijay . thanks for sharing such a imp info with us! can u also provide me
with a sample TC , a perfect sample with all inputs, explanation, actual and
expected result. I have written TC which cover every single click action and also
covered all the related modules in my TC sheet. I am also using Google Sheet to
write TCs.
Reply
prameela

can anyone send me a sample to TC to my id prameela5sep@gmail.com. thanks!

Reply
Vasantha

hi
plz send me 10 cases of testing for yahoo compose mail,its urgent .i need it
for my interview.on its basis company will select me.on monday i hav my
interview.so plz help me.i’ll be thanful to u.
Reply
Vasantha

hi
plz send me 10 cases of testing for yahoo compose mail,its urgent .i need it
for my interview.on its basis company will select me.on monday i hav my
interview.so plz help me.i’ll be thanful to u. My email is vks_52002@yahoo.com
Reply
danu

hi.. i want socket programmming in java TCs plz provide me..its too urgent.plz
provide me as soon as possible
Reply
Praveen Yelsangi

can anyone send me a sample to TCs to my id praveen.yelsangi@gmail.com

Thanks in advance
Reply
sreejith

can i get a sample TCs , i have doubt in writing TC .. pls mail me

sreejithsreedaran1995@gmail.com
Reply
Aadil Khan

can i get sample TCs? plz mail me on – aadilkhan0204@gmail.com

Reply
Amala Shiny

I am new to testing. can you send me sample TCs to my mail

Mail id: shinish3@gmail.com
Thanks in advance
Reply
Geetanjali Gaikwad

Hi,
Please send me at least 10 TCs for reference. Because I am a fresher in
software testing. This helps me for a practice. My emailid is
gaikwadgeetanjali89@gmail.com
Reply
Shirisha

Hi,

can you send some TCs for practice.I’m new to the testing. Thank u.
 mail ID: sirik712@gmail.com
Reply
Alok kumar

hi,

can anyone send me templates of test case senarios.

thank you in advance.
Reply
jesus

You’ve run your test cases and it looks like there is a major bug. Select a
test case where the
expected result does not meet the actual result, and file a bug report for this
case.
this is the situation..can anybody help me to select test case?
Reply
Samera

please, cam you give an example of test case for non-functional requirements,
because I see all examples on functional requirements.

thank you in advance

Reply
sagartrivedi

Honestly speaking that this article is really helpful for making a test cases
and very nice examples. It’s very helpful article. everyone must visit your blog.
Thanks and keep sharing.
Reply
pardie

i am a new software tester. please anyone provide me TCs with example….

thank u
Reply
Ars

Hello,
May I get some sample TCs with examples and explanations?
marqaryan23@gmail.com
Reply

Comment navigation
← Older Comments
Leave a Comment

Comment
Name
Email

About SoftwareTestingHelp
Helping our community since 2006! Most popular portal for Software professionals
with 100 million+ visits! You will absolutely love our tutorials on Software
Testing, Development, Software Reviews and much more!

Join over 200,000+ Testers

Get premium ebooks and testing tips.

Join Over 300,000+ Followers!

Top FREE Training Tutorials

Load Testing Buyer’s Guide

Appium Testing Tutorial
Free QA Training
Selenium Tutorials
QTP/UFT Tutorials
Quality Center QC Tutorials
LoadRunner Tutorials
JMeter Tutorials
JIRA Tutorials
VBScript Tutorials
Best Test Management Tools
Unix Tutorials
DevOps Tutorials
JAVA Tutorials
Python Tutorials
Free C++ Tutorials
101+ Interview Questions

Join Our Team!

Software Testing freelancing work