Test cases are the key elements of testing, therefore the ability to write effective tests is one
of the most important technical skills of a quality assurance engineer.
This post covers conditions to writing efficient test cases, the most preferable naming conventions,
and the best practices on structuring and writing the tests.

Conditions to writing efficient test cases

Before start writing tests, it is necessary to determine the purpose of testing,
define verifiable requirements and identify logical sets of test scenarios based on
user roles, features, etc. It is implied that a QA engineer is familiarized with the
functionality of the application and knows which operations can be performed
in order to cover all the testable requirements.

Then, it is required to evaluate the significance of functional modules, set priority
on the test scenarios in accordance with received data and customer requirements, and define
a test case template (only in case if QA team does not use a test-management tool):

List of fields for test case template	Required fields
Title	+
Summary/Description	+
Preconditions
Steps	+
Expected results	+
Postconditions
Author
Assigned to
Estimate
Comments
Milestone
Status
Keywords
Attachments	+
References
Test Environment
Custom fields

Once the template and the set of test data are defined, a QA engineer can start writing test cases.

Quick tip: the best practice is to place test data in a separate file and then reference it from the test.
This allows to test many different variations of the data using a single test case.

Naming conventions

Test case title should be unique and as descriptive as possible, the best practice is to keep the name
concise (one sentence or phrase) for readability. This name can be relatively long, but it should not
include more than 40 characters. If a test suite includes many similar tests, their names can be shortened:

	Before	After
Test suite	Invalid login	Invalid login should fail
Test cases	Login with empty password fails	Empty password
	Empty username must fail	Empty username
	Login with empty name & pass	Empty username and password
	Username with special numbers fails	Invalid username
	Invalid symbols in password	Invalid password
	Invalid log & pass	Invalid username and password

Quick tip: test cases should not contain any lingo (words, abbreviations, acronyms, etc.).

Test case structure

Tests in a suite should be independent, but, at the same time, grouped by a common idea. In the case, when
dependencies between them are unavoidable, a chain of related tests should not have more
than 3-5 units and a quality assurance engineer should verify the status of the previous test before running
the next one.

Moreover, test cases should be transparent, atomic and easy to understand.
One test should check only one subject, which can be small (part of a feature) or large (end-to-end).
The optimal number of steps in the test is about five.

Quick tip: do not specify the expected result for each step if the result is obvious.
Example: if the browser does not open, the tester won’t be able to proceed to the next step.

Examples of the simple test cases:

Test suite title	Sign in flow.	Sign in flow.
Test case title	Sign in by nickname.	Sign in with Google.
Summary/Description	This test case covers the ability to sign in to a web-service using nickname as a login.	This test case covers the ability to sign in to a web-service using Google account.
Priority	High	High
Preconditions	1) Take the test data from the attached file. 2) Open the main page of the web-service. 3) Open sign in lightbox.	1) Take the test data from the attached file. 2) Log in to Google account. 3) Open the main page of the web-service. 4) Open sign in lightbox.
Steps	Submit valid nickname and valid password.	Click on the Google button to sign in using Google account.
Expected results	The sign in lightbox should be closed. The page of the user dashboard should appear.	The sign in lightbox should be closed. The page of the user dashboard should appear.
Postconditions	Log out from the web-service.	Log out from the web-service. Log out from Google account.
Author	Alexander Kalashnikov	Alexander Kalashnikov
Assigned to	Alexander Kalashnikov	Alexander Kalashnikov
Estimate	2min	3min
Attachment	sign_in_lightbox.png test_data.txt	sign_in_lightbox.png test_data.txt
Status	Passed	Failed
Test Environment	Ubuntu 12.04 Mozilla 28.0	Mac OS X Lion Safari 5.1.10

Once a test case is ready to be executed, it’s necessary to make review and
verify that the test meet the following points:

• Title is short and descriptive.
• Test case corresponds with the requirements.
• Preconditions, steps and expected results are as transparent as possible.
• Postconditions include instructions to restore the application in its original state.
• Test case supports maintaining, update and can be re-used in the future.

Hopefully, the provided information will be helpful for writing the effective test cases in your projects.