Test Artifacts

code

Maintaining transparency among team members and stakeholders is extremely important nowadays. From updating them about the process to delivering various documents and reports related to a particular project, everything needs to be communicated clearly in order to help them understand the project and its process.

Similarly, during the process of software development, developers and testers generate various documents, plans, reports, among other things, that are delivered and shared with the team and other stakeholders after the commencement of the whole project. These deliverable, which are shared by the software engineers with their team and client are known as artifacts and are an integral part of the whole life cycle.

What are Test Artifacts?

An integral part of software testing, test artifacts are the various by-products generated during the process of software testing, which are then shared with the clients, team managers, team lead, and other team members and stakeholders associated with the project. The main purpose of these artifacts is to establish transparency among the team members and therefore are recorded properly with accurate information and details.

These artifacts help testers know the requirements of the clients and the stakeholders as well as allows them to ensure that there is no miscommunication between them.

Moreover, with the assistance of these test artifacts it becomes easy for the concerned people to track the changes in the software as well as be aware of the latest progress of the testing activities as everything is recorded properly in the form of defect report, test closure report, etc.

Types of Test Artifacts:

Produced by the people involved in the process of testing and delivered & shared with stakeholders of the project, test artifacts are provided before, during, and after the testing phases. These are extremely important for explaining the process of testing and for effective communication between the team members. Therefore, here is a list of some of the test artifacts/deliverables produced during the process of testing.

Test Strategy: Prepared by the Test Manager, test strategy defines a set of guiding principles that further enlightens the test design and regulates how testing needs to be performed. It provides clarity of the testing process, tools, techniques, approaches, infrastructure, etc. Set at the organizational level, the test strategy can be used by anyone and though it is flexible, it cannot be changed by them. Test strategy mainly includes components like:

    • Testing objectives & scope.
    • Documentation formats.
    • Test processes and techniques.
    • Team reporting structure.
    • Client communication strategy, among other things.

Test Plan: Test plan is usually confused with test strategy, but these are vastly different from one another and cater to different requirements of the software. Test Plan mainly deals with the scope, objective, and approach of testing and is majorly used for formally testing the software. It is highly dependent on the processes, standards, and test management tools being implemented during the process of testing. Moreover, the test plan is a more systematic approach of testing software, as it identifies the features to be tested, the tasks performed during the process, the degree of test independence, the test design techniques, and entry and exit criteria to be used.

Test Case: Another important deliverable, test case consists of a unique identifier, requirement references from a design specification, precondition, event, a series of steps to follow, input & output, among other things. Test cases are mainly designed to verify compliance against specific requirements and tests the correct behavior, functionality, and features of the software. It acts as the starting point of the test execution and usually consists of the following components:

    • Test case ID.
    • Test case name.
    • Test case description.
    • Steps of test execution.
    • Expected & Actual Outputs.
    • Reports of test success and failure.

“Test Data”: This is the input given to the software program and is required throughout the process. Produced by the software tester or programmer, these are designed and created in a focused and systematic manner. Test cases that are designed poorly might not be able to test all test scenarios, which can hamper the quality of testing as well as the software. Moreover, these are either developed manually or with the assistance of automated tools.

Requirement Traceability Matrix: Maintained in a table format, this document correlates two documents and defines the relationship between them. It captures the requirements proposed by the client or software development team and links these requirements throughout the validation process. The purpose of this “traceability matrix” is to verify that all the requirements are defined for a system and are tested in the test protocol. In short, it is used to track the stated requirement and to define the relationship between these requirements and test cases.

Test Coverage Matrix: This calculates the amount of testing performed by a set of test cases. Additionally, it measures the effectiveness of testing by providing data on different components of the software. With the assistance of test coverage matrix testers can create new test cases for better and full “test coverage”. Moreover, it allows them to find the area of requirements that are not implemented by the test cases during the process of testing.
Test Scripts: In software testing, “test scripts” have an immensely important role. It defines the instructions that are performed on the software under test to validate that the software functions as intended. These are mainly used in automated testing.
Test Log: Another important test artifact, the test log contains all the information regarding the executed test. From the test name, time, date, passed and failed tests, errors detected, to other relevant information, every important and necessary information is recorded in this log for the reference of the team.

Defect Reports: One of the most significant and important reports generated during the process of software testing, a defect report consists of all the defects, errors, bugs, and other discrepancies found while testing the software. The purpose of this report is to define the defects in such a manner that they can be easily replicated and fixed by the developers. It is with the assistance of this report that the developers are made aware of the defects in the system, which are then rectified to improve the quality of the software.
Test Closure Report: An important deliverable, “test closure/summary report” is prepared at the end of the software testing process. The main objective of this document is to explain the process of testing and the activities performed during the process to the team manager or other stakeholders of the project. Created by the team lead, this report summarizes the whole testing process once the “exit criteria” is successfully achieved.

Conclusion:

From the above discussion, we can say that test artifacts are important documents that are delivered to the client and other stakeholders of the project to define the process of testing as well as to help them understand the whole testing activity. With the assistance of these document testers and developers are able to build software that is free of any defects and that offers great quality and performance.

Mark Funk
Mark Funk is an experienced information security specialist who works with enterprises to mature and improve their enterprise security programs. Previously, he worked as a security news reporter.