This document provides guidance on how to write effective test cases. It discusses test case components like objectives, preconditions, steps, and expected results. It emphasizes making test cases clear, concise, reusable, and up-to-date to reflect any application changes. The document also highlights techniques like breaking tests into focused subsets and attaching relevant artifacts.

1. Created by: Sarah Goldberg
July 14, 2014
Version 1.0

2. A Test Case is simply a list of actions which need to be
executed to verify a particular functionality or feature of
your application under test.
It might take more than one test case to determine the true
functionality of the application being tested. Every
requirement or objective to be achieved should have at
least one test case.

3. • Level 1: In this level you will write the basic test cases
from the available specification and user documentation.
• Cover the entire positive scenarios first and then think about all
possibilities of negative scenarios; these will effectively find most
of the bugs.
• Level 2: This is the practical stage in which writing test
cases depend on actual functional and system flow of the
application.

4. • Level 3: This is the stage in which you will group some
test cases and write a test procedure. Test procedure is
nothing but a group of small test cases maximum of 10.
• Level 4: Automation of the project. This will minimize
human interaction with system and thus QA can focus on
current updated functionality's to test rather than
remaining busy with regression testing.

6. Name your test cases in a way that makes sense to
anyone who is going to refer the test in future.
It should represent the module name or functional
area you are going to verify in the test case.
For example, if I am working on a project “Online”
which has a functional area called “Login” and want
to write a test to verify a simple check whether the
user is able to login to the website using an email
and password
• Online_Login_ValidCredentials
• Online_Login_InvalidCredentials
Test Case
Naming
Conventions

7. Where you mention all the details about what you
are going to test, and the particular behavior being
verified by the test.
The following information would be found in a well-
written test case description:
• Test to be carried out / behavior being verified
• Preconditions and Assumptions (any
dependencies)
• Test Data to be used
• Test Environment Details (if applicable)
• Any Testing Tools to be used for the test
Try to place yourself in the shoes of someone who
is entirely unfamiliar with the function to be tested,
and make sure they can successfully complete the
test simply by following the procedure.
As much as possible, without compromising
comprehensiveness, try to write the test case such
that it will not go 'stale'. Try to ensure your test case
will be usable for a long time without regular editing.
Description

8. Communicate all assumptions that apply to a test,
along with any preconditions that must be met
before the test can be executed.
Below are the kinds of details that should be
covered in this section:
• Any user data dependency (e.g. the user should
be logged in, which page should the user start
the journey, etc.)
• Dependencies on test environment
• Any special setup to be done before Test
Execution
• Dependencies on any other test cases – does the
Test Case need to be run before/after some other
Test Case?
Assumptions
and
Preconditions

9. A few pointers:
• In many cases where you know the test data can
be re-used over time, you can mention the exact
Test Data to be used for the test.
• If the test only involves some values to be
verified, you can opt to specify the value range or
describe what values are to be tested for which
field.
• Testing with every value is impractical, so you
can choose a few values from each equivalence
class which should provide good coverage for
your test.
• You could also decide to mention the type of data
which is required to run the test and not the real
test data value. This applies for projects where
the test data keeps on changing as multiple
teams use it and may not be in the same state
when I use it the next time.
Input Test
Data

10. The test case steps should not only cover the
functional flow but also each verification point which
should be tested.
By comparing your Test Case steps with the
Requirement documents, Use Cases, User Stories
or Process Maps given for your project, you can
make sure that the Test Case optimally covers all
the verification points.
Cover
Verification
Points in Test
Steps

11. Wherever possible you should attach the relevant
artifacts to your test case.
If the change you are going to test is very minor, you
could consider mentioning it in the test step itself.
Attach the
Relevant
Artifacts

12. A well-written Test Case clearly mentions the
expected result of the application/system under
test.
Each test design step should clearly mention
what you expect as outcome of that verification
step.
• mention in detail what page/screen you
expect to appear after the test
• any changes you expect to be done to any
backend legacy systems or Database.
Attach screenshots or specification documents to
the relevant step and mention that the system
should work as outlined in the given document to
make things simpler.
Expected
Result

13. Consider breaking down the test cases into sets and
sub-sets to test some special scenarios like browser
specific behaviors, cookie verification, usability
testing, Web Service Testing and checking error
conditions etc.
• For example, if you need to verify how the login
feature for any application works with invalid
input, you can break this negative testing for login
functionality into sub tests for different values like:
• Verify with invalid email-id
• Verify with invalid password
• Verify with blank email-id field and so on…
Divide
Special
Functional
Test Cases
into Sets

14. When designing test cases, consider that they will
not always be executed by the ones who design
them.
Write Test Cases that:
• Are Simple and easily understandable by
everyone
• Are to-the-point. If a Test Case is going
beyond a certain amount of steps, break it into
a new Test Case
• Still have enough coverage
Legible &
Easily
Understandabl
e by Others

15. With Test Cases playing an important role in
Software Testing Life-cycle, making sure they are
correct and conform to standards becomes even
more necessary.
Test case review can be done by peer testers, BA,
developers, product owners or any relevant
stakeholders.
Review

16. Test Cases can be re-used in the future for other
projects.
Before writing a new test case for your
project/module, look for existing test cases. This
way you won’t risk repeating any test cases and can
avoid any redundancies in Test Management Tools.
If there is an existing test case written around the
same module, you should be updating it instead of
writing a new test case.
If you need a particular test case to execute some
other test case, you can simply call the existing test
case in the preconditions or at the specific test
design step.
Reusable

17. It’s very important that test cases are always
updated, as per the newly introduced changes in the
application they apply to.
• Always consider updating the existing Test
Cases (if any) before you start writing New
Test Cases.
Reiterating reusability, in case of any changes to an
existing page or functionality, consider updating the
existing test cases instead of writing any new test
cases hence avoiding redundancies to the existing
set.
This also makes sure you always have updated Test
Cases for any ‘journey’ in your application.
Maintenance
& Updates

18. Post-conditions basically specify the various things
that need to be verified after the Test has been
carried out.
In addition, post-conditions are also used to give
guiding instruction to restore the system to its
original state for it not to interfere with subsequent
testing.
• For example, mentioning the changes to be
made to test data so it can be used for a later
test case with the same functionality.
Post
Conditions

19. Use the Test Case Area Classification to ‘link’ the
cases together and ensure they can easily be found
both manually and automatically.
You should always use the appropriate area
whenever creating a test case in order to help
people locate the test case in the future.
Test Case
Area
Classification