Best Software Testing Test Case Templates and Examples

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.