Test cases are documentations that consists of line-by-line instructions that define how testing has to be done. Test cases are very crucial when it comes to testing, as it acts as a well-defined guide for the testing team to validate if the application is free from bugs. Another important aspect is that test cases help to verify if the application meets the client’s requirements. So if a test case is written on the go without any planning or effort, it will result in huge losses, as a mistake here would act like a domino effect that impacts all the upcoming stages of testing. As one of the best software testing companies in the market, we have seen great results when effective test cases were implemented. So in this blog article, we will be focusing on how you can effectively write test cases.
What are the Headers that should be present in a Test Case?
Before we discuss on How to Write Effective Test Cases, let’s cover the basic aspects that every test case must have.
Name of the Project:
Whenever we write any test case, we should make sure to mention the name of the project to avoid any unnecessary confusion.
Module Name:
The software will usually be broken down into different modules so that they can be tested separately. So it is important to give each module a unique name so that different methods of testing can be assigned and implemented without any errors.
Reference Document:
A software requirements specification (SRS) or the Customer Requirement Specification (CRS) must be specified so that the testing team can test the application based on it.
Created By:
Every written piece of content would have an author and so make sure to mention the name of the person or the team that has created the test cases. Though it is not mandatory to include the designation of the person, it is recommended that you do so.
Test Case Created Date:
It goes without saying that when all the above information is vital, the date would be important as well. So make sure to specify the date that the test team should start testing, as it helps set a deadline.
Test Case ID:
Each and every Test Case should have a unique individual ID. It is like how each student has their own and unique identification number. It will help locate the test case if you want to reuse it or be helpful for any future references.
Test Scenario:
It acts as a descriptive guide that helps us understand each step. It also highlights the objective of the action that we are going to perform in the Test case.
Test Script (or) Steps:
Every step that should be carried out has to be mentioned under the Test Steps header. It is like explaining each step in an in-depth manner so that the testing test doesn’t miss out on any step resulting in deviations from the client requirement.
Test Data:
Mentioning what input should be given in each step is equally important while testing the application. It helps to keep the testing process on track without any missteps.
Expected Result:
The primary objective of any test is to verify if the expected or desired result is achieved at the end. The client requirement can be firmly established by properly defining the expected result to make the application error-free. Let’s take a look at an example to get a better understanding.
Example: If the user turns ON the fan switch, the Fan should rotate in an anticlockwise direction.
The expected result here is that the fan should rotate in the anticlockwise direction when it is switched on.
Actual Result:
But we cannot expect the result to be as expected in every scenario. That is why we have to make a note of the actual results we obtain while executing the test.
Example: In the same scenario as discussed above, it doesn’t mean that everything is working fine if the fan rotates. It must be verified according to the expectation and see if the fan rotates in the anticlockwise direction. If the fan rotates in the clockwise direction, we should make sure to make a record of it.
Status (or) Comment:
Once we have the expected result and the actual result, we will be able to come to a conclusion and decide if the application passed the test or not. Apart from updating the status, we can also add remarks about the result such as special scenarios and so on. We can also compare this to a student’s report sheet which denotes if the student has passed or failed and would have remarks based on the result as well.
What is the Difference Between Test Case and Test Scenario?
This could be a common question that arises in many minds when this topic is discussed. So we have created a tabular column to establish the key differences between a test case and a test scenario.
Sample Test Case:-
Now that we have gotten the basics out of the way, let’s dive into a full-fledged example and understand how to write effective test cases.
Test Scenario: A user has to send an email to someone else using their Gmail mobile application.
What are all the different types of Test Cases available?
Generally, test cases are classified into two main types,
i. Positive Test cases
ii. Negative Test cases
Positive Test cases:-
The Positive test cases do not differ much from the usual test cases, and so they are also known as formal test cases. A positive test case is used to very if the correct output is obtained when given the correct input.
Example:
Let’s say a user wants to transfer money through any UPI app, then he/she should find the correct recipient using their UPI ID or mobile number, enter the respected amount that they wish to transfer, and also enter the right UPI pin to complete the transaction. A positive test case would have the tester do the same actions by giving the correct input and seeing if everything works smoothly without any mishaps.
Negative Test cases:-
Negative Test cases are opposite to Positive test cases, as testers will provide an intentional negative or false input to make sure that the output is also negative. If we consider the same example we saw for positive test cases, the tester would try entering an incorrect UPI pin and see if the transaction fails. This is to make sure that only the authorized user will be able to operate the application, thereby increasing the security of the app. These tests are also called informal tests as they are not needed in every scenario, but they are pivotal in making sure that the application is secure.
Types of Positive Test Cases:-
Apart from the rare scenarios where negative test cases are used, positive test cases would be the more widely used preference. The Positive test cases can be further classified further based on the type of the project and the testing methods. But we will not be focusing on every type of test case as the other types are just subcategories of these 5 main types.
1. Functional Test cases
2. Integration Test cases
3. System Test Cases
4. Smoke Test cases
5. Regression Test Cases
Functional Test Cases:-
These test cases are written to check whether a particular functionality of the application is working properly or not.
Example:
If we take the same email sending example, then the test case that verifies if the send functionality is working correctly would be an apt example.
Integration Test Cases:-
These test cases are written to ensure that there is accurate data flow and database change across two combined modules or features.
Example:
The UPI money transaction example would fit well here too. During the transaction, the user enters the amount and enters the pin to complete the transaction. Once the transaction has been completed, the user will get a message about the deduction from their bank account as a result of the database change that has happened.
In this example, there is both data flow and database change between the two different modules.
System Test Cases:-
Earlier types saw us writing test cases only for a particular functionality or to see if the two modules work properly. But whenever the Testing environment is similar to the production environment, then the system test cases can be written to verify if the application is working correctly from its launch till the time it is closed. That is why this type of testing is also called end-to-end testing.
Example:
Here also we can take the same money transaction test case, but we have to test it starting right from the launch of the application to the successful transaction, and even until we receive the amount deduction message and have the transaction history updated in the user’s bank account.
Smoke Test Cases:-
Smoke tests that are also known as initial testing are very important in software testing as it acts like a preliminary test that every application should pass before extensive testing begins Smoke test cases should be written in a way that they check the critical functionalities of the software. We can then verify if the software is stable enough for further testing.
Example:
If we go back to the UPI payment app, then the testing team would have to test the application launch, account creation, and bank account addition before heading on to the transaction feature itself.
Regression Test Cases:-
Whenever the application gets any updates like UI updates, or new feature updates, the regression test cases come into play as they will be written based on the changes.
Example:
Let’s take an application most of us use on a daily basis, WhatsApp. Previously their testing team could have written test cases where the expected result could have been a list of emojis and the gif option being displayed when a user clicks on the Emoji option in the input text box.
But in one update, WhatsApp had introduced the stickers option. Since the new stickers would appear alongside the emojis and the gif option, the new test case would have been updated accordingly.
Guidelines on how to write effective test cases:
We have covered all the basic requisites that a test case must have and also the different types of test cases. This doesn’t necessarily mean that we can start writing perfect test cases right off the bat. So we will be covering a few important guidelines you should keep in your mind to write effective test cases.
1. CRS & SRS
The Testing team should be able to read and understand the Client requirements. But how is that made possible?
The client requirements for a project can be called a CRS or a Contract in simple terms. In this CRS document, the client will mention all their expectations about the software, such as how the software should perform and so on. This CRS document will be handled by the Business Analyst-(BA) of the company, and they will convert the CRS document into an SRS [System Requirement Specification] document.
The created SRS document has the functionality for each and every module and co-modules. Once the Business Analyst converts the CRS document into an SRS document they will provide the copy of the SRS document to the Testing and Development Teams. So the Testing team can read and understand the client requirement from the SRS.
2. Smoke Tests
Whenever we start writing the test cases, we should ensure to add smoke test cases to verify if the main functionality of the application is working.
3. Easy to Read
Writing easy-to-read test cases have advantages of their own. We can call it a success if a person who doesn’t have any technical knowledge can read the test cases and understand them clearly to work with the test cases.
4. Risk Evaluation
Writing extensive test cases that are not necessary should be avoided as it is a waste of resources. So proper risk evaluation has to be done prior to writing test cases so that the testing team can focus on the main requirement and core functionalities.
5. Format
The test cases always should start with either the application or the URL being launched, and it should end with the logging out option or closure of the application.
6. Avoid Assumptions
The Expected Result should be clearly captured for each and every test step, and all the features of the software (or) application should be tested without making any assumptions.
7. Dynamic values
Each and every step should not consist of multiple actions based on a single dynamic value. The dynamically changing values should not be hardcoded while writing the Test Cases. We have listed a few examples of such dynamic values.
Example:
Date, Time, Account Balance, Dynamically changing Game Slates, Reference Numbers, Points (or) Scores, etc.,
8. Dynamic Test Cases
But what should be done if we have to write a test case for a dynamically changing value? We can make use of common terms.
Example:
Let’s assume there is an online shopping site that is running a promotional campaign called ‘Happy New Year’ that provides its customers with a 20% off on their purchase. The dynamic value here is the campaign as it keeps changing in both name and value. So instead of writing a test case with the name of the one particular offer, it is better to use generic terms like ‘Promotional Campaign’
9. No Abbreviations
The Test cases should not be consist of any abbreviation (or) short forms. If in case the usage of an abbreviation is unavoidable, make sure to explain or define what it is in the test case. If not such open-ended information can lead to unnecessary mix-ups.
10. Optimal Distribution of Tests
A component level of verification should always happen only when you are writing functional test cases. You have to make sure that the same is not carried over when writing Integration and System Testing Test Cases. The Test Case document should cover all the types of the Test cases like Functional, Integration, System, and also Smoke Testing Test Cases.
How the test case helps the Testing team:
- Test case helps reduce the time and other resources required for testing.
- It helps to avoid test repetitions for the same feature of the application.
- It plays a major role in reducing the support maintenance cost of the software
- Even if we have to add a new member to the team during the course of the project, the new member will still be able to keep up with the team by reading the test cases.
- It helps to obtain maximum coverage of the application and fulfill the customer requirements
- The test cases help to ensure the quality of the software
- Test cases help us to think thoroughly and approach the process from as many angles as possible.
How to write effective test cases using the software?
The testing community has been writing test cases manually from the very beginning. But if you are looking for any software that reduces the time spent on writing test cases. You could take a look at the below test management systems,
- TEST LINK
- TEST RAIL
Conclusion:
We hope you have enjoyed reading this blog. As a leading software testing service provider, we have always reaped the benefits of writing effective cases. But there is just no defined way to write test cases, as they are written in different formats depending on the project, the requirements, and the team involved. But we must always keep one point in our minds when we are thinking of how to write effective test cases, and that is to think from the point of view of the Client, Developer, End-User, and Tester. Then only we will be able to write quality test cases that will help us achieve 100% coverage.
Comments(0)