reuse
[email protected]
1. Review changes made on all FPDOCS SCRs, identifying all requirements that
have changed.
2. Review changes made on all FPCODE SCRs, identifying all code elements that
have changed.
3. Compare the list of changed requirements from step 1 with a complete list
of requirements. Requirements that were not changed were reused.
4. Compare the list of changed code elements from step 2 with a complete list
of code elements. Code elements that were not changed were reused.
5. Using the trace matrix, identify tests for all of the reused requirements
identified in step 3.
6. If a requirement and its corresponding code element are both reused, the
tests identified in step 5 can be reused. The test includes the tdf, support
files, and results. If a test is reused, a reuse inspection must be performed.
None of the test files (tdf, support files or results) will be inserted into
the new ACM configuration. The only element relating to the test in the new ACM
configuration will be the inspection (.ins) file. The inspection file contains
a list of all test files being reused and their generation numbers in ACM.
7. If a requirement is reused, but the corresponding code element has been
changed, the test may only need to be rerun, generating a new set of results.
In this case the tdf and support files from a previous certification effort
are reused and must go through a reuse inspection. The tdf and support files
will be inserted into the new ACM configuration. When the new results are
generated, they will also be inserted into the ACM configuration.
8. If the reused tests identified in step 6 (or rerun tests identified in step
7) can be identified at the time of creation of the initial development SCR, a
split needs to be created for reuse. All reusable and rerunable tests must be
identified and the reuse inspection completed before starting run for score.
9. If a test has to be rerun only to obtain structural coverage information,
the tdf and supporting files will not be inserted into the new ACM
configuration. The test will be rerun and only the xinfo and pth files are kept
to perform structural coverage analysis. Other results will not be inserted
into the new ACM configuration.
Software Test Inspection Checklist for Reuse
1. Test Analysis
A. Is each test case in the software test applicable and necessary to the
new application?
B. Is the software test, as written, compatible with the new application's
exeuction environment? (i.e., Does the new application have identical
operational characteristics such as inputs, data ranges, update rates,
and partition assignments?)
C. Does the software test contain any test inputs unused in the new
application? Will the behavior be predictable and acceptable if they
are not used?
D. Are any changes required to make the original software test function
in the new application? (This type of change will require a more
extensive inspection depending on the scope of changes.)
E. Are generations of code elements being tested the same for both
configurations (the baseline configuration and the new configuration)?
F. Are generation of DSS elements containing the requirements anchors being
test the same for both configurations (the baseline configuration and
the new configuration)?
2. Convention Compliance
A. Does the software test filename comply with naming conventions?
B. Do anchor names comply with anchor naming conventions?
3. Traceability and Configuration Management
A. Has traceability to the requirements been verified?
B. Has traceability to the design information (SDD) been verified (if
applicable)?
C. Is the reused element in the correct ACM configuation?
D. Does the inspection file contain the correct generation of the element
being reused?
back
