Appendix E Simplified Unit Test Plan

"KISS - Keep It Simple, Sir!"

— Anonymous

Simplified Unit Test Plan

This unit test plan template was created by our colleague Dale Perry in order to clarify and simplify the tasks needed to perform unit testing.

Created By: Dale Perry

Version 2.1

Identification

Version/release information and configuration identification.

References

Any supporting documentation including:

  • Requirements specifications
  • Design specifications
  • Other documents/diagrams

Module Component Unit

Owner

Identification

Type

New

Modified

         
         
         
         
  • Owner of the module/component
  • Module identification (e.g., name, etc.)
  • Type of module (e.g., C program, DLL, etc.)
  • Is this a new module or a modified existing module?

Functions Features (Attributes, Sub Functions)

Function

Sub-Function/Attribute

Test Aspect/Risk

New

Modified

         
         
         
         
  • Identify all modified functions/features and the attributes of those features.
  • Test Aspect/Risk:

    • Why does this need to be tested and what is the risk associated with the feature or function?

      • Business Risk

        • Risk to business if feature does not function correctly or causes faults
      • Technical Risk

        • Complexity, technology or other software concerns
  • Is this a new function or a modification to an existing function?
  • Add as many entries as required.

Shared Elements

Element

Sharing Element

Type

Risk

New

Modified

           
           
           
           
  • Identify any shared constructs and what they are shared with (e.g., constructs, transactions, messages, objects, classes). This will help focus regression test efforts.
  • What are the risks to the shared elements?
  • Is the shared element new or being modified?
  • Add as many entries as required.

Interfaces Communications

Interface

Type

Risk

New

Modified

         
         
         
         
  • Identify all interfaces and the type of interface:

    • Communication
    • Database
    • Transaction
    • Network
    • Other
  • What are the risks to the shared interfaces?
  • Is the interface new or being modified?
  • Add as many entries as required.

Non Modified or Other Functions and Attributes

Function

Sub-Function/Attribute

Risk

     
     
     
     
  • Identify all other functions/features and their sub-functions and attributes that are part of the modified component. This does not apply to new features or functions unless they are added to an existing module or to other existing features/functions.
  • What are the risks to those non-modified elements?
  • This will also help identify elements that require regression testing.

External Updates

Element

Type/Category

Version

     
     
     
     

Identify any external elements that were updated or modified to support the change:

  • These can include DLLs, object classes, shared libraries, vendor packages, etc.
  • This will allow identification of those elements that vary from those in the final production environment, and may indicate where a more advanced version was used during development than will be used in production.

Approach

  • How will unit testing be accomplished?

    • Debugged
    • Coverage tool
    • Other tool
  • How will proof of test be provided to show unit test was completed?

    • Trace reports
    • Coverage reports
    • Debug printouts
    • Other

Pass Fail Criteria

How will test results be evaluated prior to build/integration testing?





Systematic Software Testing
Systematic Software Testing (Artech House Computer Library)
ISBN: 1580535089
EAN: 2147483647
Year: 2002
Pages: 114
Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net