The documentation of artefacts created prior to and throughout the testing of software is called Test documentation. The testing team uses the test documentation to estimate the testing effort (that is needed), execution progress, resource tracking and test coverage. 

It is a complete suite of documents that allows one to describe and document test planning, test design, test execution, and test results that are derived from the testing activity. 

While it is generally believed that testing is executing the various sections of code on an ad-hoc basis and verifying the results, in actuality, it is a very formal activity which is documented in detail. 

Test documentation makes the planning, review, and execution of testing verifiable and easy. Functional testing or even any other type of testing without documentation renders it difficult to see the complete picture. Every team member can access complete information about all the testing activities that have been and will be undertaken in the project. 

Since every member may have a different understanding of a common goal, it is important to be specific about it and test documentation accomplishes that.

The degree of test formality depends on:

  • The application type under test
  • The standards followed by the organization
  • How mature the development process is

Typically, testing takes up anywhere between 30% and 50% of the effort of a software development project. And documentations are a big help in identifying the test process improvement that can be applied to future projects. 

Without documentation, the QA engineers’ task will be seriously impacted, especially while working on complex products and under oft-changing requirements. 

The lack of documentation will render it impossible to figure out how a feature is supposed to behave or why it leads to errors in the first place. Wrong prioritization as a result of lack of documentation results in skipping defects and presenting incomplete reports.

Types of Test Documentation

1. Test Policy

It is a high-level document describing the principles, methods and important testing goals of the organization.

2. Test Strategy

It is a high-level document that spots the test levels that need to be executed for the project.

3. Test Plan

It is a complete planning document containing the object, scope, approach, resources, strategy, risks, work schedule, etc. of all test activities. Everything that a tester needs to do in the project is made available here. Typically, a test plan is drawn up by an experienced testing professional.

4. Requirements Matrix

It is a document that connects the requirements to the test cases for configuration testing as well as other types of testing. 

5. Software Requirements Specifications

It is a complete description of the properties and features of the software under development. It helps avoid misunderstandings of the objective and the process in the team.

6. Test Scenario

It is an item or event of a software system that is verified by one or more test cases.

7. Use Case

It is a less official document which is based on assumptions about what a user will do and which button they will click, thereby allowing testers to check the user paths. Use cases are created in order to address business requirements and objectives. 

8. Test case

It is a document containing a highly detailed and specific description of the steps that a QA engineer needs to perform to test one portion of functionality, comprising a group of input values, execution preconditions, expected execution postconditions and results. It is developed for a test scenario.

9. Test Data 

It exists before a test is executed and is used to execute the test case.

10. Defect/Bug Report

It is a documented report of flaws in a software system that does not perform as expected. It provides full information about the defect and the steps to reproduce the bug.

11. Test Summary Report

It is a high-level document that summarizes test activities and the test results.

Best Practices for Optimal Test Documentation 

  • Involving the QA right from the beginning of the project so that test documentation is created in parallel
  • Using version control to track and manage documents
  • Documenting what is needed for an understanding of the project and what is needed to produce to the stakeholders
  • Creating and, importantly, regularly updating the document
  • Using a standard template like an excel sheet or doc file for documentation 
  • Storing all project-related documents in a single location that is accessible to the team for reference as well as updation
  • Providing adequate detail while creating a test document

You might also like to read: All you need to know about Usability Testing. 

Merits of Test Documentation

  • It reduces or eliminates any uncertainties about the testing activities and it resolves ambiguity about task allocation.
  • Showcasing test documentation reveals a mature testing process and is a fine marketing strategy for the organization.
  • Documentation offers a systematic approach to software testing and it serves as training material for beginners in the software testing process.
  • Offers a standard quality product to the client within a specified time and improves transparency.
  • In software engineering, test documentation helps to configure the program through the configuration document and operator manuals.

Demerits of Test Documentation

  • The time-consuming nature of test documentation means that the costs surpass the value.
  • Often, when the document is written by people who either cannot write well or are not adequately aware of the material, the documentation is of little use. 
  • It is a tedious and tiresome task to keep track of all the changes requested by the client and to update the corresponding documents.
  • Poor documentation directly reflects the quality of the product, leading to a misunderstanding between the client and the organization.

Conclusion

In conclusion, the larger the project, the more detailed documentation is required. Using a checklist alone will surely cause misconceptions about the goal and scope of the project. 

Test documentation is not merely a static report or document but is dynamic in nature: it needs to be regularly updated. When requirements change and priorities shift, test coverage and the necessary resources change as well. 

Failing to record this in the documentation will result in inconsistencies and errors in the process. The QA engineers need to cover with tests every new functionality.