Testing Type	Description	Benefits	Testing Phase
Ad hoc	Informal software testing that is outside a formal test plan. It can be used for the purpose of learning the system. A common use is for functional subject matter experts to “beat” on the system with odd scenarios that may hit in the real world (such as user errors and exceptional conditions) with the intent to try to “break the system.”	Ad hoc testing is a useful training tool for learning how to use the system. It also is a great tool for uncovering bugs or system problems with random input that is outside the normal path. Most testing staff do ad hoc testing as they think of new scenarios or possibilities during the formal testing process.	All phases of testing code
Black box	Testing based on business requirements and functionality without regard to internal design or code.	Same as functional testing. Focuses on WHAT the system must do. Test cases are written from business requirements before system is created, so testing verifies whether code accomplishes function described in requirements.	System User Acceptance
Boundary	Testing to determine if the system handles values that are outside set boundaries, for example: - Maximum negative, maximum positive, and “0” inputs or outputs; - Input or output strings at size limits or one character beyond size limits; - Empty input files and files with only one character in them.	History shows that bugs sometimes are concentrated around the boundary values. Focusing on the boundaries can uncover problems quickly and reduce testing time by attacking the high risk areas first.	All phases of testing code
Capacity	Testing to determine capacity of hardware, servers	Assists system owners to reduce costs by planning for future reductions or expansions on the front end.	Integration System User Acceptance
Dynamic	Testing involving execution of code	Verifies whether code performs as intended.	All phases of testing code
End-to-end	Testing a complete application environment from beginning to end with all programming, interfaces, network communications, hardware and applications operating to mimic a real world environment.	Testing is closest to real world conditions and may uncover problems that would not be discovered otherwise.	System User Acceptance
Functional	Black box type testing based on business requirements and functionality, without regard to internal design or code.	See black box testing	Integration System User Acceptance
Load	Testing the system by feeding it large tasks, such as: executing code that would cause generation of a large volume of forms; feeding an unusually large document to a word processor; sending empty tasks through (i.e. a report creation when no data can be found to populate it); executing a search that would require the system to read a high number of records.	See Performance	Integration System User Acceptance
Performance	Testing to eliminate bottlenecks and establish a baseline for future regression testing, such as testing for acceptable response times and ability to handle concurrent users.	Prevents system performance problems that, under normal testing conditions, would not be discovered until after implementation. Risk is far less if problem is discovered before implementation.	Integration System User Acceptance
Recovery or Failover	Testing how well the system recovers from crashes, hardware failures or other catastrophic events.	Prevents major real world losses if problems are corrected prior to implementation.	Integration System User Acceptance
Regression	Retesting the system after programming modifications to ensure that no new “bugs” have been introduced.	Helps ensure that new code versions have not introduced new bugs.	All phases of testing code
Sanity or Smoke	Initial testing to determine whether a new software version is performing well enough to accept for a major testing effort.	Prevents losses caused by wasting resources on doomed testing efforts.	Prior to System or User Acceptance
Scalability	Testing whether the application can be scaled easily for increases or reductions in workload.	Scalability usually is a major factor in choosing application options. Ensuring that your system can grow or decrease with the business will enable a long term cost benefit.	Integration System User Acceptance
Security	Testing how well the system protects against unauthorized internal or external access and attempts made to compromise data, software or hardware.	Particularly in government programs, systems store very personal confidential data and issue monetary benefits. Security breaches could be catastrophic.	All phases of testing code
Static	Walkthroughs and Inspections: Manual examination of project documentation such as requirements, use cases, design documents, program specifications, dataflow diagrams, architectural diagrams, etc. Most effective if completed by independent reviewer who was not involved in creation of deliverable.	Discovers gaps and errors in requirements before coding begins. Reduces costs of rework if found early in the process. Cost effective testing	As documents are created – prior to coding
Stress	Testing to check system performance in response to a failure – does it fail and recover gracefully? Test conditions could include: doubling the baseline number for concurrent users/HTTP connections; randomly shutting down and restarting ports on the network switches/routers that connect the servers; taking the database offline, then restarting it.	See Performance	Integration System User Acceptance
Usability	Testing to determine if the system is user friendly and easy to navigate. Should be completed by functional staff.	If performed by true system users (customer), it may identify problems that would appear insignificant to a developer but would have significant negative impact for users.	Integration System User Acceptance
White box	Testing based on knowledge of the internal logic of the application code. Also called structural testing or glass box testing.	Focuses on HOW the system performs its functions. Test cases are created after system is created. Helpful in identifying errors that were introduced by the current version. Ensures that technology selected to implement requirement is correct.	Unit Integration