During the development life cycle of a software product, testing is performed at different levels and can involve the whole system or parts of it. Depending on the process model adopted, then, software testing activities can be articulated in different phases, each one addressing specific needs relative to different portions of a system. The system is tested in steps, in line with the planned build and release strategies, from individual units of code through integrated subsystems to the deployed releases and to the final system. Testing proceeds through various physical levels of the application development life cycle. Each completed level represents a milestone on the project plan and each stage represents a known level of physical integration and quality. These stages of integration are known as test levels. Here the level of test is defined by a given environment where environment is a collection of people, hardware, software, interfaces, data, etc.
The following are the different test levels in software testing:
1. Unit Testing.
2. Integration Testing.
3. System Testing.
4. Regression testing.
5. User Acceptance Testing.
6. Pilot/Field Testing.
7. Installation or Production Testing.
1. Unit Testing:
A unit is the smallest testable piece of software, which may consist of hundreds or even just a few lines of source code, and generally represents the result of the work of one programmer. The unit testing purpose is to ensure that the unit satisfies its functional specification and/or that its implemented structure matches the intended design structure. In this phase of testing, separate units of software system are tested. This is also known as component testing in which each module is tested alone to find any error in its source code. Programmer performs this testing as part of the development life cycle.
2. Integration Testing:
The integration testing is done to test the communication between different components of the software; all the modules that a program comprises are being brought together to test whether they are functioning in correct order with their counter part. The decomposition based integration testing is based on the functional decomposition of the system. In this testing, there are four approaches are available:
1. Top-down Approach:
The top-down approach to integration testing requires the highest-level modules to be tested and integrated first. Thus, this allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.
A driver is an application which drives the functionality of a module (unit). A collection of drivers is called a Stub.
2. Bottom-up Approach:
Bottom-up integration testing begins construction and testing with components at the lowest levels in the program structure. The process is repeated until the component at the top of the hierarchy is tested. Bottom up testing requires test drivers, but does not require test stubs.
3. Mixed Approach:
A mixed (also called sandwiched) integration testing follows a combination of top-down and bottom-up testing approaches. Bottom-up testing starts only after the bottom level modules are ready. The mixed approach overcomes this shortcoming of the top-down and bottom-up approaches. In the mixed testing approaches, testing can tart as and when modules become available. Therefore, this is one of the most commonly used integration testing approaches.
d. Big bang Approach:
Simplest approach to Integration Testing, where all
modules are simply put together and tested.
For some projects integration testing can further be divided into two levels:
1. Assembly Integration Testing.2. System Integration Testing.
During assembly testing, the integration of the software components is tested. During system integration testing, the communication with external systems is tested. Integration Test Plan should be written from High Level design document.
3. System Testing:
System testing verifies the complete, integrated system in order to check whether the system meets its functional and non-functional objectives and requirements.
The Functional Testing at system level verifies interoperability testing of interfacing with all external components along with end-to-end business workflows and Interoperability.
Non-functionality testing in System Testing includes Usability Testing, Reliability Testing, Efficiency Testing, Portability Testing, and Maintainability Testing. In these non-functional tests, performance testing is one type of testing.
Performance Testing verifies the system to know the extent to which it meets the performance requirements like load, volume, stress and also, worst case scenarios.
4. Regression Testing:
Retesting of a unit, a combination of components or a whole system after modification, in order to ascertain that the change has not introduced new faults is called Regression Testing. Regression testing may be performed at the end of each test level after reported bugs are fixed or as a separate test level prior to Acceptance Testing or whenever changes are made to the system to address post-release complaints of client and user. It is an on going process throughout testing lifecycle.
5. User Acceptance Testing:
User acceptance testing is also called as beta testing, application testing, and/or end user testing – is a phase of software development in which the software is tested in the “real world” by the intended audience or a business representative. Usually the users are responsible for executing the tests. This may also involve verification of help desk functions, backup and recovery, business processes, user training material evaluations, etc.
6. Pilot/Field Testing:
Pilot/Field Testing verifies the system and business processes in the deployment like environment under typical business conditions. This may also involve verification of help desk functions and manual procedures.
7. Installation and Production Testing:
This installation or production testing verifies whether the installed system performs as expected in the user’s environment if acceptance or pilot testing was not performed at the user location. This is the final check-out of the system prior to retiring the existing system (if one exists), and/or turning responsibility for the system over to the user organization, or to the Maintenance and Operations (M&O) staff. The system is used for processing actual business using “live” data and the new/modified business processes.
Important Factors on Testing Levels:
1. Factors influencing test scope are size of project, complexity of project, budget for project, time scope for project, and number of staff.
2. Why we have to test at different levels means software development naturally split in to phases, easily track bugs, and ensures a working subsystem/component/library.