Best Software Testing Test Case Templates and Examples | DeviQA
DeviQA Logo

8 minutes to read

Best Software Testing Test Case Templates and Examples

Best Software Testing Test Case Templates and Examples
August 29, 2019


Test case means a check. It means that you should run the test case to check whether the results correct. Test case describes the checking of system behavior that can be carried out by QA engineer, developer, or even by an analyst. The set of test cases is called a test suite. Sometimes it is called a test plan - that is incorrect. A test plan is a plan that describes when, what, for what and with the help of which resources to run the test. The usage of a standard format of software test case templates is a way to set up the test process on your project. write test cases

These are the standard fields in the test case template:

Test case ID: It is a unique ID for each test case. You should follow the convention to indicate types of tests. For example, "TC_UI_1" means ‘user interface test case #1.

Test priority (Low/Medium/High): This one is for test execution. Test priority for business rules and functional test cases might be medium or higher, whereas minor user interface cases can be with a low priority. Test priority is set by the reviewer.

Module Name: - The names of the main module or submodule are mentioned.

Test Designed By: Tester's name is mentioned here. This information is given to contact the author for asking questions or get clarification.

Test Designed Data: You mention the data when the test case is written. It is used as an input for the test case. Various data sets are to be provided with exact values. Also, you can store test data in a text file or in an Excel spreadsheet. By using a test data file, you avoid hard coding test data in the test case, so a single test case can be used to test several sets of test data.

Test Executed By: This field will be filled after the execution of a test case.

Test Execution Date: Date when a test is executed.

Test Title/Name: for verifying login page with valid username and password. It is a short description of the essence of checking. It is short but informative.

Test Summary/Description: Describe test objective in brief.

Preconditions: Any prerequisite that ought to be fulfilled before the execution of the target test case. List all the preconditions to execute the test case successfully. For example: sign up in the system. If there are no preconditions, the field stays unfilled.

Dependencies: Mention any dependencies must be mentioned in other test cases or test requirement.

Expected Result: What is the system output after the test execution? Describe the expected result in detail, including message/error that should be displayed on the screen.

Actual result: Actual test result may be filled after test execution. Describe system behavior after test execution.

Test Steps: List all test execution steps in detail. Write test steps in the order providing all the possible information in which these should be executed. Tip - to efficiently manage test case with lesser number of fields use this field to describe test conditions, test data, and user roles for running test.

Status (Pass/Fail): If an actual result does not correspond to the expected result you should mark this test as failed. If test status is abandoned, then include the link to defect issue or mention the issue number. Otherwise, update as passed.

Notes/Comments/Questions: To support above fields if there are some special conditions which can't be described in any of the above areas or there are questions related to expected or actual results mention those here.

Requirements: Requirements, for which this test case is written. Preferably the exact section number of the requirement doc.

Attachments/References: This field is useful for complex test scenarios. To explain test steps or expected result using an attached file. Provide the link or location to the actual path of the attached file.

Post conditions: E. g. you must return the system to its initial state.

Related articles:

Simple Template for Test case

Sample Template for Test Case

The example of test script template (there is only one expected result)

There is the site of the company that provides the internet. Let it be Test stand where further development is being checked before releasing in PROD (the same as production) uses another domain which corresponds to

N.B. is an abstract domain of the site. Do not search for it :).

The one can add service cards the buildings and cards of the tenants on this site. Cards are added by the administrator. The test machine has its own admin.

Test case #1

Creating a tenant without a name

Steps to reproduce:

Go to (login - test, password - test)
Log in as administrator (login - admin, password - 1)
Go to the tab "tenants"
Press the "Create a new tenant card" button
Press the "Save" button (do not fill in any fields)

Expected result: The error "Fill in all the necessary fields that are marked *". The card cannot be saved.

Another option for writing a test case with a few expected results is when the results are written for each step where clarifications are needed, that is, at different stages of the scenario. Below is an example of a test case of such software test template.

Test case #2. Creating a tenant with the full name

Steps to reproduce:

Go to the site (login - test, password - test)
Login under administrator account (login - admin, password - 1)
Click the "Tenants" tab
Click the button "Create a tenant card"
Fill in correct names, for example, "James Bond"
Click the "Save" button

Expected Result:

The login/password entry window opens with the appropriate fields for input, the "Login" button and the message "Please enter your data to enter the system".
Log in to the system was successfully executed. "Hello, admin" is displayed in the upper right corner. The main page of the site is open.
The page "Creation of a new tenant" with "Name" text field and "Save" button has been opened.
The form with information about the tenant is closed, and a general list is displayed, in which there is a new card. This card can be opened, and the entered data is displayed on it.

Below there is an example of a test case from software testing templates with few checks after one scenario.

Test case #3. Creating a tenant with the full name

Steps to reproduce:

Go to the site (login - test, password - test)
Login under administrator account (login - admin, password - 1)
Click the "Tenants" tab
Click the button "Create a tenant card"
Fill in the correct name, for example, "James Bond"
Click the "Save" button

Expected results:

The window with information about the tenant is closed, and a general list is displayed, in which there is a new card
This card can be opened
In the opened card, the entered data is displayed

Advantages and disadvantages of test cases

Advantages: it is possible to entrust the test-cases to a newcomer or a colleague which was called from another department who does not know anything about the project. There will not be many additional questions from him - everything and so (it should be) understandable!

Disadvantages (arise from one another)

A lot of copy-paste actions. In the example above, the "Name" field was filling in. Test cases "enter only characters in the field, only numbers, a zero-length string, etc." Will be very similar to each other, the first steps are the same and, honestly, will copy. Try to write at least three test cases for one functional and immediately see this problem.
It is difficult to support. Imagine that the tab "Tenants" would be renamed to "Customers" To update the test cases, you need to make changes to hundreds of test cases, which is tedious even in the "Ctrl + C, Ctrl + V" mode.
Not actual state. Test cases are being copied from each other, and often there remain irrelevant parts of the original case that forgot to update.

For test cases to perform their role impartially, they must be supported, periodically checked for correctness and modified... It takes a lot of time and effort.

To simplify this process, test cases with one set of steps to reproduce can be used, but several input parameters and different expected results. In fact, we get mini-checklists with preliminary steps.