Aim: analyse and test the combined software and hardware for compliance with the Software Requirements Specification, stressing functional and safety aspects by integrity level, and check fitness for the intended application. Outputs are the Overall Software Test Report, the Software Validation Report and the Release Note. The Tester writes the test report per the generic rules and records all test and analysis results; the Validator may specify and run extra tests or have the Tester run them. The software is exercised against real hardware or systems it will connect to, or against simulated inputs and loads driven by its outputs, in normal running, in foreseeable events and in undesired situations that call for system action; simulation is shown not to differ statically or dynamically from operation, and any difference is analysed to decide which tests must run in the real environment. The Validator's report, written once integration and overall testing are complete, states whether the validation plan was met with deviations justified, summarises whether the complete software running on its target meets its requirements, evaluates requirements test coverage and other verification with a check that requirement tracing is complete, documents any Validator-only tests, confirms each Annex A technique combination suits the level and evaluates its overall effectiveness given software size, complexity and results, and addresses the software identity and configuration, support software and equipment, simulation models, adequacy of the overall test specification, correctness of the release notes, tracking and risk evaluation of deviations, handling of corrective actions under change management, each restriction arising from deviations, and a conclusion on fitness given application conditions. Discrepancies (errors, non-compliances with the standard, requirements or plans, constraints and limitations) sit in a separate subclause of the report, are evaluated against the integrity level and carried into the Release Note, which states software and hardware compatibility and every restriction and condition of use derived from detected errors, non-compliances and partial fulfilment of requirements or plans.
This control maps to 8 controls across 4 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 8 it maps to, and the evidence behind each claim, over MCP and REST.