Downloaded from https://www.everyspec.com ADS-79D-HDBK value should be specified in the test procedure along with any necessary tolerances (+/- values) to establish the PASS/FAIL criteria for each test. The test procedures also document the environment necessary in which to conduct the test; any prerequisites for the test; the pre- and post-test procedures required to perform the test; and any unique conditions, data, or environmental considerations required for the test. Just as an integration phase is usually necessary to complete the software design phase, a ‗dry-run‘ phase is usually necessary to complete and confirm the development of test procedures.
Since test procedures are very detailed instructions on how to execute and manipulate the software under test, it is usually necessary to execute these procedures informally a few times in order to evaluate the procedure and make any necessary adjustments and clarifications prior to release and formal test execution. K.6.1.2.1 Ground Station Automated Verification. When allowed by certificating authorities, automated tools to assist with the verification of the software under test are encouraged. Automated verification enables the developers to concentrate on desired changes rather than running test suites repeatedly.
By automating the verification of the system, it can be tested more extensively and faster than via manual methods. Guidance for verification tools can be found in Section 12 of RTCA DO-178B. K.6.1.2.2 Ground Station Regression Testing. As a part of verifying new functionality, any change to the system should also be considered a candidate for regression testing to ensure that functionality not intended for modification at a given change has indeed not changed. This is even more important for systems whose behavior depends on the aircraft model or other external indications. For more information on modifications to previously developed software reference RTCA DO-178B, section 12.1.1.
K.6.1.3 Ground Station Software Verification Results. The output of the verification process is captured in the Software Verification Results (also known as a Software Verification Report (SVR) or Software Test Report). The SVR documents the entire test environment, the unit under test (UUT) and its configuration, and the results of the execution of the software test procedures. If any failures occur during test, the information regarding those failures is captured, and documentation of the failure is captured (for example the creation of a Software Problem Report or equivalent defect tracking system input).
The SVR provides a single source for determination of whether the unit under test meets its requirements or is deficient in any way. The airworthiness authority uses this document to either accept or reject the product based on the results of verification activities performed. K.6.2 Ground Station Validation Process.
As stated earlier, validation answers the question ―Does the system do what it is supposed to do?‖ It occurs sequentially following verification (which is assumed to already have proven that the system functions as it was specified to work) and is vital to the fielding of a completed system because it focuses on end- user functionality in the designed target environment, rather than on simulated environments and test cases. As such, validation is typically performed by the end-user or customer representative, on actual or representative hardware running in the end-user‘s normal hardware environment. 222