Software Testing Levels

Software testing has several levels. It also has two broad categories: functional testing and non-functional testing. We explore those categories in detail in the next chapter.

Overview of Software Testing Levels

The four testing levels are:

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing

Open Full-Size Diagram ↗

Overview of Software Testing Levels

Unit Testing

A unit is the smallest independent, testable part of the source code. Unit testing is the first testing level and is generally performed by developers or their teammates, rather than software testers. Complete unit testing before integrating the units. A well-defined unit test plan and test cases are essential.

Unit testing gives you confidence to proceed with integration once the individual units work correctly. Testing alongside development may initially feel slow: defects are discovered and code changes are needed. Over time, the code improves and defects decrease. This creates a stronger foundation and helps later development move faster, saving time.

Open Full-Size Diagram ↗

Unit Testing

Effective unit testing also saves money. Defects generally cost much more to fix late in development than during its early stages.

Unit tests cover a small component, so their test cases and data cannot check every functional or information-flow scenario across the application. Some scenarios can be tested only after units have been combined into a larger component.

Integration Testing

After unit testing, integration testing checks how two or more units interact and what output they produce in different scenarios. A software test engineer carries out this testing.

Integration testing reveals functional, requirements-related and performance defects. Unit testing checks that components work individually; integration testing checks that they work as expected together. The main approaches are:

1. Big bang
2. Top-down integration
3. Bottom-up integration

In big bang integration testing, all modules are combined into the complete system and then tested for defects.

Open Full-Size Diagram ↗

Integration Testing

Top-down integration starts with the highest-level modules, then adds and tests lower-level modules one at a time. Bottom-up integration reverses that sequence: test the lowest-level modules first, then add higher-level modules progressively. A common sequence is to begin with bottom-up testing and follow it with top-down testing.

Open Full-Size Diagram ↗

Top down and Bottom up Integration Testing

In top-down testing, stubs stand in for unavailable or unfinished lower-level modules or subprograms. In bottom-up testing, a driver acts as the calling program when the required higher-level program is not yet available.

System Testing

After integration succeeds, system testing examines the complete system with its components working together. It checks performance, functional and technical specifications, and the organization’s quality standards. A highly skilled testing team should carry out this work in an environment that closely resembles the system’s real deployment setting.

Open Full-Size Diagram ↗

System Testing

System testing is purely black box testing. It checks the system against requirements from the user’s perspective, including application behavior, design and end-user expectations. It verifies and validates both the application architecture and the client’s business requirements.

Acceptance Testing

After unit, integration and system testing, acceptance testing examines quality and accuracy using predefined scenarios and test cases. The quality assurance team reviews the system from several perspectives, including appearance and internal operation. This stage is crucial because client acceptance also depends on legal and contractual requirements. Acceptance testing includes:

1. User acceptance testing: Actual users test the software before accepting it, either at their own site or at the organization that developed it.
2. Operational acceptance testing: Check that the processes and procedures needed to use and maintain the system are in place.
3. Contract and regulatory acceptance testing: Check compliance with contractual requirements and applicable government, legal and safety standards.
4. Alpha testing: Check overall product quality and prepare for beta testing near the end of development, when the whole system can be tested. Test engineers and other team members examine quality and engineering from the customer’s perspective. This can take considerable time.
5. Beta testing: After alpha testing, actual users try the product in real-world conditions to improve quality and check that it meets their requirements. It takes place a few days or weeks before launch and may last a few days. It may be shorter than alpha testing because the chance of finding defects is relatively low at this stage.

Open Full-Size Diagram ↗

Acceptance Testing