Incorparating CoPilot review findings

Signed-off-by: Philipp Ahmann <philipp.ahmann@de.bosch.com>

Author: pahmann

process/process_areas/verification/guidance/verification_guideline.rst

@@ -100,12 +100,12 @@ execute affected test cases locally upfront using the execution framework of the
 following basically the steps the CI does locally.
 
 Tests have to be identifiable by a unique identifier, as described in :need:`gd_guidl__verification_specification`.
-They need need to have a clear passed or failed result and a documented configuration to enable proper evaluation of the result.
+They need to have a clear pass/fail result and a documented configuration to enable proper evaluation of the result.
 
 Automated tests can also be executed locally, as the sources and binaries are available for re-execution.
 Failing test cases during re-execution can be reported following the guide :need:`gd_temp__problem_template`.
 
-During a relase, for any non executed test case, the reason for non-execution has to be documented in the
+During a release, for any non-executed test case, the reason for non-execution must be documented in the
 :need:`wp__platform_sw_release_note` or :need:`wp__module_sw_release_plan` depending on the level (unit to platform) of the test case.
 
 Execution of manual test cases
@@ -136,20 +136,18 @@ in the :need:`wp__verification_plan`. Due to the high degree of automation, it i
 that a pass rate lower 95% is not acceptable. This percentage may increase with the maturity of
 the overall platform and the test coverage.
 
-In case an existing test case is failing due to regression in the CI, the respective issue of the
-PR in their role as :need:`rl__contributor` is responsible for fixing the test case as part of
-respective PR.
+In case an existing test case is failing due to regression in the CI, the PR author in their role as
+:need:`rl__contributor` is responsible for fixing the test case as part of the respective PR.
 
 Test case results are also documented in the :need:`wp__verification_platform_ver_report` and
 :need:`wp__verification_module_ver_report`.
 
 Reporting of not executed or skipped test cases
 -----------------------------------------------
 
-In case a test case is not executed or skipped, a rational has to be provided in the release notes
-in case they are link against a requirement. A skipped or not executed test case is not counting into
-the value for the requirements coverage, as only executed and passed test cases can be counted for the
-coverage of a requirement.
+In case a test case is not executed or skipped, a rationale has to be provided in the release notes
+if the test case is linked to a requirement. A skipped or non-executed test case does not count towards
+requirement coverage, as only executed and passed test cases can be counted for the coverage of a requirement.
 
 Skipped or not executed test cases are also documented in the :need:`wp__verification_platform_ver_report` and
 :need:`wp__verification_module_ver_report`.

process/process_areas/verification/guidance/verification_process_reqs.rst

@@ -146,7 +146,7 @@ Process Requirements
     The tool automation shall automatically generate the Verification reports.
     These may be independent documents (i.e. not integrated into docs-as-code based repositories).
     The content of the reports is specified in :need:`gd_temp__platform_ver_report` and :need:`gd_temp__mod_ver_report`.
-    The execution results of a test cases are marked with a clear passed of failed result.
+    The execution results of test cases are marked with a clear pass/fail result.
 
 .. gd_req:: Verification Report Archiving
     :id: gd_req__verification_report_archiving

process/process_areas/verification/guidance/verification_specification.rst

@@ -83,14 +83,14 @@ A test specification contains the following attributes.
 
 The implementation of :need:`wp__verification_plan` defines the full list of allowed types and methods.
 
-It is assumed that tests will be written as code (also for manual tests, which are script based)
-and each test case will have a unique identifier, by its script, execution call, or function name.
-The call used to execute the test marks the uniqueness of the test case and its identification,
-e.g. guaranteeing proper traceability and reproducibility.
+It is assumed that tests will be written as code (also for manual tests, which are script-based)
+and that each test case will have a unique identifier (e.g. its script name, execution call, or function name).
+The invocation used to execute the test defines the test case identification, thereby guaranteeing
+proper traceability and reproducibility.
 
-As the tests are stored in a repository close to the implementation code, versioning is done by the versioning of the repository.
+As the tests are stored in a repository close to the implementation code, versioning is handled by the repository's version control.
 
-Any specification and resulting implementation ends with a clear passed or failed result.
+Any specification and resulting implementation ends with a clear pass/fail result.
 
 Test description
 ----------------

process/process_areas/verification/verification_concept.rst

@@ -170,7 +170,7 @@ The verification of requirements of types "Process" and "Non-Functional" will be
 which is part of the requirement inspection :need:`doc__feature_name_req_inspection` and `Component Requirements Inspection Checklist <https://eclipse-score.github.io/module_template/main/score/component_example/docs/requirements/chklst_req_inspection.html>`__.
 Requirements always include Assumptions Of Use.
 
-A more detailed description of how to link code to requirements is available by :need:`gd_req__verification_link_tests`.
+A more detailed description of how to link code to requirements is available here: :need:`gd_req__verification_link_tests`.
 
 Another element of traceability for a proper backlink is the unique identification of test cases as described in the
 :need:`gd_guidl__verification_specification`.