Testing Documentation

Testing documentation is the documentation of artifacts that are created during or before the testing of a software application. Documentation reflects the importance of processes for the customer, individual and organization.

Projects which contain all documents have a high level of maturity. Careful documentation can save the time, efforts and wealth of the organization.

There is the necessary reference document, which is prepared by every test engineer before stating the test execution process. Generally, we write the test document whenever the developers are busy in writing the code.

Once the test document is ready, the entire test execution process depends on the test document. The primary objective for writing a test document is to decrease or eliminate the doubts related to the testing activities.

Types of test document

In software testing, we have various types of test document, which are as follows:

• Test scenarios
• Test case
• Test plan
• Requirement traceability matrix(RTM)
• Test strategy
• Test data
• Bug report
• Test execution report

Test Scenarios

It is a document that defines the multiple ways or combinations of testing the application. Generally, it is prepared to understand the flow of an application. It does not consist of any inputs and navigation steps.

For more information about test scenario, refers to the below link:

https://www.javatpoint.com/test-scenario

Test case

It is an in-details document that describes step by step procedure to test an application. It consists of the complete navigation steps and inputs and all the scenarios that need to be tested for the application. We will write the test case to maintain the consistency, or every tester will follow the same approach for organizing the test document.

For more information about test case, refers to the below link:

https://www.javatpoint.com/test-case

Test plan

It is a document that is prepared by the managers or test lead. It consists of all information about the testing activities. The test plan consists of multiple components such as Objectives, Scope, Approach, Test Environments, Test methodology, Template, Role & Responsibility, Effort estimation, Entry and Exit criteria, Schedule, Tools, Defect tracking, Test Deliverable, Assumption, Risk, and Mitigation Plan or Contingency Plan.

For more information about the test plan, refers to the below link:

https://www.javatpoint.com/test-plan

Requirement Traceability Matrix (RTM)

The Requirement traceability matrix [RTM] is a document which ensures that all the test case has been covered. This document is created before the test execution process to verify that we did not miss writing any test case for the particular requirement.

For more information about RTM, refers to the below link:

https://www.javatpoint.com/traceability-matrix

Test strategy

The test strategy is a high-level document, which is used to verify the test types (levels) to be executed for the product and also describe that what kind of technique has to be used and which module is going to be tested. The Project Manager can approve it. It includes the multiple components such as documentation formats, objective, test processes, scope, and customer communication strategy, etc. we cannot modify the test strategy.

Test data

It is data that occurs before the test is executed. It is mainly used when we are implementing the test case. Mostly, we will have the test data in the Excel sheet format and entered manually while performing the test case.

The test data can be used to check the expected result, which means that when the test data is entered, the expected outcome will meet the actual result and also check the application performance by entering the in-correct input data.

Bug report

The bug report is a document where we maintain a summary of all the bugs which occurred during the testing process. This is a crucial document for both the developers and test engineers because, with the help of bug reports, they can easily track the defects, report the bug, change the status of bugs which are fixed successfully, and also avoid their repetition in further process.

Test execution report

It is the document prepared by test leads after the entire testing execution process is completed. The test summary report defines the constancy of the product, and it contains information like the modules, the number of written test cases, executed, pass, fail, and their percentage. And each module has a separate spreadsheet of their respective module.

Why documentation is needed

If the testing or development team gets software that is not working correctly and developed by someone else, so to find the error, the team will first need a document. Now, if the documents are available then the team will quickly find out the cause of the error by examining documentation. But, if the documents are not available then the tester need to do black box and white box testing again, which will waste the time and money of the organization.More than that, Lack of documentation becomes a problem for acceptance.

Example

Let's take a real-time example of Microsoft, Microsoft launch every product with proper user guidelines and documents, which are very explanatory, logically consistent and easy to understand for any user. These are all the reasons behind their successful products.

Benefits of using Documentation

• Documentation clarifies the quality of methods and objectives.
• It ensures internal coordination when a customer uses software application.
• It ensures clarity about the stability of tasks and performance.
• It provides feedback on preventive tasks.
• It provides feedback for your planning cycle.
• It creates objective evidence for the performance of the quality management system.
• If we write the test document, we can't forget the values which we put in the first phase.
• It is also a time-saving process because we can easily refer to the text document.
• It is also consistent because we will test on the same value.

The drawback of the test document

• It is a bit tedious because we have to maintain the modification provided by the customer and parallel change in the document.
• If the test documentation is not proper, it will replicate the quality of the application.
• Sometimes it is written by that person who does not have the product knowledge.
• Sometimes the cost of the document will be exceeding its value.