NVP Software Testing

 

 

Types of Testing

Development-Level Testing

Unit Testing: The testing of each individual module that comprises the system. Testing checks only the module in question and is based on knowledge of the coding included in the module. Inputs will be in the form expected by the module and outputs will be accepted in the form produced by the module.

bullet

Risk if not completed – Defects made at the unit level may not be caught until much later in the testing cycle, leading to delays and extra costs.

Initial Testing

Configuration Testing: Checks the operation of the program under various software and hardware configurations that might exist or be implemented at customer sites.

bullet

Risk if not completed – A prospective client may be unable to run the provided system correctly at their site.

Compatibility / Conversion Testing: Confirms that the program is compatible with any co-resident programs and that the data output by the program is in the correct format to be used as input for a succeeding program or programs. Conversion testing confirms that any required or expected data conversions occur without loss of data or information.

bullet

Risk if not completed – The output from the program may not be in a format acceptable to a program with which it is required to interface. Data may not be converted properly from one release to the next.

Installability Testing: Confirms that the program can be installed in the expected environment without problems and without affecting any other programs or data on the machine.

bullet

Risk if not completed – After all other testing is completed, the system cannot be installed in the final environments.

Ongoing Testing

Functionality Testing: Confirms that the functions listed in the specifications operate properly in the software, in all identified environments.
 
bullet

Risk if not completed – The system may not operate as required.

Facility Testing: Confirms that all the documented facilities are implemented in the system to be shipped. Facilities include items that are not direct functionality but are included in the product.

bullet

Risk if not completed – The system may not contain all the facilities expected.

Security Testing: Confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.
 
bullet

Risk if not completed – Personnel without sufficient security clearance may be able to execute inappropriate functions and processes.

Performance Testing

Volume Testing: Confirms that any values that may become large over time (such as accumulated counts, logs, and data files) can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.
 
bullet

Risk if not completed – It may not be possible to operate the complete system with all data in place if the volume of expected records is not checked during testing and verified to work correctly and completely.

Stress Testing: Confirms that the program continues to operate when subjected to stress (that is, during a short, sharp, peak of intensive activity).
 
bullet

Risk if not completed – Users may find the system response becomes non-existent or unacceptably slow under some conditions if the system is not confirmed to operate properly under conditions of stress.

Load Testing: Confirms that the program operates without memory loss or degradation of performance for several days without being shut down.
 
bullet

Risk if not completed – When the system is placed under load to complete a number of transactions in a short time, it may not respond appropriately.

Performance Testing: Checks the program’s speed. It checks both speed of response to the user and speed of execution of any underlying batch programs, under conditions of both normal and stress usage.
 
bullet

Risk if not completed – System performance may be too slow to meet your requirements, and may impede your users from successful completion of functions.

Storage Testing: Checks that the program stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space.

Note: This is external storage as opposed to internal storage.

bullet

Risk if not completed – The system may not be able to store the expected volume of records, and this may cause unexpected and unknown errors.

Post-Functional Testing

Usability Testing: Confirms that the program conforms to requirements standards and that the interface is accessed and manipulated in a user-friendly fashion.
 
bullet

Risk if not completed – Screens and functions may be modified through the requirements and development cycle and lose the usability originally built in.

Reliability Testing: Confirms that the program operates and provides accurate and consistent results under normal usage.
 
bullet

Risk if not completed – The system may provide anomalous results under different conditions. Results will not be the same and cannot be trusted.

Recovery Testing: Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
 
bullet

Risk if not completed – The system may lose data in unexpected and unknown ways if recovery from unexpected errors is not checked.

Post-Installation Testing

Serviceability: Confirms the ability of trained personnel to service the program and make required changes without affecting the ongoing use of the program or any existing data. An example of servicing a program might occur when there has been an unexpected crash and development is required to recover data. Serviceability testing confirms the ability to implement that recovery.
 
bullet

Risk if not completed – It may not be possible to implement changes and fixes to the system as required if the system is not checked and confirmed to be serviceable.

Completion Testing

Documentation: Reviews all pieces of documentation for consistency, adherence to standards, and accuracy.
 
bullet

Risk if not completed – Documentation may not reflect the requirements of the user and the nature of the system.

Procedure: Confirms that all documented procedures are accurate and can be implemented as they are written.
 
bullet

Risk if not completed – Provided procedures might not operate as expected or as documented unless tested on the final system prior to implementation.

© 2006, NVP Software Testing Inc.