• info@helpingtesters.com
  • helpingtesters

What are the different test artifacts?

June 23, 2017
test artifacts

Talking in layman’s term, Test Artifacts are deliverables or documents which are prepared during the testing process. These documents are shared with different stakeholders like clients, Test Managers, Team members, and other people involved in the project so that every test process are properly recorded and are transparent for all stakeholders. 

Need of Test Artifacts

Test Artifacts are shared with the client and the testing team, and sign-off is taken from the client so that there is no communication gap in what more is required. Also, it is very easy to track changes and be aware of the latest progress of testing activities from the requirement, as everything is on record.



Different Test Artifacts

Test Strategy

The testing strategy is a document which enlists, how to achieve the desired result using available resources. Test Strategy is usually prepared at management level. Mostly prepared by Test Manager.

  • It provides clarity of processes, tools, techniques, approaches, infrastructure etc. Test strategy is used to communicate Test approaches to various stakeholders like the client, Test Managers, Developers, Testers etc.
  • Test Strategy also defines the possible risk factors during testing and mitigation plan to short out the risk. For creating a powerful Test strategy, one is required to have a clear understanding of the client requirements and the expectation from the application.
  • It should even define the timeline of all the phases required to complete the project. Test Strategy should contain the testing tools to be used in the processes, including the bug tracking tool being used. It also describes the environment of testing.
  • In short, Test Strategy describes the approach to complete all the testing process. It also defines entry criteria, exit criteria, resumption criteria defining when to start testing, and when to end testing and when to resume testing. Resourcing and scheduling are also part of Test Strategy.
  • While creating the test strategy, one thing every tester should keep in mind, the Test Strategy should never be static. The result of Test Strategy should be monitored and revised in order to optimize Test strategy for a better Test result.

 

Test Plan

It is a systemic approach for testing a software application. The test plan typically contains a detailed understanding of how the workflow will be. In software testing, a Test Plan contains detailed testing information regarding upcoming testing efforts which include the scope of testing, scheduling, test deliverables, release criteria, risk, and contingencies.

Test Plan template contains the following information

 

  • Test Plan Identifier is used in configuration management and used for versioning of Test plan.
  • References contain all the referred document such as project plan software requirement specification and detailed design document etc.
  • The introduction defines the purpose of defining the Test Plan which covers scope and objective of Test Plan.
  • Software risk issue covers all the possible risk which may arise due to complexity or misunderstanding of various application related requirements. There may also be other reasons causing risk.
  • Features to be tested includes all the features that require being tested in the application.
  • Features not to be tested include all the features that require not to be tested. There are many reasons for mentioning the items which won’t be part of the testing process. Some of the reasons are, these items or modules were already tested earlier and is currently stable or it is to be tested in next cycle. Even very low risk, trivial or rarely used functionalities are left out so that testers can focus and emphasize on the major ones.
  • Entry and exit criteria define when to start testing and when to stop testing. Suspension criteria and resumption criteria define when to suspend testing and when to resume testing. This is done to mark the duration when the application is not fit for testing and is sent back to the development team to release a stable build for testing.
  • Test deliverables are the documents prepared during the testing process and are shared with stakeholders. 
  • Responsibilities include who will be responsible for which testing process.
  • Risk mitigation and contingency strategies lay down the guidelines for all the possible risks that the testing team might encounter and the different ways to handle them, once they arise.
  • Approvals need to be taken for the testing process, the various testing related documents and for the various deliverables. The glossary includes terms and terminology to be used during the testing process.

 

Test Scenario

It explains what to test in the application. Test scenario may be defined as the high-level definition of test condition from which one or many test cases can be formed. Test Scenario contains the situation in the application from which many test cases can be prepared.
For example, consider a “Login” test scenario for the login page of the application. Many positive and negative test cases can be prepared from this scenario for successful and unsuccessful login actions.

 

Test Case

Talking in simpler terms, a test case may be defined as a set of detailed steps along with the expected results. Before looking into various components of a test case or knowing what the test cases comprise of, we need to know the importance of test case and how it is used in software testing.

If a tester is required to test any system or test any requirement to ensure that it satisfies the base requirements of the system under test, one is required to design a test case. Now in order to design the test, one is required to have overall idea of what needs to be tested, what action one is going to take, what are the parameters which will be required as input for doing test and what are the expectations which is required to be met after performing action or operation on the system.
Now, this overall idea should be documented for a series of operations that need to be performed on the system. Documentation can be done on paper or excel sheet or test case management system.
In order to document everything in a test case, one is required to have inputs or ideas regarding requirement. The idea or input can be taken from requirement document. It can be in the form of Business Requirement Document, Software Requirement Specification document, Functional requirement document, non-functional requirement document, Technical Documents, Use Cases or User Stories.

There might even be circumstances when there are no requirement documents available and the tester is required to make test cases. In such situation, it is recommended to get the requirement by having a meeting with the project stakeholders.
These stakeholders may be Product Owner, Business Analysts, Senior Developers, Project Manager or Scrum Master. Test Case template usually contains:

      • Test Case ID
      • Test Case Name
      • Test Case Description
      • Test StepsExpected Result
      • Actual Result
      • Application/Release Name
      • Pass/Fail status.

 

Traceability Matrix

The first time you hear about requirements matrix, it may seem complex, but once you understand it, working with on it can be very easy. Requirement traceability matrix, as the name indicates is a matrix that contains tables which show many to many relationships between the requirement and the test cases.

If the project has multiple requirements and multiple test cases, then there comes the need of the requirements traceability matrix in the form of a table that shows the relationship between the requirement and the test cases.
The matrix shows which requirements are implemented by which one test case or test cases and which test case/ cases are mapped to which specific requirement or requirements.
Sometimes, requirements traceability matrix can be a big matrix which can be divided by the number of tables.

There can be a mapping of the business requirement to software requirement, so if there is a high-level business requirement, then there can be a one-to-many relationship and one business requirement may be broken down into several software requirements and there can be a mapping between the test cases and automated test scripts for every test case.

There is also the concept of forward traceability and backward traceability matrix. The forward traceability matrix ensures whether the project is on the right path. This matrix checks whether each and every requirement is actually implemented. On the other hand, the backward traceability matrix maps test cases to requirements to ensure that the testability and test coverage is at par with the code coverage.

 

Software Test Report

It is a report on the testing activities. From Test report, information like what each testing resources are doing, what is the progress of testing and what is the quality of the application being tested, is available.

The test report can be of different types. It can be an individual Test report or a team report prepared by the collaboration of an individual tester or a pool of testers. It can be a daily Test report or it can be final Test Report after completion of testing or after release (meaning at the end of testing cycle).
In the test report, you can include Project name, Test cycle number, Types of testing done like manual testing automation testing, performance testing, ad-hoc testing, security testing etc. Also one can include Test status of the Tests like how many tests are in progress, how many tests have been completed and how many Tests are pending.

Test report also contains the report from bug tracking tool or bug management system and contain information like how many bugs have been reported, how many bugs have been closed and how many still in open state. All this information regarding bug is maintained in the Test report. Also, Test Report can contain observations and recommendations, if any. It can also include the status of the feature that was to be tested. This report can be shared with Stakeholders like Client, Test Manager, Developers and other team members. From this Test report, one can communicate to Stakeholders the current responsibilities of each testing resource, the progress of testing, and the status of the bugs found. Such detailed information helps in getting the overview of the overall quality of the application being tested.

Conclusion

Overall, we can say that Test Artifacts are important documents prepared during testing activities and shared with all stakeholders so that everybody is clear about the requirement and progress made in testing activities. Every test artifacts mentioned above should never be static and should be modified from time to time as the application evolves and new functionalities are added.

About the author

RamPrakash Singh author

Ram Prakash has worked in various domains of testing including security, performance, security testing and automation testing. Including several tools like QTP, selenium, LoadRunner,JMeter, VSTS Coded UI, soap UI, Burp Suite etc.

Leave a Reply

Your email address will not be published.