TOM DEMARCO says, “ you can’t control what you can't measure.” Test artifacts are a set of documents, which the tester of a software project gets during the software testing life cycle (SDLC / STLC). It is to monitor and also to control the process and product. It helps to drive the project towards the planned goals without any deviation.
DIFFERENT TEST ARTIFACTS IN SOFTWARE TESTING :
There are different types of test artifacts. Not all the software products will go through every process mentioned below. The following are a set of test deliverables that are commonly prepared during the process of software testing.
TEST STRATEGY :
The first or foremost step in test artifacts is to design a strategy. Test strategy explains the way the testing should happen. It gives a set of guidelines on how to determine the scope, documentation formats, test process, and client communication strategy. Once the strategy is set, the test manager decides on what module to test. Only after the preparation of the test strategy document, the testers can proceed with other artifacts and testing process. The test strategy should be standard throughout the process. The tester needs to make sure they are working according to the planned approach.
TEST PLAN :
“To plan is to act.” A test plan is a detailed document that outlines the test strategy, testing objectives, resources required for testing, test schedule and test deliverables. Test planning describes the scope, scheduled in the test activities. It also allocates the task for each test environment. It measures the amount of risk involved in the process. Test plan contains the test ID, the features to be tested, the entry and exit criteria and then the type of testing.
When you need to execute a particular function or a feature in the software application, we require test cases. We give a set of conditions to each test cases, and the tester determines if the input satisfies the defined objective in software testing. In general, the QA team is responsible to write the Test cases. The Test cases will examine the expected and actual result and gives a pass or fail status at the time of execution. These test cases usually contain the title, description, test steps, expected result, and actual result. It is essential to write the test cases as it has a significant impact on the testing phase.
Let us look at some places where we can use the test case.
TEST CASE 1:
To check results on entering valid user ID and password.
TEST CASE 2:
Checking results on entering the invalid user ID and password.
TEST CASE 3:
To check whether the login button works without entering the login ID.
TEST CASE 4:
Try to log in without providing any password and check the response.
It plays a crucial role while doing actual testing. It contains both positive and negative data to perform positive/negative testing. We work on the test data in database or .xls or .csv file or any other format and use that while doing testing. Most of the companies get real-time historical data from the client and use it while testing.
REQUIREMENT TRACEABILITY MATRIX:
It is a document which ensures that every requirement has a test case.
We write test cases taking the requirements as the basis and then we execute those test cases. If we write the test cases regardless of the test environment, then we cannot test specific features which might have some bugs associated with it. To ensure that we cover all the requirements, we write the traceability matrix. The requirement matrix changes from company to company and project to project.
TEST COVERAGE MATRIX:
Test coverage assures the quality of the test. It benefits you in preventing defect leakage. Gaps in requirements, test cases, defects at the unit level and code level can be found easily. We can accomplish it by transforming the ad-hoc defects into executable test cases.
To achieve the objective of each test case you would write a test script. A test script is writing a set of chronological steps to validate a test case.
After executing the test case we have to report in the Test Log document. It consists of percent of test case pass criteria and percent of test case fail criteria. In addition, this criterion is useful in exit criteria to take the decision of whether we have to stop testing or not. In other words, Test Log is a repository to store pass/fail test cases.
The tester identifies the defect and creates a defect report to state the problem as clearly as possible so that the developers can replicate the defect easily and fix it. The document contains the products name, test Id, the project release version, the summary, the results, remarks, the defect severity, defect priority, etc. The report also mentions the testers name and details to report the defect effectively.
TEST CLOSURE REPORTS:
This is the final document in test artifacts. This document gives a consolidated version of the software testing life cycle. It the report on the testing activities. The benefit of this report is to communicate the system status to the stakeholders about the project and the team. The testing team discuss and analyze the artifacts and evaluate the test cycle completion criteria. It identifies strategies that have to be implemented in the future. The entry criteria in this phase are test case execution report, opened and closed test defect reports. The exit criteria are the test closure reports signed up by the client and test metrics.
Some important activities in this phase:
Evaluate test cycle completion criteria
Prepare test metrics
Documentation of the learning from the project
Prepare test closure report
Deliverables in this phase :
Test closure report and