How to write software testing evaluation: indicators and writing points

Key points of this article

Test evaluation should answer questions about the quality, where the risks are, and whether it can be released. It is not about relisting the test data.
Write down the formula and denominator for each indicator, and explain which module and type of risk it affects.
You can only choose between three conclusions: can be published, conditionally published (state the conditions), and not recommended for publication.
Unexecuted use cases, uncovered modules and restricted environments must be written out, otherwise the conclusions will be misinterpreted.

After writing test execution and test reports, many people will get stuck on the last part: test evaluation. The report lists the number of use cases and defects, but it is unclear whether "this version can be launched online"; or the conclusion only says "test passed", and no one knows what the basis is during the review.

Test evaluation and test report are not the same thing. The report records the process and data, and the evaluation makes judgments based on these data to answer questions about the quality, where the risks are, and whether it can be released. This article explains how to select indicators, how to organize indicators into evaluations, how to write conclusions, and provides steps for writing in Word. After reading it, you should be able to write a test evaluation that is well-founded and can be reviewed by others.

How to write a software testing evaluation? One sentence conclusion

First select several indicators that can reflect quality according to the test objectives, explain the data and basis one by one, and finally give a clear conclusion. Don't just list numbers.

your situation	Recommended practices	reason
The requirements are clear and it is necessary to confirm whether the functions are met	Mainly based on demand coverage and use case pass rate	Directly corresponds to "did it happen or didn't do it, did it right or didn't do it"
As release approaches, focus on legacy risks	Mainly based on the number of serious defects and the distribution of unclosed defects	It is usually high-risk items that determine whether they can be released
There are code-level testing requirements	Increase statement coverage and branch coverage	Describes the extent to which the code is executed
Multiple rounds of iteration, want to see trends	Compare the defect detection and repair status of each round	It is difficult to judge whether a single number is good or bad
Review targets are management or customers	The conclusion comes first, and the indicators are attached as the basis.	Readers must first make judgments and then verify data

Before you start: Confirm these points first

Who is the reader of the review? For R&D, reproduction and positioning information should be written clearly, while for project managers or release decision-makers, risks and conclusions should be highlighted. The reader determines the detail and length.
Whether the acceptance criteria have been agreed upon. Evaluation needs to be based on pre-agreed standards. Without standards, we can only describe the data but cannot judge whether it is good or bad. This should be explained in the text.
Whether the data are taken from the same time point. If the use case status and defect data are exported twice, the numbers will easily not match up, resulting in untenable conclusions.
Whether the indicator caliber is unified. Whether "defects" include suggestions, duplicate orders, and unrepeatable orders needs to be determined first and noted in the text.
What content was not measured. Unexecuted use cases, uncovered modules, and restricted test environments must be written separately, and you cannot only write the parts with good results.

Steps to write a test review in Word

Determine the chapter structure. Common practices are: evaluation scope, indicator results, problem analysis, risk description, conclusions and recommendations.
Organize the original data table. Export use case execution and defect statistics from the test management tool, organize them into tables, and retain the original numbers required to calculate indicators.
Calculate indicators item by item and write formulas. For example, "use case pass rate = number of passed use cases ÷ number of executed use cases", the result can be expressed as a decimal or a percentage, and the denominator must indicate the number of use cases executed in this round.
Interpret each indicator. The number itself does not explain the problem. It is necessary to write clearly what it means and which modules or functions it affects.
Summary the problems and risks. List serious defects, non-covered items and environmental restrictions one by one, indicating the scope of impact and impact on release.
Form a conclusion. Choose one of the three options: "can be released", "conditional release (specify conditions)" and "not recommended for release yet" and list the basis.
Unified format. Unify the units and decimal places, and add numbers and titles to tables to ensure that the same indicator is written consistently throughout the text.
Processing when bilingual or multi-person collaboration is required. If the team has English readers, you can use the OmniDoc desktop client to translate the entire Word document and select a bilingual version; you can also edit it in the UniDoc web editor (app.unidoc.top) to maintain Word compatibility. Machine-translated terms and numbers require manual verification.

Check each item after completion

Check items	How to see	What to do if there is a problem
Do the conclusions correspond to the indicators?	The numbers cited in the conclusions can be found in the data sheet	If the numbers are inconsistent, check the original data and modify it after unifying the caliber.
Whether the denominator is stated	Each percentage indicates the range of the numerator and denominator	Supplementary calculation scope, such as "use cases executed in this round"
Are all remaining issues listed?	Unclosed defects, unexecuted use cases, and uncovered modules are all recorded	Supplement the list and mark the impact on the release
Are the conditions for a conditional conclusion verifiable?	Every condition can be checked explicitly	Change vague conditions into specific retest or supplementary test requirements
Are the bilingual versions consistent?	The terminology is unified and there is no misalignment between numbers and tables.	Manually check terms and figures and correct them before sending them out

📊 Core comparison

There are three common ways of writing test evaluations. The main difference lies in whether readers can make judgments based on them.

Writing method	What readers get	Main questions
Just list numbers	With original data, you can calculate it yourself	No conclusion can be seen and it is difficult to use it for decision-making
Numbers plus a conclusion	Conclusion, short length	The conclusion lacks basis and is easily questioned during the review
Four-stage structure of indicators, basis, risk and conclusion	You can see the judgment process, and you can also see the conditions and restrictions.	Writing takes a long time, and standards need to be aligned in advance

❓ Frequently Asked Questions (FAQ)

1. What is the difference between test evaluation and test report?

The test report records the test process and data, and the test evaluation makes judgments based on these data. The report answers "what was done", and the evaluation answers "how is the quality and can it be published?"

2. How to draw conclusions without clear acceptance criteria?

First align the standards with the demander or project leader. If it is too late, you can indicate "judgment based on the agreed scope" in the evaluation and list the assumptions based on it item by item.

3. If the number of defects is small, does it mean the quality is good?

uncertain. It also depends on whether the test coverage is sufficient, which modules the defects are distributed in, and their severity. If some modules are not measured, a small number of defects may mask the real risk.

4. When there are remaining issues, should the conclusion be written as "passed" or "conditionally passed"?

If the remaining issues do not affect the core functions, you can write a conditional conclusion and list the conditions, such as "it can be released after a certain defect is fixed and the regression is completed." When legacy issues affect the core process, it is recommended to write "not recommended for release yet".

5. Can the English test evaluation of machine translation be used directly?

Not recommended for direct use. Professional terms, abbreviations and numbers must be checked one by one, especially the indicator names and calculation formulas, before being sent to external readers.

📝 Summary

The key to how to write a software test evaluation is to first select indicators that can reflect quality, write down the formulas and basis, and then give a clear conditional or unconditional conclusion. Only by writing the unmeasured parts and risks clearly can the evaluation stand up to review. Follow the above steps to organize it in Word, and the structure and conclusion will be clearer.

Open OmniDoc, edit and export documents online