bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin


Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned


Div
idtabs-1

1. Requirements

3.3.4 The project shall ensure that the software code is unit tested per the plans for software testing.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Classes F and G are labeled with "X (not OTS)." This means that this requirement does not apply to off-the-shelf software for these classes.

Class D Not Safety Critical is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.


applicable
f*
g*
h0
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc1
dnscp
dsc1
ensc0



Div
idtabs-2

2. Rationale

Unit testing is the process for testing the range of inputs to a unit to ensure that only the intended outputs are produced. By doing this at the lowest level, fewer issues will be discovered when the components are later integrated and tested as a whole. Therefore, during unit testing, it is important to check the maximum and minimum values, invalid values, empty and corrupt data, etc. for each input and output to ensure the unit properly handles the data (processes or rejects it).


Panel

Unit testing can be described as the confirmation that the unit performs the capability assigned to it, correctly interfaces with other units and data, and represents a faithful implementation of the unit design

sweref
081
081


Ensuring that developers perform unit testing in accordance with written test plans helps build quality into the software from the beginning and allows bugs to be corrected early in the project life cycle when such corrections cost the least to the project.


Div
idtabs-3

3. Guidance

Per IEEE STD 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, a "unit" is defined as:
 
(1) A separately testable element specified in the design of a computer software component. 
(2) A logically separable part of a computer program.
(3) A software component that is not subdivided into other components.
 
Given the low-level nature of a unit of code, the person most able to fully test that unit is the developer who created it.  

Projects ensure that the appropriate test environment, test materials, and personnel training (SWE-017), are in place and then conduct unit tests per the approved plans (SWE-104), according to the schedule (SWE-016), and with proper monitoring per the software assurance plan, making sure that:

  • Criteria for a successful test are established prior to the test.
  • Test environment represents inputs, output, and stimulus the unit will experience in operation.
  • Capture weaknesses or differences between unit test environment and actual target environment.
  • In accordance with the approved plans for unit testing:
    • Unit test results are captured.
    • Issues are identified and documented (some minor issues, such as typos, as defined by the project, may simply be corrected without documentation).
    • Unit test issues are corrected; these may include:
      • Issues found in the code.
      • Issues found in test instruments (e.g., scripts, data, procedures).
      • Issues found in testing tools (e.g., setup, configuration).
    • Unit test corrections are captured (for root cause analysis, as well as proof that the unit test plans were followed).
  • Unit test results are evaluated by someone other than the tester to confirm the results, as applicable and practical; evaluation results captured.
  • Unit test data, scripts, test cases, procedures, test drivers, test stubs are captured for reference and any required regression testing.
  • Notes captured in software engineering notebooks or other documents are captured for reference.
  • Objective evidence that unit tests were completed and unit test objectives met is captured in the Software Development Folders (SDFs) or other appropriate project location as called out in the project documentation (e.g., Software Development Plan (SDP) / Software Management Plan (SMP) , Configuration Management Plan(CMP)).
    sweref
    013
    013
  • Unit test metrics captured, as appropriate and defined for the project.

Per NASA-STD-8719.13, NASA Software Safety Standard; and NASA-GB-8719.13, NASA Software Safety Guidebook, software assurance is to "Verify unit testing and data verification is completed before the unit is integrated."

sweref
271
271
Either software assurance or Independent Verification and Validation (IV&V) personnel "Verify unit tests adequately test the software and are actually performed."
sweref
276
276
When less formal confirmation of unit testing is needed, a software team lead or other designated project member may verify completeness and correctness of the testing by comparing the results to the test plan to ensure that all logic paths have been tested and verifying the test results are accurate.
sweref
047
047

Unit testing tools and some integrated development environments (IDEs) can auto-generate unit tests based on the code. These tools provide a quick method to generate unit tests, but may not completely exercise the unit of code. Rerun units tests each time the unit is updated to ensure the code continues to work as expected. When continuous integration is part of the life cycle, all of the unit tests are rerun each time the code is updated to ensure only working code is integrated.

Documented test results, results evaluations, issues, problem reports, corrections, and tester notes can all serve as evidence that unit tests were completed. Comparing those documents to the software test plans for unit testing can ensure the tests were completed in accordance with those documented procedures.

Make sure evidence of all test passes is captured.

NASA-GB-8719.13, NASA Software Safety Guidebook,

sweref
276
276
further states in the section on safety-critical unit test plans that "documentation is required to prove adequate safety testing of the software." Therefore, unit test results can play an important role in supporting reviews of safety-critical software.


Note

Consult Center PALs for Center-specific guidance and resources related to unit testing.


Additional guidance related to unit testing may be found in the following related requirements in this handbook:


SWE-066

Perform Testing

SWE-067

Verify Implementation

SWE-069

Document Defects and Track

SWE-104

Software Test Plan

SWE-118

Software Test Report




Div
idtabs-4

4. Small Projects

Projects with limited budgets and personnel may choose to perform unit testing or capture unit test results and artifacts in a less formal manner than projects with greater resources. Regardless of the formality of the procedures used, the software test plans for unit testing need to describe the test environment/setup, results capture, simple documentation procedures, and compliance checks against the procedures. Some Centers have tailored lean unit test procedures and support tools specifically for small projects.


Div
idtabs-5

5. Resources


refstable

toolstable


Div
idtabs-6

6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to unit testing:

  • MPL Uplink Loss Timer Software/Test Errors (1998) (Plan to test against full range of parameters.) Lesson Number 0939:  Lesson Learned No. 2 states: "Unit and integration testing should, at a minimum, test against the full operational range of parameters. When changes are made to database parameters that affect logic decisions, the logic should be re-tested."
    sweref
    530
    530
  • Computer Software/Configuration Control/Verification and Validation (V&V) (Unit level V&V needed for auto-code and auto-code generators.) Lesson Number 1023:  "The use of the Matrix X autocode generator for ISS software can lead to serious problems if the generated code and Matrix X itself are not subjected to effective configuration control or the products are not subjected to unit-level V&V. These problems can be exacerbated if the code generated by Matrix X is modified by hand."
    sweref
    533
    533