There are several types of testing in a comprehensive software test process, many of which occur simultaneously.
- Unit Testing
- Integration Testing
- System Testing
- Performance / Stress Test
- Regression Test
- Quality Assurance Test
- User Acceptance Test and Installation Test
Testing each module individually is called Unit Testing. This follows a White-Box testing. In some organizations, a peer review panel performs the design and/or code inspections. Unit or component tests usually involve some combination of structural and functional tests by programmers in their own systems. Component tests often require building some kind of supporting framework that allows components to execute.
The individual components are combined with other components to make sure that necessary communications, links and data sharing occur properly. It is not truly system testing because the components are not implemented in the operating environment. The integration phase requires more planning and some reasonable sub-set of production-type data. Larger systems often require several integration steps.
There are three basic integration test methods:
The all-at-once method provides a useful solution for simple integration problems, involving a small program possibly using a few previously tested modules.
Bottom-up testing: involves individual testing of each module using a driver routine that calls the module and provides it with needed resources. Bottom-up testing often works well in less structured shops because there is less dependency on availability of other resources to accomplish the test. It is a more intuitive approach to testing that also usually finds errors in critical routines earlier than the top-down method. However, in a new system many modules must be integrated to produce system-level behavior, thus interface errors surface late in the process.
Top-down testing: fits a prototyping environment that establishes an initial skeleton that fills individual modules that is completed. The method lends itself to more structured organizations that plan out the entire test process. Although interface errors are found earlier, errors in critical low-level modules can be found later than you would like.
The system test phase begins once modules are integrated enough to perform tests in a whole system environment. System testing can occur in parallel with integration test, especially with the top-down method.
An important phase of the system testing, often-called load or volume or performance test, stress tests tries to determine the failure point of a system under extreme pressure. Stress tests are most useful when systems are being scaled up to larger environments or being implemented for the first time. Web sites, like any other large-scale system that requires multiple accesses and processing, contain vulnerable nodes that should be tested before deployment. Unfortunately, most stress testing can only simulate loads on various points of the system and cannot truly stress the entire network, as the users would experience it. Fortunately, once stress and load factors have been successfully overcome, it is only necessary to stress test again if major changes take place.
A drawback of performance testing is it confirms the system can handle heavy loads, but cannot so easily determine if the system is producing the correct information.
Regression tests confirm that implementation of changes have not adversely affected other functions. Regression testing is a type of test as opposed to a phase in testing. Regression tests apply at all phases whenever a change is made.
Quality Assurance Testing
Some organizations maintain a Quality Group that provides a different point of view, uses a different set of tests, and applies the tests in a different, more complete test environment. The group might look to see that organization standards have been followed in the specification, coding and documentation of the software. They might check to see that the original requirement is documented, verify that the software properly implements the required functions, and see that everything is ready for the users to take a crack at it.
Traditionally, this is where the users ‘get their first crack’ at the software. Unfortunately, by this time, it's usually too late. If the users have not seen prototypes, been involved with the design, and understood the evolution of the system, they are inevitably going to be unhappy with the result. If one can perform every test as user acceptance tests, there is much better chance of a successful project.