UNDER CONSTRUCTION
This testing is performed as individual modules of code are combined into larger units of code for integration into a system. There are two sub activities in testing. The development of plans and procedures provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned testing activities to ensure the outcome will meet the expectations and goals of the project. Test reports ensure that the results of verification activities are documented and stored in the configuration management system for use in acceptance reviews or readiness reviews. Before software testing begins, all software items are placed under configuration control. This configuration control captures and identifies the versions of what is being tested. Test results are the basis for confirming that the team has fulfilled the software requirements in the resulting software product. To make such decisions, test results must be reviewed and evaluated using a documented, repeatable process. The team can derive quality conclusions by capturing the actual test results, comparing them to expected results, analyzing those results against pre-established criteria, and documenting that analysis/evaluation process. Validation is a process of evaluating work products to ensure that the right behaviors have been built into the work products. The right behaviors adequately describe what the system is supposed to do and what the system is supposed to do under adverse conditions. They may also describe what the system is not supposed to do. Validation is performed to assure that the specified software systems fulfill their intended use when placed on the targeted platform in the target environment (or simulated target environment). To identify which lines of source code have been tested and which lines of your source code have not been tested and to provide data showing the completeness of the executed software tests. The purpose of regression testing is to ensure that changes made to the software have not introduced new defects. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software. To ensure no new defects are injected into the previously integrated or tested software, the project manager should both plan and conduct regression testing to demonstrate the newly integrated software. Verify by the test that any safety features related to system hazards, fault trees, or FMEA events are reliable and work as planned. Any uploaded or uplinked data, rules, and code can affect the behavior of the software and/or system. Special acceptance tests should be developed to validate and verify the uplinked or uploaded information for nominal and off-nominal scenarios. Software testing is required to ensure that the software meets the agreed requirements and design, the application works as expected, the application doesn’t contain serious bugs and the software meets its intended use as per user expectations. Testing of embedded COTS, GOTS, MOTS, Open Source Software (OSS), or reused software component should be at the same level required to accept a custom-developed software component for its intended use. Testing is an activity that is constantly being performed as the software products are developed and become available in release packages. testing cycles are driven by: a. Software test plan(s). Independent validation and verification (IV&V) is a part of Software Assurance playing a role in the NASA software risk mitigation strategy. OSMA is responsible for determining which projects have IV&V for NASA in conjunction with the responsible Mission Directorate. The rationale for independent validation and verification (IV&V) on a project is to reduce the risk of failures due to software and provide assurance that the software will operate as intended, not operate unexpectedly and respond appropriately to adverse conditions. Performing IV&V on projects yields greater confidence that the delivered software products are error-free and meet the customer’s needs. IV&V across the project life cycle increases the likelihood of uncovering high-risk errors early in the life cycle. IV&V is a technical discipline of software assurance that employs rigorous analysis and testing methodologies to identify objective evidence and conclusions to provide an independent assessment of critical products and processes throughout the software development life cycle. The evaluation of products and processes throughout the life cycle demonstrates whether the software is fit for nominal operations (required functionality, safety, dependability, etc.) and off-nominal conditions (response to faults, responses to hazardous conditions, etc.). The goal of the IV&V effort is to contribute assurance conclusions provided to the project and stakeholders based on evidence found in software development artifacts and risks associated with the intended behaviors of the software. The rationale for independent validation and verification (IV&V) on a project is to reduce the risk of failures due to software. Performing IV&V on projects yields greater confidence that the delivered software products are error-free and meet the customer’s needs. IV&V across the project life cycle increases the likelihood of uncovering high-risk errors early in the life cycle. The IV&V Project Execution Plans (IPEP) documents the activities, methods, level of rigor, environments, tailoring (if any) of the IV&V requirements, and criteria to be used in performing verification and validation of in-scope system/software behaviors (including responsible software components) determined by the planning and scoping effort. IV&V artifacts and products required to perform the IV&V analysis on NASA projects are to be made available in electronic format in the original format. The electronic availability of the IV&V products and artifacts facilitates post-deliveries that might be necessary with software updates. Electronic access to IV&V artifacts and products reduces NASA's IV&V project costs and accommodates the longer-term needs when performing software maintenance. If the project manager does not address the issues and risks found by IV&V and track them to closure, these unaddressed risks and issues could cause the project to fail to meet its objectives (e.g. schedule, planned quality, functionality, etc.) Since IV&V personnel have generally worked across many projects, they are often likely to recognize risks and issues to the project that the project manager may not recognize. Performing verification and validation (V&V) to accredit software models, simulations, and analysis tools is important to ensure the credibility of the results produced by those tools. Critical decisions may be made, at least in part, based on the results produced by models, simulations, and analysis tools. Reducing the risk associated with these decisions is one reason to use accredited tools that have been properly verified and validated. See also A.02 Software Assurance and Software Safety. a. Category 1 projects as defined in NPR 7120.5.
See edit history of this section
Post feedback on this section
06.00. Software Testing Activity Overview
Software testing is required to ensure that the software meets the agreed requirements and design, works as expected, doesn’t contain serious bugs, and meets its intended use as per user expectations. IV&V may be used to expand test coverage and depth. 1.1 Sub-Activities in Testing
06.01. Software Testing Activity Overview
Frequency Of This Activity
06.01.1 Related SWEs
Testing
b. Software test procedure(s).
c. Software test(s), including any code specifically written to perform test procedures.
d. Software test report(s).Cybersecurity
06.01.2 Related Work Products
06.01.2.1 Related Process Asset Templates
06.01.3 Related Topics
06.01.4 Related SPAN Links
06.02. IV&V
Frequency Of This Activity
06.02.1 Related SWEs
b. Category 2 projects as defined in NPR 7120.5, that have Class A or Class B payload risk classification per NPR 8705.4, Risk Classification for NASA Payloads.
c. Projects selected explicitly by the Mission Directorate Associate Administrator (MDAA) to have software IV&V.06.02.2 Related Work Products
06.02.2.1 Related Process Asset Templates
06.02.3 Related Topics
06.02.4 Related SPAN Links