How to write a software testing confirmation report: structure and key points

Key points of this article

The test summary report explains what was tested and found, confirms whether the report answers can be released or accepted, and is handed over to the signatory for decision.
The confirmation report must indicate the source of the tested version number, build number, test environment and passing conditions, otherwise the person to sign will not be clear.
When there are remaining defects, the conclusion should be written as "conditional pass" and list the conditions, defect numbers and avoidance methods.
Export the PDF to lock the content before signing. If you want to modify it after signing, you should issue a revised version and sign again.

Before and after release, the project team will often receive a document that needs to be signed: the test confirmation report. It determines whether the version can be launched online or whether Party A can accept it. Many people have test summary reports in their hands, but they cannot tell the difference between the two. They directly regard the defect list and use case statistics as confirmation conclusions. As a result, the signatories cannot tell whether they can be released.

This article is written for engineers, project managers and acceptance leaders responsible for testing. After reading, you will be able to distinguish what the two documents do, know what parts the confirmation report should contain, get a signature confirmation wording that can be directly reused, and master the verification method before signing.

How to write a software test confirmation report? One sentence conclusion

The confirmation report answers "Can this version be delivered or accepted?" and gives the conclusion to the person with the authority to make the decision for signature. The test summary report answers "what was measured, what were the results, and what problems were found" and is the basis to support the confirmation conclusion. The two can be two independent documents, or the confirmation report can reference the summary report as an attachment.

your situation	Recommended practices	reason
Internal release, only need internal confirmation from the project	Place the confirmation report at the end of the summary report and attach a signature page	There are few documents, and the conclusions and basis are in the same place, making it easy to trace.
Party A’s acceptance or acceptance as agreed in the contract	Issue a separate confirmation report, citing the summary report number as an attachment	The accepting party usually only looks at the conclusion and signature page, and independent documents are more clear.
Release with remaining bugs	State the conditions for conditional passing, remaining defect numbers and avoidance methods.	The signatory must know what risks he has accepted and cannot just write "passed"
Test multiple subsystems separately	Give a conclusion for each subsystem, and finally give the overall conclusion	When parts fail, the overall conclusion will not be misinterpreted
The signatory is not in the same place	Export to PDF and initiate online signature	The signed version is fixed and the signature record can be traced

Before you start: Confirm these points first

Signature and signing authority: First determine who has the authority to approve release or acceptance, usually the project leader, product leader or Party A’s contact person. If the signer is wrong, the conclusion will not be valid no matter how complete it is.
Version number and test environment: The confirmation report must indicate the version number, build number and test environment under test. Without a version number, the person signing is uncertain.
Source of acceptance criteria: The passing conditions should come from the acceptance clauses in the requirements document or contract, rather than being improvised by testers. Write down the source of the standard clearly so that there will be a basis for disputes when they arise.
Deadline time for defect status: The summary date should be fixed, and the number and grade distribution of defects at the cutoff time point should be stated. Defects that are repaired after signing should be separately stated in the report.
Uncovered content: List the functions, compatible environments and performance items that have not been tested or have only been partially tested, and explain the reasons. Writing this clearly will protect the signer better than silence.

Steps to write a confirmation report in Word

Create a new Word document and first use the title style to set up the chapters: report overview, test basis, test conclusion, remaining issues, and signature confirmation. If you want to edit on a web page, you can use UniDoc Web Editor (app.unidoc.top), which supports Word-compatible editing.
Fill in the basic information form, including project name, version number under test, build number, test environment, test cycle and writer. Each item should be on its own line to facilitate quick verification by the signer.
Write the test basis, list the number and version of the requirements document, acceptance criteria and test summary report, and explain what materials the conclusion is based on.
Write the test conclusion, giving "pass", "conditional pass" or "fail" in one sentence, and then support it with verifiable facts, such as "all core use cases have been executed and all blocking defects have been closed."
List the remaining issues, list the unclosed defects by level, and indicate the number, scope of impact, avoidance method and planned repair version for each item.
Write down the risks and limitations, explain the uncovered items and known risks, and suggest what needs to be monitored after going online.
Create a signature page with a table listing roles, names, titles, signatures, and dates, leaving plenty of white space.
Export to PDF. Export a PDF version to lock content before signing. If you need to sign remotely, you can use OmniDoc to initiate an online signature request and let the signer complete the signing online.

Signature confirmation wording reference

The wording of the conclusion should correspond to the facts and avoid vague "basically no problem". The following three paragraphs can be changed according to the actual situation.

Passed wording: After evaluation by the testing team, the core functions of a certain version of the project (version number, build number) within the test scope have passed acceptance. The remaining issues are listed in Section 1. After the evaluation, it will not affect the launch. Agree to publish the conclusions of this report.

Wording of conditional approval: This version may be released only if the conditions listed in Section 1 are met. It will not be released until the conditions are met. Signing constitutes acceptance of the remaining risks listed in Section 1.

Failed wording: This version has blocking flaws, see Section 1 for details. It is recommended to resubmit for confirmation after repairing and completing regression testing.

Check each item after completion

Check items	How to see	What should you do if there's a problem?
Version information	The version number and build number in the report match the actual delivered package	Re-export after updating and notify signatories
Conclusion and data	Conclusions such as "pass" correspond to the implementation of the use case and the number of defects	If the conclusion conflicts with the data, the conclusion should be revised based on the data
leaving behind defects	Each unclosed defect has an number, an impact description, and a workaround	Missing information defects should be returned to the defective system to fill in
Standard sources	Each passing condition can be traced back to the requirements or contract terms	If you can't find the source, first confirm with the buyer before writing it
Signature page	Characters, names, and dates are complete, and the signatory has the appropriate permissions	If permissions are not met, the signatory should be changed; do not sign on behalf of others

If the report cites a foreign language requirement or scanned contract, it should be manually verified before referencing. There may be discrepancies between machine translation and OCR results; key clauses should be based on the original text.

❓ Frequently Asked Questions (FAQ)

1. Can the test confirmation report and the test summary report be combined into one account?

Yes, you can. Internal publishing scenarios often merge but place conclusions at the front and the basis later, with the signature page separated to make it easy for signatories to view directly.

2. If there are serious defects that haven't been fixed yet, can you write "Pass"?

Not recommended. If the blocking defect is not closed, write "Not Passed". If the team accepts a conditional online list, it should be written as "conditionally passed" and list the conditions and risks.

3. Do I need to have both a signed and editable version of the confirmation report?

Usually, yes. The editable version is for revisions, while the signed version is exported as a PDF with a version number; both must be consistent in content.

4. If errors are found in the report after signing, how should it be handled?

Don't just change the signed version directly. A revised version should be issued, specifying the changes, reasons, and dates, and the signing procedure should be re-completed.

5. How long should the confirmation report take?

Clearly state the conclusions, basis, remaining issues, and signature pages. Length is not the main point; the key is that the signatory can find conclusions and verify evidence within minutes.

📝 Summary

The core of the test confirmation report is the correspondence among conclusions, the basis, and the responsibility for signing. Clearly state the version number, the source of the approval conditions, and any lingering risks, then end with verifiable signature wording, so the signatory can make decisions with confidence.

Open OmniDoc to edit and export documents online