Learn All About Test Deliverables In Software Testing With Examples:
A sigh of relief comes for every tester when the assignment bestowed is completed successfully. At the end of every testing, the tester must send the appropriate test deliverables to the client.
In this article, we will take a look at some of the important test deliverables in detail.
Test deliverables, in general, are used throughout a project. They are used in all phases of testing and they always have to be sent on time to proceed with further processing.
Table of Contents:
Test Deliverables In Software Testing
Test Deliverables play an important role in Software Testing. This article discusses all Test Deliverables in detail.
Some of the important test deliverables are enlisted below for your reference:
- Test strategy
- Test plan and estimation
- Test scenario
- Test cases and test data
- RTM
- Test summary report
- Test closure report
- Incident report
Test Strategy
Test strategy will be decided based on the Business requirement specification. It is a vital document that contains all the details of the testing work to be carried on. It is a complete management document.
When compared to the test plan, this is a high-level document and is usually prepared by the Test manager or lead. Test objective, test approach, test scope, entry & exit criteria, types & levels of testing, milestones, staffing, etc must be mentioned here.
Test Plan and Estimation
The granular level details for each step of testing should be mentioned here. In general, a proper plan leads to a proper work structure. Similarly, a good plan leads to good testing.
The Test objective, test approach, test scope, entry & exit criteria, types & levels of testing, milestones, staffing, etc should be mentioned here in a detailed manner.
The master plan which includes how testing is to be carried is used for simple projects.
Estimation: Estimation is defining how long each step will occur in testing along with the overall cost.
Also, Read => A Perfect Test Plan Tutorial – An In-Depth Guide
Test Scenario
We will understand this with an example now. Let us take the train reservation as an example here. All the functionalities that we need to test are mentioned in high-level forms in the test scenario document. In simple words, it means a group of similar activities to be performed.
Two Techniques for the scenario:
#1) Use Case
It is the goal-oriented method which is a set of interactions between the external factors and the system. Its components include primary flow, alternate flow, triggers or activities, exception flows, pre-conditions, post-conditions, etc.
Example:
[image source]
#2) ACE (Activity Component Element)
The Activity Component Element process breaks the business requirements into activities.
Example:
In general, we book a ticket by filling in the passenger details, gender, etc. Hence we need to validate the following fields which thereby become scenarios.
- Reservation: Check the reservation functionality.
- Passenger details: Check the gender, age, and sex fields functionality.
- Modify: Check if the modified functionality works properly.
- Concession: Check if the concession functionality works properly.
- View: Check if the view functionality works properly.
- Cancel: Check if the cancel functionality works properly.
Here, the concession may be called as an “alternate scenario” as the user can book with or without it based on age. However, the goal is the same i.e. to book a ticket.
Test Case
By taking the same above example of the reservation page, the test cases are written as follows:
Reservation:
- Check if the user can book a ticket by filling in valid details in all the fields.
- Check if the user can book a ticket by filling invalid details in all the fields.
- Check if the user can book a ticket by leaving any blank field.
Passenger details:
- Check if the user can book a ticket by entering a valid name.
- Check if the user can book a ticket by entering an invalid name.
- Check if the user can book a ticket by choosing any one gender at a time.
- Check if the user can book a ticket by entering an age greater than 60.
- Check if the user can book a ticket by entering an age less than 60.
- Check if the user can book a ticket by entering any valid age greater than 5.
- Check if the user is not able to book by entering an age less than 5.
Modify:
- Check if the user can modify the name field.
- Check if the user can modify the gender field.
- Check if the user can modify the age field.
Concession:
- Check if the user can get a concession by selecting the “Senior citizen” option.
- Check if the user can get a concession by selecting the “Handicapped/Disabled” option.
View:
- Check if the user can view the ticket reserved.
Cancel:
- Check if the user can cancel the ticket.
Thus test cases tell what exactly needs to be tested in detail. Test cases have to be written in simple language and should be easily understandable. It should be written in proper format as asked by the concerned client.
Test Data
Some project needs prior data from the client before proceeding with the execution of the test case. Test data need to be applied to perform testing.
Example: In the hospital portal for getting an injection, it is important to get the patient details to check the injection reminder option.
Here the “patient details” is the test data.
Suggested Read => Test Data – Meaning & Preparation Techniques With Examples
RTM/ Requirement Traceability Matrix
- As the name implies, it simply means that you have to map every requirement with the appropriate test case.
- It helps us in checking if we have covered all the requirements in our test cases or not.
- It helps in rework or the next successive releases of a project.
- The client can easily check our coverage status and know our testing process.
Test Summary Report
Test Summary Report summarizes all the test activities done and the test results are compiled in it. All the test information such as members involved in testing, objectives, scope, client details, test approach used, test results, defect report, etc should be mentioned here.
However, the test summary report should be prepared as per the client’s advice. Thus it is a useful document for the client as well to review the overall performance.
Test Closure Report
It means that we are going to close the project after testing and defect fixing. Thus here we have to provide a detailed analysis of the execution of the tests.
The defects found, and fixed must be mentioned here. The overall requirement coverage is seen in this report. It is generally prepared by the team lead or manager. All the exit criteria should be satisfied accordingly.
Incident Report
While performing formation execution if a user finds defects, then an Incident report (IR) should be raised. This means that there is a defect and thus the execution has to be stopped. We now need to raise an incident report to the client for asking them permission to execute the error areas again as a separate test case.
This indeed is a black mark and is not expected from a tester. All the defects have to be found in the dry run itself. If it is missed and found in formal execution, then it becomes an IR.
Example:
If I miss certain functionality in mobile testing say the “screensaver change” option. Then while executing a test case I get locked and I will not be able to proceed further because of this option. Then I raise an IR and write a separate test case to execute the screensaver option.
Conclusion
The artifacts that are sent to the stakeholders of a software project during the STLC are known as Test Deliverables. We had a look at the most important Test Deliverables in this article.
We hope this article helped you learn about Test Deliverables in Software Testing!!