Test Case
The test case is defined as a group of conditions under which a tester determines whether a software application is working as per the customer’s requirements or not. Test case designing includes preconditions, case name, input conditions, and expected result. A test case is a first level action and derived from test scenarios.
It is an in-details document that contains all possible inputs (positive as well as negative) and the navigation steps, which are used for the test execution process. Writing of test cases is a one-time attempt that can be used in the future at the time of regression testing.
Test case gives detailed information about testing strategy, testing process, preconditions, and expected output. These are executed during the testing process to check whether the software application is performing the task for that it was developed or not.
Test case helps the tester in defect reporting by linking defect with test case ID. Detailed test case documentation works as a full proof guard for the testing team because if developer missed something, then it can be caught during execution of these full-proof test cases.
To write the test case, we must have the requirements to derive the inputs, and the test scenarios must be written so that we do not miss out on any features for testing. Then we should have the test case template to maintain the uniformity, or every test engineer follows the same approach to prepare the test document.
Generally, we will write the test case whenever the developer is busy in writing the code.
When do we write a test case?
We will write the test case when we get the following:
- When the customer gives the business needs then, the developer starts developing and says that they need 3.5 months to build this product.
- And In the meantime, the testing team will start writing the test cases.
- Once it is done, it will send it to the Test Lead for the review process.
- And when the developers finish developing the product, it is handed over to the testing team.
- The test engineers never look at the requirement while testing the product document because testing is constant and does not depends on the mood of the person rather than the quality of the test engineer.
Note: When writing the test case, the actual result should never be written as the product is still being in the development process. That?s why the actual result should be written only after the execution of the test cases.
Why we write the test cases?
We will write the test for the following reasons:
- To require consistency in the test case execution
- To make sure a better test coverage
- It depends on the process rather than on a person
- To avoid training for every new test engineer on the product
To require consistency in the test case execution: we will see the test case and start testing the application.
To make sure a better test coverage: for this, we should cover all possible scenarios and document it, so that we need not remember all the scenarios again and again.
It depends on the process rather than on a person: A test engineer has tested an application during the first release, second release, and left the company at the time of third release. As the test engineer understood a module and tested the application thoroughly by deriving many values. If the person is not there for the third release, it becomes difficult for the new person. Hence all the derived values are documented so that it can be used in the future.
To avoid giving training for every new test engineer on the product: When the test engineer leaves, he/she leaves with a lot of knowledge and scenarios. Those scenarios should be documented so that the new test engineer can test with the given scenarios and also can write the new scenarios.
Note: when the developers are developing the first product for the First release, the test engineer writes the test cases. And in the second release, when the new features are added, the test engineer writes the test cases for that also, and in the next release, when the elements are modified, the test engineer will change the test cases or writes the new test cases as well.
Test case template
The primary purpose of writing a test case is to achieve the efficiency of the application.
As we know, the actual result is written after the test case execution, and most of the time, it would be same as the expected result. But if the test step will fail, it will be different. So, the actual result field can be skipped, and in the Comments section, we can write about the bugs.
And also, the Input field can be removed, and this information can be added to the Description field.
The above template we discuss above is not the standard one because it can be different for each company and also with each application, which is based on the test engineer and the test lead. But, for testing one application, all the test engineers should follow a usual template, which is formulated.
The test case should be written in simple language so that a new test engineer can also understand and execute the same.
In the above sample template, the header contains the following:
Step number
It is also essential because if step number 20 is failing, we can document the bug report and hence prioritize working and also decide if it’s a critical bug.
Test case type
It can be functional, integration or system test cases or positive or negative or positive and negative test cases.
Release
One release can contain many versions of the release.
Pre-condition
These are the necessary conditions that need to be satisfied by every test engineer before starting the test execution process. Or it is the data configuration or the data setup that needs to be created for the testing.
For example: In an application, we are writing test cases to add users, edit users, and delete users. The per-condition will be seen if user A is added before editing it and removing it.
Test data
These are the values or the input we need to create as per the per-condition.
For example, Username, Password, and account number of the users.
The test lead may be given the test data like username or password to test the application, or the test engineer may themself generate the username and password.
Severity
The severity can be major, minor, and critical, the severity in the test case talks about the importance of that particular test cases. All the text execution process always depends on the severity of the test cases.
We can choose the severity based on the module. There are many features include in a module, even if one element is critical, we claim that test case to be critical. It depends on the functions for which we are writing the test case.
For example, we will take the Gmail application and let us see the severity based on the modules:
| Modules | Severity |
|---|---|
| Login | Critical |
| Help | Minor |
| Compose mail | Critical |
| Setting | Minor |
| Inbox | Critical |
| Sent items | Major |
| Logout | Critical |
And for the banking application, the severity could be as follows:
| Modules | Severity |
|---|---|
| Amount transfer | critical |
| Feedback | minor |
Brief description
The test engineer has written a test case for a particular feature. If he/she comes and reads the test cases for the moment, he/she will not know for what feature has written it. So, the brief description will help them in which feature test case is written.
Example of a test case template
Here, we are writing a test case for the ICICI application’s Login module:
Types of test cases
We have a different kind of test cases, which are as follows:
- Function test cases
- Integration test cases
- System test cases
The functional test cases
Firstly, we check for which field we will write test cases and then describe accordingly.
In functional testing or if the application is data-driven, we require the input column else; it is a bit time-consuming.
Rules to write functional test cases:
- In the expected results column, try to use should be or must be.
- Highlight the Object names.
- We have to describe only those steps which we required the most; otherwise, we do not need to define all the steps.
- To reduce the excess execution time, we will write steps correctly.
- Write a generic test case; do not try to hard code it.
Let say it is the amount transfer module, so we are writing the functional test cases for it and then also specifies that it is not a login feature.
The functional test case for amount transfer module is in the below Excel file:
Integration test case
In this, we should not write something which we already covered in the functional test cases, and something we have written in the integration test case should not be written in the system test case again.
Rules to write integration test cases
- Firstly, understand the product
- Identify the possible scenarios
- Write the test case based on the priority
When the test engineer writing the test cases, they may need to consider the following aspects:
If the test cases are in details:
- They will try to achieve maximum test coverage.
- All test case values or scenarios are correctly described.
- They will try to think about the execution point of view.
- The template which is used to write the test case must be unique.
Note: when we involve fewer numbers of steps or coverage is more, it should be the best test case, and when these test cases are given to anyone, they will understand easily.
System test cases
We will write the system test cases for the end-to-end business flows. And we have the entire modules ready to write the system test cases.
The process to write test cases
The method of writing a test case can be completed into the following steps, which are as below:
System study
In this, we will understand the application by looking at the requirements or the SRS, which is given by the customer.
Identify all scenarios:
- When the product is launched, what are the possible ways the end-user may use the software to identify all the possible ways.
- I have documented all possible scenarios in a document, which is called test design/high-level design.
- The test design is a record having all the possible scenarios.
Write test cases
Convert all the identified scenarios to test claims and group the scenarios related to their features, prioritize the module, and write test cases by applying test case design techniques and use the standard test case template, which means that the one which is decided for the project.
Review the test cases
Review the test case by giving it to the head of the team and, after that, fix the review feedback given by the reviewer.
Test case approval
After fixing the test case based on the feedback, send it again for the approval.
Store in the test case repository
After the approval of the particular test case, store in the familiar place that is known as the test case repository.
To get complete information about test case review process refers to the below link:
https://tutoraspire.com/test-case-review-process