What content and functions does the software test report contain?

Key points of this article

The core of the test report is to answer "what was tested, what were the results, and whether it can be put online", rather than listing all test cases.
A complete report usually includes basic information, test scope, environment, execution results, defect summary, risks and conclusions.
The pass rate and number of defects must be accompanied by statistical caliber and range, otherwise readers cannot judge the meaning of the numbers.
There is no unified word count standard for reports. The length should be determined by the project scale and the needs of the readers. The key lies in whether the information is complete and whether the conclusions can be quickly located.
Determine the chapter framework first and then fill in the data to avoid random changes in the structure; use the title level to build the structure in a Word-compatible editor, making modification and reuse more convenient.

The software test report is the formal output of the testing work and is responsible for telling the project manager, development, product and operation and maintenance: what was covered by the test, what problems were found, and what is the current quality status. When writing reports, many testers either paste the entire use case execution record or just write "test passed". As a result, readers can see neither the basis nor the risks.

This article is written for people who need to write or review test reports, especially newcomers who have just taken over the test document and are not sure which chapters to write. After reading, you can judge which parts the report should contain, what questions each part should answer, know how to roughly control the length, and be able to put together the structure using Word-compatible editing methods.

The following will first answer the core questions, then discuss the composition, functions and common misunderstandings of the report, and finally explain how to use the document editing function of OmniDoc.

What is the content of the software testing report? One sentence conclusion

Software testing reports usually include six parts: basic information, testing scope, testing environment, execution results, defect summary, risks and remaining issues, and testing conclusions. The core is to provide traceable data and clear go-live judgments. The specific level to write depends on the scale of the project and the needs of the readers.

your situation	Recommended practices	reason
Small function iteration, only test a single module	Keep five parts: basic information, scope, execution results, defects, and conclusion. Just a few paragraphs for each part.	Readers are concerned about whether this change introduces problems, and the short length makes it easier to read.
Full system version testing	All six parts are retained, and the environment and defects parts are written in more detail.	Involving multiple environments and multiple versions, it is necessary to clarify which environment each conclusion applies to
Requires online approval	The conclusion part is divided into a separate section to clarify the "yes/conditional/not required" online conditions.	Decision makers usually look directly at the conclusion, and judgments must have basis and premises.
Stage report mid-test	Focus on writing the completed scope, progress, current defect trends and blocking items	The stage report does not need to give a final conclusion, but it should clarify what remains to be tested.
Need to be handed over to client or external team	Add test environment description and version correspondence, and remove internal remarks	External readers lack context and need full context and caliber description

What parts does a report usually contain?

A complete test report is generally organized in the following order, with each section answering a specific question.

Basic information: project name, version number under test, test cycle, writer, reviewer, writing date. This section lets readers know which version the report is for and when it was published.
Test Scope and Objectives: Which functional modules and requirements will be covered by this test, and what content will be clearly excluded. Only when the scope is written clearly will the subsequent conclusions have boundaries.
Test environment: operating system, browser or client version, server configuration, test data source. The same conclusion may have different meanings in different circumstances, and the circumstances must be clearly stated.
Test methods and execution results: Type of test adopted (function, interface, compatibility, performance, etc.), total number of test cases, number of executed, passed, failed, blocked and unexecuted.
Defect Summary: Count the number of defects according to their severity, and list the important defects that have not been closed and their numbers, status and impact.
Risks and legacy issues: unresolved defects, uncovered scenarios, dependent external conditions, and their possible impacts.
Test conclusion and suggestions: Make a judgment on the quality status, and give opinions and prerequisites on whether to recommend going online.

What is the function of the report?

Test reports have three main functions.

Provides a basis for decision-making: The project manager decides whether the version can be released and whether it needs to be postponed based on this. The conclusions and risk items in the report are direct inputs for decision-making.
Make problems traceable: Through the defect number, use case number and version number, development and testing can be aligned. When an online problem occurs, you can also review what was tested and what risks were left.
Keep process records: The report is written evidence of the project quality, which is convenient for review, summary of experience, and reference for subsequent iterations.

Who should report it to? Who is the reviewer?

Many people will ask "Who is the reviewer of the software testing report?" Usually, the report writer is the test leader or test engineer, who is responsible for data statistics and conclusion writing; the reviewer is usually the test manager, project manager, or development leader, who is responsible for confirming whether the scope and conclusions are reasonable. The readers of the report include product, development, operations and management. The report should also indicate the writer and reviewer, with clear responsibilities.

Common misunderstandings and areas of confusion

Misunderstanding 1: A report is a list of use cases. Use cases are the input to the test, and reports are the output of the test. By listing hundreds of use cases one by one, readers will not be able to grasp the key points. The correct approach is to summarize statistics and only attach details of key use cases or failed use cases when necessary.

Misunderstanding 2: All passed means good quality. A high pass rate does not mean adequate coverage. If the test scope is very narrow, or a large number of use cases are not executed, then there is no reference value if they all pass. The report should state both the implementation rate and the coverage so that readers can understand the premise of the pass rate.

Misunderstanding 3: Pass rate and number of defects can be viewed separately. The same 10 defects, if 3 of them are critical defects and not fixed, the conclusion is completely different. The number of defects should be considered based on severity and repair status.

A point of confusion: test plans, test reports and defect reports. The test plan is written before the test, describing how it is planned to be tested; the test report is written after the test, describing what was actually tested and what the results were; the defect report focuses on a single problem, describing the steps and phenomena to reproduce it. The three have different readers and uses and should not be substituted for each other.

📊 Core comparison

Document	When to write	The main question to answer	Typical reader
Test plan	Before the test begins,	What are you going to test, what method will be used, and when will it be completed?	Project manager, test team
Test case	Test preparation phase	How is each function verified and what is the expected result?	Testers, developers
Defect report	When a problem is found	How does a problem reappear and what is its impact?	Developers, testers
Test report	End of test phase or version node	What has been tested, what is the result, and can it be online?	Project manager, product, management

# how to use it

In OmniDoc, you can use a Word-compatible online editor to build a test report structure, as follows.

Open app.unidoc.top and create a new document, which is a web editor that supports Word-compatible editing.

two. According to the previous chapter order, use the title level to build the framework: basic information, test scope, test environment, implementation results, defect summary, risk and legacy issues, test conclusions. Determine the structure first, and then fill in the content, you can avoid the structure out of shape in the middle of the writing.

Fill in the data in the corresponding section: version number, number of use cases executed, defect number and severity, etc. The contents of the table class are presented directly in the table, which is easy for readers to compare.
After writing, check chapter by chapter: whether each conclusion is supported by data or basis, whether the passing rate indicates the scope of implementation, and whether the remaining problems are explained.
If you need to work with the desktop version, you can download the OmniDoc Desktop client (download.omnidoc.top) and continue to edit similar documents in the document editor; if the report contains materials that flow in the form of PDF, you can also deal with it in the desktop client's PDF editor, such as comparing the two versions of the report, OCR the file and then copy the content.

It should be noted here that what OmniDoc can do is to organize the structure and content of the report, and the test conclusions of the report still need to be judged by the testers according to the actual situation.

# which method is suitable for you?

- just started writing the report : first use the six parts of this article as a template, write one or two sentences in each part, and then gradually fill in the details. - frequent reports : fix a set of chapters and table styles and replace only version numbers, dates and data at a time to reduce duplication of work. - the report needs to be reviewed by multiple people *: clearly write down the reviewer and audit opinions in the conclusion section to avoid the conclusion being revised back and forth and the version confused.

# frequently asked questions (FAQ)

1. How many words are there in the software test report?

There is no uniform word count standard. The report for small iterations may be only a few pages, and the version of the complete system is much longer. To judge whether the length is appropriate, look at two points: whether the reader can find a conclusion in a few minutes, and whether all the data and risks have been explained. Instead of pursuing the number of words, it is better to pursue the integrity of information and clear structure.

2. Must all test cases be attached to the test report?

You don't have to. The report should summarize the execution of the use case and list the number of the key failure use case or important use case. The complete use case details can be kept separately from the report as attachments or links, so that the text can be kept concise.

3. How should the pass rate be calculated?

The pass rate is usually calculated by dividing the number of use cases passed by the number of use cases executed. It should be noted that unexecuted use cases should not be counted as passed, and the implementation rate should be listed in the report to let the reader know how many executed use cases the pass rate is based on.

4. Can the conclusion of the test report be "basically passed"?

Yes, but state the specific meaning of "basically passed", such as which features have been passed, which still have legacy defects, and whether the prerequisites for going online are met. Vague conclusions can easily lead to misjudgment by decision makers, and it is suggested that they should be clearly written as "with online conditions", "qualified with online conditions" or "not with online conditions", and list the corresponding conditions.

5. Do you need to check the figures in the report?

Need. Machine statistics or data derived from tools should be checked with the original records of defect systems and use case systems, especially the number and status of defects, before submission. If foreign language materials processed by machine translation or OCR are used in the report, the important contents should also be checked item by item.

# Summary

The core of the software test report is to clarify the test scope, execution results, defect status and on-line judgment, and each part should be based and traceable. First determine the chapter framework, and then fill in the data, and explain the premise and risk in the conclusion, the report can really serve the project decision-making. Using a Word-compatible editor to build the structure at the title level allows the framework to be used repeatedly in each version.

Open OmniDoc to edit and export documents online