What is a Test Case?
A test case is a document that tests a specific scenario in the working of a software system. The scenario could be about a feature or a non-functional aspect like performance or security.
Test Scenarios
A scenario is a specific condition to be tested in the software. It is best illustrated using some real-world examples.
Let's say you have a field called price. You will write a test case for each of the following scenarios:
- Users should not be able to enter non-numeric characters.
- Price should be greater than zero.
- Price should be less than a million dollars.
Let's take another example, this time about a non-functional aspect. Let's say we have another field called description. You will write a test case for each of the following security conditions:
- The software should remove all script tags before saving this field.
- All HTML tags, other than <b> <i> and <u> should also be escaped.
- The field should be immune to SQL injection attacks.
Attributes of a Test Case
Typically, a test case has the following attributes:
- Test Case ID: a unique ID of the test case. If you use test management software, this will be automatically assigned. This field is used to cross-reference features and test cases in the RTM.
- Test Scenario: a summary of the test.
- Test Case Description
- Prerequisites: conditions that must exist before executing this test case.
- Test Steps & Validations
- Test Data
- Environment: the software and hardware to be used to run this test
- Module: the primary module related to this test case
- Comments
- File Attachments
- Designed By
- Last Updated On
Different organizations can have more or fewer fields based on their requirements. For example, you can have an attribute called "priority" to help your testers decide which tests to perform first.
Example
Let's say we have the common requirement that usernames should be unique while creating a user. You can have a test case like:
Test Case ID | USR-08 | ||||||||||
Test Case Scenario | Disallow duplicate usernames while creating a user. | ||||||||||
Prerequisites | A user exists with the username: Apple. | ||||||||||
Test Case Steps |
| ||||||||||
Test Environment | Any Supported Browser | ||||||||||
Module | User | ||||||||||
Designed By | Mike Jones (mike.jones@tuskr.app) | ||||||||||
Last Updated On | 2 March 2020 |
Test Case Writing Best Practices
1. Write one test case per scenario.
Testers often combine multiple scenarios into one test case to reduce the number of test cases. This is frequently based on incorrect assumptions about how the software is implemented and, rather than helping, reduces the effectiveness of the test case.2. Keep it terse but precise.
Testing is a manual and time-consuming activity. Productivity is an important aspect. To aid the tester, write crisp and clear instructions. Skip the obvious and develop conventions to compress the text. The lesser text, the better.
For example, instead of writing "Click on the User button from the main menu and choose View," you can write "Click Main Menu > User > View." Instead of writing "Click on the Save button," you can say "Save."
You can also assume that testers will be fairly familiar with the software. So instead of stating, "Click on the admin link located on the top right-hand corner of the page," you write "Click Admin."
3. Use Test Data
Developing test data for test cases can significantly reduce time. In the example section above, a user was already created with the username apple so that the duplication test can be performed quickly. Otherwise, the steps would first include the creation of a user, slowing down the testing.
Test data is especially useful when testing complex algorithms. For example, in testing a scheduling software program, it would be of great help if different users having different work timings in different time zones were already created, along with a few projects having different tasks.
4. Attach images and videos.
A picture speaks more than a thousand words, it is said, and now you can easily capture and upload videos. If instructions to the tester are complicated, it is better to upload videos with text callouts.
5. Fill in all the fields.
A most egregious practice that we have observed is that test case writers don't fill in all the fields. They may leave the module blank or sometimes skip entering some other important fields used for reporting. If you use a test management tool, try marking important fields are mandatory.