Verification Workflows

For a detailed explanation of workflows and their role within the process model, please refer to the Introduction.

Create/Perform Unit Test		status: valid
tags: implementation, verification contains: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence has: doc_concept__verification_process, doc_getstrt__verification_process, doc_concept__imp_concept, doc_getstrt__imp_getstrt needs input: wp__sw_implementation, wp__verification_plan outputs: wp__verification_sw_unit_test responsible: rl__contributor approved by: rl__committer supported by: rl__safety_manager satisfied by: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_req__verification_checks, gd_req__verification_checks_extended
Every Unit shall have at least one Unit Test. They verify the detailed design of the implementation. Unit tests are automatically executed as part of the CI after PR merge. In case of changes at inputs, the workflow need to be executed again as part of maintenance. Any contributor can create a component test and create a PR for it. During the review process the test cases will be approved by a committer. Committer and contributor need to differ. The actual Committer of the implementation can also be the creator of the unit tests. Independence is achieved by different approver at PRs and by the Module Verification Report. The typical steps when creating a unit tests are: Check the detailed design of the component. Create a test for every interface of the unit showing at least every flow in dynamic diagrams. Follow the detailed design to the component requirements and test these requirements. Fill in the test attributes based on the previous steps and provide a description. Link the test against detailed design or component requirement.
wf__verification_unit_test		Workflow

Create/Maintain Component Integration Test		status: valid
tags: verification, verification contains: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_guidl__verification_specification has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__component_arch, wp__sw_implementation, wp__requirements_comp, wp__requirements_comp_aou, wp__verification_plan outputs: wp__verification_comp_int_test responsible: rl__contributor approved by: rl__committer, rl__testing_community supported by: rl__safety_manager satisfied by: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_req__verification_checks, gd_req__verification_checks_extended, gd_req__verification_external_aou
Component Integration test cases are based on component architecture and component requirements. They also cover the detailed design and integration of units forming a component. The integration testing of component architecture is optional in case a component is standalone and has no (sub-)components. Any contributor can create a component integration test and create a PR for it. During the review process the test cases will be approved by a committer. Committer and contributor need to differ. The tests are automatically executed as part of the CI after PR merge. In case of changes at inputs, the workflow need to be executed again as part of maintenance.
wf__verification_comp_int_test		Workflow

Create/Maintain Feature Integration Test		status: valid
tags: verification, verification contains: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_guidl__verification_specification has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__feature_arch, wp__requirements_feat, wp__requirements_feat_aou, wp__verification_plan outputs: wp__verification_feat_int_test responsible: rl__contributor approved by: rl__committer, rl__testing_community supported by: rl__safety_manager satisfied by: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_req__verification_checks, gd_req__verification_checks_extended, gd_req__verification_external_aou
Feature Integration test cases are based on feature requirements and architecture of a specific feature. Any contributor can create a feature integration test and create a PR for it. During the review process the test cases will be approved by a committer. Committer and contributor need to differ. The tests are automatically executed as part of the CI after PR merge. In case of changes at inputs, the workflow need to be executed again as part of maintenance.
wf__verification_feat_int_test		Workflow

Create/Maintain Platform Integration Test		status: valid
tags: verification, platform, verification contains: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_guidl__verification_specification has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__requirements_stkh, wp__verification_plan outputs: wp__verification_platform_int_test responsible: rl__contributor approved by: rl__committer, rl__testing_community supported by: rl__safety_manager satisfied by: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_req__verification_checks, gd_req__verification_checks_extended
Platform Integration Test cases are based on Stakeholder requirements. This is the highest test level. Any contributor can create a platform integration test and create a PR for it. During the review process the test cases will be approved by a committer. Committer and contributor need to differ. The tests are automatically executed as part of the CI after PR merge. In case of changes at inputs, the workflow need to be executed again as part of maintenance.
wf__verification_platform_int_test		Workflow

Create Verification Plan		status: valid
tags: verification, verification contains: gd_guidl__verification_guide, gd_temp__verification_plan has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__requirements_stkh, wp__platform_mgmt, wp__tool_verification_report outputs: wp__verification_plan responsible: rl__committer, rl__testing_community approved by: rl__project_lead supported by: rl__safety_manager, rl__infrastructure_tooling_community
The verification plan is created by Committer. It clearly outlines all aspects of the verification activities, provide a roadmap for the verification efforts throughout the software development lifecycle. The plan should be dynamic and updated as needed throughout the project lifecycle by Maintain Verification Plan.
wf__verification_plan		Workflow

Maintain Verification Plan		status: valid
tags: verification, verification contains: gd_guidl__verification_guide, gd_temp__verification_plan has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__verification_plan, wp__requirements_stkh, wp__platform_mgmt, wp__feature_arch, wp__requirements_feat, wp__requirements_feat_aou, wp__component_arch, wp__requirements_comp, wp__requirements_comp_aou, wp__tool_verification_report outputs: wp__verification_plan responsible: rl__committer, rl__testing_community approved by: rl__project_lead supported by: rl__safety_manager, rl__infrastructure_tooling_community
The verification plan is maintained by Committer. The plan should be dynamic and updated as needed throughout the project lifecycle, as verification activities may be impacted, by new requirements, architectural decisions, introduction of tools. Note that during the initial creation of the verification plan in Create Verification Plan not every input down to component level may be available.
wf__verification_plan_maintain		Workflow

Set Requirement Test Coverage		status: valid
tags: verification, verification contains: gd_req__req_attr_test_covered, gd_req__req_suspicious, gd_guidl__verification_guide has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__requirements_stkh, wp__requirements_feat, wp__requirements_feat_aou, wp__requirements_comp, wp__requirements_comp_aou, wp__verification_plan, wp__verification_sw_unit_test, wp__verification_comp_int_test, wp__verification_feat_int_test, wp__verification_platform_int_test outputs: wp__requirements_stkh, wp__requirements_feat, wp__requirements_feat_aou, wp__requirements_comp, wp__requirements_comp_aou responsible: rl__committer, rl__testing_community approved by: rl__project_lead supported by: rl__safety_manager, rl__security_manager
The requirement attribute complete test coverage is set to yes by a Committer when it is verified that the requirement is fully covered by test cases. This means the linked test cases in sum fully satisfy the requirement. A fully covered requirement will be set to no automatically via the implementation of the check described in Requirement check: suspicious. A recheck is needed in this case to get the status back to yes.
wf__verification_req_test_coverage		Workflow

Create Module Verification Report		status: valid
tags: verification, verification contains: gd_temp__mod_ver_report has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__verification_plan, wp__requirements_comp, wp__requirements_comp_aou, wp__component_arch, wp__module_sw_release_note, wp__platform_mgmt, wp__sw_component_fmea, wp__sw_component_dfa, wp__sw_arch_verification, wp__sw_implementation_inspection, wp__requirements_inspect, wp__verification_comp_int_test, wp__verification_sw_unit_test outputs: wp__verification_module_ver_report responsible: rl__committer, rl__testing_community approved by: rl__project_lead supported by: rl__safety_manager, rl__infrastructure_tooling_community, rl__contributor satisfied by: gd_req__verification_reporting, gd_req__verification_report_archiving
The verification report is created and maintained by a Committer. It is based on the Verification Plan and covers all the components of a developed module. This includes their requirements, AoUs, Architecture, Detailed Design, Units, DFA, Safety Analyses, Unit Code coverage. The respective necessary test methods and rigor of their application is defined in the Verification Plan. In case of externally provided pre-existing software maintained outside of the project, the Module Verification Report also applies as documentation for the Qualification Verification Report. The respective component(s) are verified with the same methods and deviation techniques as mentioned in the Verification Plan. The report will be filled by the Committer responsible for integration of the external component and will get support by the Contributor who proposed the component to the added to the project scope. The report is valid for ONE version of a module.
wf__verification_mod_ver_report		Workflow

Create Platform Verification Report		status: valid
tags: verification, platform, verification contains: gd_temp__platform_ver_report has: doc_concept__verification_process, doc_getstrt__verification_process needs input: wp__verification_plan, wp__requirements_stkh, wp__requirements_feat, wp__requirements_feat_aou, wp__feature_arch, wp__platform_sw_release_note, wp__platform_mgmt, wp__feature_fmea, wp__feature_dfa, wp__platform_dfa, wp__sw_arch_verification, wp__requirements_inspect, wp__verification_feat_int_test, wp__verification_platform_int_test outputs: wp__verification_platform_ver_report responsible: rl__committer, rl__testing_community approved by: rl__project_lead supported by: rl__safety_manager, rl__infrastructure_tooling_community
The verification report is created and maintained by a Committer. It is based on the Verification Plan and covers all the selected features of a SW platform. This includes their requirements, AoUs, Architecture, DFA, Safety Analyses, The respective necessary test methods and rigor of their application is defined in the Verification Plan and Platform Management Plan. The report is valid for ONE specific platform version baseline.
wf__verification_platform_ver_report		Workflow

RAS(IC) for Verification:

No needs passed the filters