- Software Testing Dictionary
- Home
Software Testing - Test Case
Software testing is conducted with the help of a number of artifacts namely the test plans, strategies, scenarios, and test cases. It is performed not only to detect errors but also to verify if the software is working as expected. To achieve this, a specific template is followed to verify each functionality. It is known as a test case.
What is a Test Case?
A test case is standard format adhered to in testing to check if the software is working as per the requirements. It comprises a collection of conditions that are required to be verified to validate if the actual outcomes on the software are matching with the expected ones.
The various sections of a test case are listed below −
- Functionality Name − It points to the functionality which is verified.
- Test Case Identifier − It points to a unique id assigned to each test case.
- Name of Tester − The name of the tester who will carry out the testing.
- Test Scenario Name − The name of the scenario which will be converted into a test case.
- Test Case Description − The requirement or the criteria which is going to be verified in the test case.
- Test Steps − The actions to be performed on the software to verify the test conditions.
- Preconditions − The prerequisites that need to be satisfied before starting with the test steps.
- Test Priority − The test priority is assigned to the test case to decide the order in which it needs to be executed.
- Test Data − The inputs and data which are needed to complete the test.
- Expected Outcome − The expected results as per the requirements.
- Test Settings − The settings and parameters that are needed to be set before running the test.
- Actual Outcome − The actual result produced on the software.
- Environment − The configuration of the environment on which the test is to be performed including the operating system, configurations, security etc.
- Test Status − The status of the test should reflect as pass, fail, not executed and blocked.
- Comments − The comments added against each test case.
Difference Between Test Cases and Test Scenarios
There are multiple differences between test cases and test scenarios −
| Sr.No | Test Case | Test Scenario |
|---|---|---|
| 1 | It has all the granular details on what to test, what test steps need to be done, what is actual, and expected results etc. | It is a high level document which touches all the functionalities, and user stories of all the features. | 2 | It is created so that both the testers, and the developers can work in collaboration. | It guides a testing team on tasks to be performed. | 3 | It is created from a test scenario document and it is reused again during the regression or retesting phase. | It is created straight from the requirements but it needs to be updated whenever there is a change or addition of any requirements. |
Which Time do we Write a Test Case?
A test case is written even before the starting of the software development when the requirements are ready. The testers finish designing the test cases at the time when development of the software has also been completed.
It is also created right after the complete software development (before production deployment) or after a new feature has been implemented as per need.
Test case creation is an ongoing process during the entire software development process such that once a module or a part of it is ready, it can immediately be tested parallelly.
Why are the Test Cases Written?
The test cases are written for the reasons listed below −
- To check if the software is working as per the requirements.
- To check if the software is working under specified conditions.
- It helps to restrict the software updates and other needs.
- It ensures that all the requirements with every possible scenario and use cases are covered and documented, thereby improving the test coverage.
- It helps to achieve evenness in test execution. A well designed test case lets any tester begin verifying the software.
- A good test case requires minimal maintenance efforts.
What is the Basic Format of a Test Case?
| Components | Purpose |
|---|---|
| Test Case Id | It points to a unique id assigned to each test case. |
| Test Case Description | A short description to describe why the test case is designed. |
| Preconditions | The prerequisites that needed to be satisfied before starting with the test steps. |
| Test Steps | Describe the test steps in detail. |
| Test Data | The inputs and data which are needed to complete the test. |
| Expected Outcome | The expected results as per the requirements. |
| Post Conditions | The conditions that are required to be fulfilled after the test case is run successfully. |
| Actual Outcome | The actual result produced on the software. |
| Test Status | The status of the test after comparing with the actual and expected results. |
| Project Name | Name of the project. |
| Module Name | Name of the module. |
| References | The location where the references are available. |
| Created By | The tester name who has designed the test case. |
| Created Date | The data on which the test case has been created. |
| Reviewed Date | The data on which the test case has been reviewed. |
| Executed By | The tester name who has executed the test case. |
| Executed Date | The data on which the test case has been executed. |
| Comments | The comments added against the test case. |
The below image shows a test case format.
Best Practices to Design a Test Case
The best practices to design a test case are listed below −
- It should not be complex, clear and easy to understand.
- Each of the test cases should be distinct.
- It should be designed only after a clear understanding of requirements, inputs, data, and without any assumptions.
- Each of the test cases should be mapped to at least one requirement for traceability.
- Every test case should be verified with all possible inputs, conditions, and data.
- The test case descriptions, names etc should be self explanatory but explained in a few sentences.
- Each test case should cover customer requirements.
- The test cases should not be designed such that they generate the same outcomes.
- It should be designed keeping in mind the end user’s requirements and perspectives.
- Every test case should have a unique id.
- It should have the clearly defined preconditions and postconditions.
- It should be written such that it can be reused in other places.
- The precise expected outcomes of the test cases should be incorporated.
Test Management Tools
The different test management tools are listed below −
- TestRail − It is a test management tool.
- Jira − It is a project management tool.
- ALM/HP QC − It is a project management tool.
Formal and Informal Test Cases
- Formal Test Case − It follows the test case template or format as discussed above.
- Informal Test Case − It does not follow any test case template or format.
Different Types of Test Cases
The different types of test cases are listed below −
- Functional Test Cases − They are written to verify if the functionalities of the software are working as expected.
- Unit Test Cases − They are written by developers to verify if the unit of the software they have developed is working.
- GUI Test Cases − They are written to verify the graphical user interface of the software.
- Integration Test Cases − They are written to verify if the different components of the software are working fine after being integrated with other components.
- Performance Test Cases − They are written to verify the response time and overall performance of the software.
- Database Test Cases − They are written to verify the backend and if all the data are reflecting in the correct tables in the database.
- Security Test Cases − They are written to verify the security features of the software.
- Usability Test Cases − They are written to verify if the software is usable and user friendly.
- User Acceptance Testing − They are written to verify if the software is working correctly in real life scenarios and environments.
Practical Example of Test Case
The below is an example of a functional test case designed to verify if the payment can be processed only if the user has a minimum account balance.
| Module Name | Payment |
|---|---|
| Test Case Id | 10 |
| Created By | Ram |
| Test Case Description | To verify payment features |
| Preconditions | 1. A user should be able to login. 2. A user should have some balance in his account. |
| Environment | Windows, latest Chrome browser UAT environment |
| Scenario Name | Verify if the payment can be processed only if the user has minimum account balance. |
| Test Case Id | Test Steps | Test Data | Expected Result | Actual Result | Status | Comments |
|---|---|---|---|---|---|---|
| 10 | Launch browser | User credentials | Browser should be launched | Browser is launched | Pass | N/A |
| Open URL | Application URL should be opened | Application URL is opened | ||||
| Click on Balance Tab | Balance Page should be opened and user should have some balance. | Balance Page is opened and user has some amount balance | ||||
| Click on Payment Tab | Payment Page should be opened and user should successfully process payment using the balance. | Payment Page is opened and user successfully processes payment using the balance. | ||||
| Click on Logout | Application should be logged out. | Application is logged out |
In the above example, the user first launches the browser and opens an application there. Then the user account balance is checked following which the payment is done using that balance.
Conclusion
This concludes our comprehensive take on the tutorial on Software Testing Test Cases. We’ve started with describing what is a test case, what is the basic characteristics of a test case, which time we write a test case, why test cases are written, what are the differences between test cases and test scenarios, what are the different test management tools, what are formal and informal test cases, what are the different types of test cases, and practical example of a test case.
This equips you with in-depth knowledge of Software Testing Test Cases. It is wise to keep practicing what you’ve learned and exploring others relevant to Software Testing to deepen your understanding and expand your horizons.