Aim: establish how the software behaves or performs against its test specification, as far as the chosen coverage allows. Inputs are the system, hardware and software documents the verification plan names; outputs are the specification and report pairs for overall software testing, software integration, software/hardware integration and component testing. Tests specified or run by the Requirements Manager, Designer or Implementer can be accepted by the Verifier or Validator if fully documented and compliant, with the rationale recorded in their reports. Measuring equipment is suitably calibrated and every test tool is shown fit for purpose. Each test specification sets out objectives; cases, data and expected results; test types; environment, tools, configuration and programs; completion criteria; coverage criteria and target; roles; the requirements covered; and the choice and use of test equipment. Each test report names the testers, gives results and whether objectives and criteria were met, records and summarises failures, keeps cases and results (ideally machine readable), makes tests repeatable and automated where practicable, has automated scripts checked against the specification, records the identity and configuration of hardware, software, equipment, calibration and specification version, and evaluates coverage and completion with deviations noted.
This control maps to 7 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 7 it maps to, and the evidence behind each claim, over MCP and REST.