'The art of writing effective and transparent test cases' post illustration

The art of writing effective and transparent test cases

avatar

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.webp
test_data.txt
sign_in_lightbox.webp
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.

If you're looking for a developer or considering starting a new project,
we are always ready to help!