I keep getting several requests to share a good Test Case Template. And I’m surprised that many testers are still documenting test cases with Word docs or Excel files. Most of them prefer excel spreadsheets because they can easily group test cases by test types and most importantly they can easily get test metrics with the Excel formulas. But I’m sure that as the volume of your tests goes on increasing, you will find it extremely difficult to manage.
If you are not using any test case management tool, then I would strongly recommend using an open source tool to manage and execute your test cases.
Test case formats vary from one organization to another. But using a standard test case format for writing test cases is one step closer to setting up testing process on your project. It also minimizes ad-hoc testing done without proper test case documentation. But even if you use standard templates you need to set up test cases writing, review and approval, test execution and most importantly test report preparation process, all by using manual methods.
Also if you have a process to review test cases by the business team, then you must format these test cases in a template agreed by both the parties.
Here is how to make this manual test case management process a bit easier with the help of simple testing templates.
Note: I’ve listed maximum fields related to a test case. But it is advised to use only those fields which are used by your team. Also if you think any field used by your team is missing from this list, then feel free to add it to your customized template.
There are certain standard fields to be considered while preparing a Test case template.
Several standard fields of a sample Test Case template are listed below.
Test case ID: Unique ID is required for each test case. Follow some convention to indicate types of the test. E.g. ‘TC_UI_1’ indicating ‘user interface test case #1’.
Test priority (Low/Medium/High): This is very useful while test execution. Test priority for business rules and functional test cases can be medium or higher whereas minor user interface cases can be of low priority. Test priority should always be set by the reviewer.
Module Name: Mention the name of the main module or the sub-module.
Test Designed By Name of the Tester
Test Designed Date: Date when it was written
Test Executed By Name of the Tester who executed this test. To be filled only after test execution.
Test Execution Date: Date when the test was executed.
Test Title/Name: Test case title. E.g. verify login page with a valid username and password.
Test Summary/Description: Describe test objective in brief.
Pre-condition: Any prerequisite that must be fulfilled before execution of this test case. List all the pre-conditions in order to execute this test case successfully.
Dependencies: Mention any dependencies on other test cases or test requirement.
Test Steps: List all the test execution steps in detail. Write test steps in the order in which they should be executed. Make sure to provide as many details as you can. Tip – In order to manage a test case efficiently with a lesser number of fields use this field to describe test conditions, test data and user roles for running the test.
Test Data: Use of test data as an input for this test case. You can provide different data sets with exact values to be used as an input.
Expected Result: What should be the system output after test execution? Describe the expected result in detail including message/error that should be displayed on the screen.
Post-condition: What should be the state of the system after executing this test case?
Actual result: Actual test result should be filled after test execution. Describe system behaviour after test execution.
Status (Pass/Fail): If actual result is not as per the expected result mark this test as failed. Otherwise, update it as passed.
Notes/Comments/Questions: If there are some special conditions to support the above fields, which can’t be described above or if there are any questions related to expected or actual results then mention them here.
Add following fields if necessary:
Defect ID/Link: If the test status is failed, then include the link to the defect log or mention the defect number.
Test Type/Keywords: This field can be used to classify tests based on test types. E.g. functional, usability, business rules etc.
Requirements: Requirements for which this test case is being written for. 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 a Visio diagram as a reference. Provide the link or location to the actual path of the diagram or document.
Automation? (Yes/No): Whether this test case is automated or not. Useful to track automation status when test cases are automated.
With the help of above fields I’ve prepared a test case example template for your reference:
Personally, I prefer to use a test case management tool. You can start with any open source tool. It will be a good addition to your efforts to set up testing process and meanwhile, it will also save a lot of time instead of manually maintaining these documents.
Are you an expert in preparing Test cases? Then kindly share few valuable tips with us.
Let us know if you have any queries, comments/suggestion about this post.