How do you translate software quality requirements and ISO/IEC 25010:2023 evaluation reports without turning a design target into a test result or a partial test pass into product acceptance? Teams searching for software quality requirements translation, SQuaRE product quality model translation, multilingual QA test metrics, acceptance criteria localisation and software evaluation report translation need to preserve exactly what a product is expected to do, what was measured and who approved it.
Imagine a performance report saying the current build met a 600-millisecond response-time target in one laboratory configuration while peak-load capacity remains untested. A translation that says the product is ‘fast and fully scalable’ replaces controlled evidence with advertising. A translation that says the product ‘failed all performance criteria’ makes the opposite error. The correct version carries the environment, load, metric, result, exception and release decision together.
This educational guide examines translation decisions involving the ISO/IEC 25010:2023 product quality model, a reference framework with nine quality characteristics and associated subcharacteristics for ICT and software products. It deals with requirements, evaluation evidence and handoff language, not a full software testing tutorial or a competing translation master. Examples are fictional and do not claim that any software is certified, secure, safe or compliant with a standard.
Quick answer: identify the product and evaluation boundary, retain the exact quality characteristic and relevant subcharacteristic, distinguish required from measured from accepted, translate metric and unit definitions faithfully, carry forward exceptions, then obtain domain-specialist review before anyone treats the translated statement as a release decision.
Jump to: Edition and scope · Quality translation distinctions · 24 worked cases · Terminology · 10-step workflow · Four-week plan · FAQ · References.
What ISO/IEC 25010:2023 does and does not establish
ISO/IEC 25010:2023 defines a product quality model for ICT and software products, with nine characteristics and further subcharacteristics used to specify, measure and evaluate quality properties. Its model informs requirements, design objectives, test objectives and evaluation criteria. A quality characteristic is not itself a test result; a metric target is not proof that it was met; and the model’s use does not automatically certify a product. This edition is distinct from ISO/IEC 25010:2011, and older taxonomy labels must not be imported blindly.
This guide solves the narrow task of translating software product quality requirements, evaluation metrics and release-evidence documents. It does not teach the entire family of translation methods or replace a formal technical evaluation. The nine-characteristic framework can help organise terms, but it cannot demonstrate that a product meets its requirements by itself. A test report needs actual results, methods, thresholds and context.
The examples below are hypothetical, not a copy of protected standard text, and do not assert certification or performance of a real product. A multilingual user-facing statement should be no more confident than the original measured result. A test field named “status” might describe execution status, defect status, acceptance status or deployment status; a translator must find out which before choosing its target-language equivalent.
Ten software product quality translation traps
1. Model versus measured result
An evaluation team may use a named quality characteristic as a heading while measurements appear in later test reports.
What can go wrong? Translating the category heading as an achieved claim makes the product appear validated before testing. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Separate reference-model terminology, operational definition, measurement and decision. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
2. Product boundaries and test configuration
The reported system may include a server, mobile client, API gateway and third-party identity provider.
What can go wrong? Calling one component’s test a full-system pass changes the assessment boundary. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Keep the system-under-test ID, build, dependency versions, platform and excluded functions. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
3. Reliability and failure handling
Teams report crashes, recovery time, fault tolerance and availability under specified conditions.
What can go wrong? A high observed uptime over a short interval cannot guarantee uninterrupted service worldwide. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Preserve interval, workload, fault type, method and untested conditions. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
4. Performance and resource consumption
Latency, throughput, CPU use, memory and capacity reflect different dimensions of behaviour.
What can go wrong? Conflating response time with processing throughput or tested capacity produces false promises. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Keep units, percentiles, sample counts, traffic shape and environment. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
5. Security and confidentiality
Security results can describe controls, vulnerabilities, penetration tests and remediation plans.
What can go wrong? A fixed vulnerability in one build does not mean the software has no security risks. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: State exact finding, severity, patch version and retest status. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
6. Safety and harm prevention
Some products have safety-relevant failures that must be discussed separately from convenience or security flaws.
What can go wrong? A product quality model heading must not be treated as proof of safety certification. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Describe harm scenario, tested safeguard, approval authority and uncovered residual cases. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
7. Compatibility and integration
Tests may describe coexistence with other products or interoperability across defined interfaces.
What can go wrong? Passing one API contract test does not establish universal compatibility. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Name protocol, version, partner system and direction of data exchange. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
8. Interaction capability and accessibility
User-facing reports may contain task success rates, navigation issues and assistive-technology findings.
What can go wrong? A successful accessibility check on one screen cannot certify the entire application as accessible. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Separate tested user group, task, platform, modality and unresolved barriers. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
9. Maintainability and change impact
Build pipelines, modular design and tests affect effort to analyse, modify and verify code.
What can go wrong? Calling code ‘easy to maintain’ erases the specific evidence and context. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Preserve assessment method, affected module and known technical debt. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
10. Release gates and acceptance authority
A test report can mark a criterion blocked, conditional, waived, passed or accepted.
What can go wrong? A waiver is not a pass; a test pass is not a release authorization. A good translator anchors the phrase in the test requirement ID and the exact build or document version. A reader should be able to follow an individual claim backward from a polished summary to the record that supports it.
Practical review: Check the requirement identifier, responsible reviewer, deviations and change-control decision. Preserve any qualifiers attached to samples, intervals, platforms, dependency versions and unexecuted tests. Before release, ask the product owner whether the translated summary supports the same decision as the original, rather than just whether its vocabulary sounds natural.
Twenty-four worked examples: from source measurement to honest multilingual decision
Each invented example describes the source, a tempting mistranslation, a more faithful meaning model and a verification task. The English contrast is designed to expose meaning shifts across any source and target language; it is not a mandatory translation or a product performance claim.
1. Performance percentile
Evidence context: A p95 latency of 420 ms was observed at 200 concurrent sessions. The tempting but inaccurate version is “Every request finishes in 420 ms under any load.” A metric without its denominator or environment often becomes misleading. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The 95th-percentile latency was 420 ms in the described 200-session test.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Keep percentile, workload, platform and test duration. Operational consequence: A customer must not mistake a sample statistic for a service guarantee. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
2. Capacity not tested
Evidence context: A staging test passed at 1,000 requests per minute; maximum capacity was not measured. The tempting but inaccurate version is “The platform handles unlimited transactions.” Execution status, defect status and acceptance are different decision layers. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The tested load was passed, while maximum capacity remains unestablished.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check test ceiling and unexecuted load cases. Operational consequence: A scaling plan should not be based on an invented capacity. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
3. Availability sample
Evidence context: The service recorded 99.9% availability in a seven-day trial. The tempting but inaccurate version is “The system guarantees 99.9% availability annually.” A pleasant adjective is not a substitute for a measurable result. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The observed availability was 99.9% during the specified seven days.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check monitoring definition and whether maintenance windows were excluded. Operational consequence: A sample observation is not a contractual SLA. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
4. Disaster recovery exercise
Evidence context: A test restored a database in 38 minutes in one controlled drill. The tempting but inaccurate version is “All systems always recover within 38 minutes.” The target-language sentence must carry the source’s uncertainty, not merely its nouns. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The tested database restoration completed in 38 minutes under the drill conditions.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Verify data scope, clock start and other services. Operational consequence: Recovery planning relies on scenario-specific evidence. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
5. Error budget
Evidence context: The team allocated an error budget for a service objective. The tempting but inaccurate version is “The team has permission to ignore user errors.” An unresolved test is an unresolved test even when the release deadline is near. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “An error budget tracks tolerated deviations against a defined reliability objective.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Locate policy and SLO definition. Operational consequence: A monitoring concept must not become a legal permission. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
6. Blocked penetration test
Evidence context: A test case was blocked because a third-party environment was unavailable. The tempting but inaccurate version is “The security test passed.” A metric without its denominator or environment often becomes misleading. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The test was not executed because the required environment was unavailable.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check test execution state and responsible dependency. Operational consequence: A blocker is missing evidence, not a security result. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
7. Vulnerability retest pending
Evidence context: A patch was deployed, but the vulnerability retest is scheduled next week. The tempting but inaccurate version is “The defect is verified as fixed.” Execution status, defect status and acceptance are different decision layers. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “A patch was applied; confirmation by retesting is outstanding.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Match patch build, ticket and retest date. Operational consequence: Release notes must not represent work in progress as confirmed remediation. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
8. Encryption at rest
Evidence context: One database volume uses encryption at rest; export files are not addressed. The tempting but inaccurate version is “All customer data are encrypted everywhere.” A pleasant adjective is not a substitute for a measurable result. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The specified database volume uses at-rest encryption; exports are outside this statement.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Identify data stores and key scope. Operational consequence: The translation must not overstate confidentiality safeguards. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
9. API interoperability
Evidence context: Service A exchanged a valid schema with Service B version 2.4. The tempting but inaccurate version is “The product is compatible with all external software.” The target-language sentence must carry the source’s uncertainty, not merely its nouns. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The specified exchange succeeded with Service B version 2.4.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Retain endpoints, version and schema validation evidence. Operational consequence: Integration scope drives procurement decisions. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
10. Locale formatting
Evidence context: French number formatting passed, but right-to-left layouts were not tested. The tempting but inaccurate version is “The interface supports every international locale.” An unresolved test is an unresolved test even when the release deadline is near. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “French number formatting was verified; RTL layout compatibility was not assessed.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check locale matrix and rendering screenshots. Operational consequence: Global readiness depends on untested language-specific interactions. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
11. Screen-reader task
Evidence context: A named screen-reader completed three checkout tasks on desktop. The tempting but inaccurate version is “The website is fully accessible.” A metric without its denominator or environment often becomes misleading. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The specified assistive technology completed the three tested desktop tasks.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Preserve assistive technology and untested pages. Operational consequence: A narrow test is not a site-wide accessibility verdict. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
12. Keyboard trap
Evidence context: A modal cannot be exited with the keyboard in one browser. The tempting but inaccurate version is “Keyboard navigation is entirely broken.” Execution status, defect status and acceptance are different decision layers. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “An exit interaction failed for the specified modal and browser.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Confirm build, focus path and affected modal. Operational consequence: Precise defect scope supports corrective action. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
13. Memory profiling
Evidence context: Peak memory for one workflow was 1.8 GB. The tempting but inaccurate version is “The application always needs exactly 1.8 GB of memory.” A pleasant adjective is not a substitute for a measurable result. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “A peak of 1.8 GB was measured in the named workflow and environment.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check inputs, concurrency and instrumentation. Operational consequence: Sizing claims should not erase workload dependence. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
14. CPU efficiency
Evidence context: A prototype consumed 40% less CPU than a prior build in one benchmark. The tempting but inaccurate version is “The product is 40% more energy efficient in all use.” The target-language sentence must carry the source’s uncertainty, not merely its nouns. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “CPU usage fell in the specified benchmark; energy consumption was not established.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Retain benchmark and power measurements if any. Operational consequence: CPU and energy efficiency are related but not equivalent. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
15. Data integrity scenario
Evidence context: A test detected that duplicate messages were rejected under one retry policy. The tempting but inaccurate version is “Duplicate data can never occur.” An unresolved test is an unresolved test even when the release deadline is near. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “Duplicate messages were rejected in the tested retry configuration.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check idempotency keys and other ingestion paths. Operational consequence: A narrow behaviour must not become an absolute guarantee. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
16. Backup restore point
Evidence context: The team set a recovery-point objective of four hours. The tempting but inaccurate version is “The system has never lost more than four hours of data.” A metric without its denominator or environment often becomes misleading. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The specified RPO target is four hours; achieved losses require separate evidence.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Distinguish objective from measured outcome. Operational consequence: A target is not a historic record. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
17. Maintainability metric
Evidence context: A static analyzer flagged several high-complexity modules. The tempting but inaccurate version is “The software cannot be maintained.” Execution status, defect status and acceptance are different decision layers. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The analysis identified modules with elevated complexity under the chosen rule.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Confirm thresholds, tool and affected files. Operational consequence: A quality indicator should not become a categorical prediction. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
18. Test coverage
Evidence context: Unit-test line coverage reached 88% in one package. The tempting but inaccurate version is “Eighty-eight percent of possible defects are eliminated.” A pleasant adjective is not a substitute for a measurable result. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The stated package achieved 88% line coverage by the named measure.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Keep metric type and included file set. Operational consequence: Code coverage is not defect-free probability. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
19. Feature completeness
Evidence context: All mandatory functions in a limited release scope were implemented. The tempting but inaccurate version is “The entire product roadmap is finished.” The target-language sentence must carry the source’s uncertainty, not merely its nouns. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The functions required for the stated release scope were implemented.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Verify the requirements baseline and deferred items. Operational consequence: A scope boundary controls truthful readiness claims. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
20. Compatibility exception
Evidence context: An application supports OS versions 14 and 15 but fails one critical workflow on version 13. The tempting but inaccurate version is “The application supports every supported phone.” An unresolved test is an unresolved test even when the release deadline is near. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The tested workflow is supported on versions 14 and 15, with a known failure on 13.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check product support policy and defect severity. Operational consequence: Compatibility statements must identify actual supported environments. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
21. Conditional customer acceptance
Evidence context: A customer signed acceptance subject to correction of two defects. The tempting but inaccurate version is “The release was accepted without reservation.” A metric without its denominator or environment often becomes misleading. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The customer accepted conditionally, with two listed defects outstanding.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Check sign-off letter and due dates. Operational consequence: Conditional acceptance can determine payment or delivery obligations. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
22. Safety mitigation
Evidence context: A safety-related alert was implemented but had not been validated under a power-loss scenario. The tempting but inaccurate version is “The safety system is validated for all operating conditions.” Execution status, defect status and acceptance are different decision layers. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The alert was implemented; power-loss validation remains incomplete.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Review validation matrix and hazard analysis. Operational consequence: A design feature must not masquerade as tested safety assurance. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
23. Security severity
Evidence context: A finding was rated medium according to a named methodology. The tempting but inaccurate version is “The finding is harmless.” A pleasant adjective is not a substitute for a measurable result. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “The assessment assigned the stated medium rating under its specified method.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Keep severity scheme, assumptions and remediation advice. Operational consequence: Different schemes may classify the same issue differently. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
24. Release candidate
Evidence context: A build is labelled RC2 and awaits final acceptance. The tempting but inaccurate version is “The software is in general production.” The target-language sentence must carry the source’s uncertainty, not merely its nouns. This error changes the scope or logical strength of the assertion; it may turn a statistic into a guarantee, an objective into an achievement or a test exception into an unqualified pass.
Meaning-preserving alternative: “RC2 is a release candidate pending final acceptance.” To render this into another language, retain the actor or system component, test conditions, numerator and denominator when relevant, dates, thresholds, test state and exclusions. Change grammatical order if needed for natural reading, but do not replace numbers with promotional adjectives or erase the evidence’s provenance.
Check before approval: Verify deployment channel and approval gate. Operational consequence: Users should not infer production status from a build tag. Keep a translator query for any unexplained metric, unfamiliar unit or contradictory table. The final evidence trail should identify the specification, execution record, approval owner and the exact translated claim; otherwise later readers cannot reconstruct why the language appeared trustworthy.
Twelve technical terms that can change a release decision
1. quality characteristic
In this context, A named category of product quality properties in the model. It is not the same as “proof of a passed test.” Map the heading to the correct edition and keep the result separate. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
2. acceptance criterion
In this context, A defined condition used to judge readiness or suitability. It is not the same as “automatic acceptance.” Check threshold, owner and approval status. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
3. observed latency
In this context, Measured time in a defined environment and workload. It is not the same as “guaranteed response time.” Retain unit, percentile, interval and traffic pattern. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
4. throughput
In this context, Completed work or transactions per period under conditions. It is not the same as “latency.” Keep transaction definition, denominator and time unit. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
5. fault tolerance
In this context, Ability to maintain appropriate function under defined faults. It is not the same as “unlimited availability.” Identify the tested fault modes and excluded failures. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
6. recoverability
In this context, Ability to restore data or operation after interruption. It is not the same as “absence of any interruption.” State recovery target and actual measurement separately. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
7. compatibility
In this context, Ability to work appropriately in a specified shared environment. It is not the same as “support for every platform.” List tested products, versions and constraints. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
8. interoperability
In this context, Exchange and usable interpretation of information through defined interfaces. It is not the same as “mere shared network access.” Record semantics, direction and protocol version. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
9. maintainability
In this context, Quality related to analysing, modifying and testing a product. It is not the same as “guaranteed zero-cost changes.” Tie statement to evidence and module. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
10. security finding
In this context, A result about a stated security property or identified issue. It is not the same as “complete security clearance.” Preserve scope, severity and retest status. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
11. conditional approval
In this context, Permission or acceptance subject to stated obligations. It is not the same as “unconditional release.” Retain conditions and responsible approver. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
12. not evaluated
In this context, No relevant test or judgement completed in this scope. It is not the same as “passed.” Mark genuinely missing evidence rather than a zero score. When the term crosses languages, preserve the local syntax but retain the model edition, field definition, evidence date and approval state. A glossary should carry warnings about near-synonyms as well as approved words; the intended readers need stable meaning, not forced uniformity.
Ten-step QA workflow for translated software evaluation evidence
Step 1: Identify the system
Record system-under-test, build, modules, dependencies, operating environment and translated-document recipient. Do not treat one component test as a system-wide evaluation. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 2: Set the quality-model edition
Confirm the ISO/IEC 25010:2023 edition and terminology used in the actual source. Ask whether older terminology was deliberately retained in a legacy report. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 3: Map requirement identifiers
Create a crosswalk from each quality statement to requirement ID, test case and result record. Preserve status meanings and any references to superseded requirements. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 4: Record metric definitions
Keep units, percentiles, sampling intervals, workloads, denominators, thresholds, confidence qualifiers and instrumentation. Translate the measurement’s definition, not merely its label. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 5: Separate objectives and outcomes
Mark specified, implemented, tested, passed, failed, blocked, deferred, waived, accepted and released as distinct states; do not promote one to another. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 6: Build a termbase
List the quality characteristics and actual field names appearing in the file, with permitted equivalents and notes on false friends. Align with the client’s software glossary. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 7: Translate together with context
Read notes, tables, graphs and release decisions in the same pass. A title, caption or coloured cell can modify the scope of the surrounding translated prose. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 8: Run technical bilingual review
A language expert compares sentence meaning and a test engineer validates whether it matches the actual metric or product state. Either reviewer may identify a different class of error. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 9: Document open issues
Issue queries for missing baselines, undocumented calculations or inconsistent build references. Do not invent results merely because the source report is incomplete. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Step 10: Release with provenance
Deliver translated report, source version, review log and unresolved limitations. If a new test run changes results, update the affected claims under explicit version control. Before final sign-off, ask which operational decision the translated statement could change: a security remediation, acceptance payment, compatibility notice, accessibility commitment or production release. That test focuses review effort where an apparently small wording shift matters.
Four-week learning plan for multilingual engineering teams
Week one: learn the product and record language
Collect a fictional release specification, two test reports and a quality glossary. Identify ten quality claims and map each to a measurable condition. Record the build, evidence date, characteristic and approval owner. Translate the key terms twice, then compare whether their use changes between specification and result.
Week two: practise metric and condition accuracy
Translate six performance and reliability cases into a target language. Ask a bilingual reviewer to recover units, denominators, workloads, percentile and confidence solely from the translation. Mark every sentence that drops a restriction, then correct it while keeping reader-friendly prose.
Week three: review exceptions and status
Practise with blocked tests, partial fixes, retest-pending vulnerabilities and conditional acceptance. Build a status map distinguishing request, implementation, test execution and sign-off. Make the translation compact without collapsing those stages into one generic word like complete.
Week four: simulate a release package
Prepare a 1,200-word mock multilingual product-quality report with tables and a one-page conclusion. Obtain a second-reader meaning audit and a technical evidence audit. Deliver the version history, open queries and final release caveat. The goal is a transparent report, not an imaginary certification.
Frequently asked questions about ISO/IEC 25010 software quality translation
Is ISO/IEC 25010:2023 a software certification?
No. It defines a model of product quality characteristics for requirements and evaluation. A product’s conformity, actual test results and external certification status require separate evidence and process.
Is the 2023 edition the same as 2011?
No. The current edition’s product quality model has nine characteristics; 2011 used a different model and characterisation. Do not silently use old definitions because a legacy test template looks familiar.
Can a metric be translated as a general quality adjective?
Only when the source actually makes that general claim, and even then preserve material qualifiers. Converting a measured percentile to “fast” or a limited fault test to “reliable” often overstates the evidence.
Does a test pass imply customer acceptance?
Not necessarily. A test result addresses a particular criterion and configuration; contractual acceptance or release approval may require additional review, waivers and sign-off.
How should a translator handle an unexplained abbreviation?
Check source glossary, test tool and team context. If unresolved, preserve the code with a query. An abbreviation guessed incorrectly can reverse the significance of an evaluation.
What about AI-translated product quality reports?
Automated drafting may assist, but numbers, logical qualifiers, edition terminology and decision statuses need independent review by qualified humans. Do not let a model invent unstated conditions or evidence.
How is this different from software test plan translation?
This article focuses on product quality characteristics, measured quality evidence and acceptance interpretation. Test plan translation is a separate question about planned cases, steps and expected results.
Where can I study the wider language method?
The existing translation master covers meaning transfer generally; the Vocabulary Learning Hub and How English Works pages give language foundations. This article remains a specialist companion.
Verified edition, independent educational scope and related reading
The official ISO catalogue identifies ISO/IEC 25010:2023 as the second edition, published in November 2023, for the product quality model within SQuaRE. This page is not an authorised reproduction of its protected content and does not promise that software evaluated using the model has been certified or accepted.
Official ISO/IEC 25010:2023 product quality model scope.
For general language transfer continue to Master Art of Translation — Complete System; for word precision use the existing Vocabulary Learning Hub; for language logic visit How English Works — Translation and Meaning Across Languages. These established resources retain their canonical role.