Software testing on different levels is done throughout the whole software development cycle. Testing level determines what is tested: a separate module, a group of modules or a system as a whole. Testing all system levels is a key to successful project delivery.
There’re four main software testing levels:
- Component testing or Unit testing;
- Integration testing;
- System testing;
- Acceptance testing.
Component or Unit testing
Component testing is an integral part of software testing services which checks functionality and finds out bugs and defects in app parts, which are available and can be tested separately (for example, program modules, objects, classes, etc.). Usually, component testing is done by checking the code with the help of different frameworks for component testing and debugging tools. All detected bugs are generally fixed in the code without them adding and describing in the bug tracking system. One of the most effective approaches to component testing is preparation of automation tests before the work on software coding begins. This is called test-driven development or test first approach. With this approach, small pieces of code are written and integrated, which then tested against pre-written tests. The development is done until all the tests are successfully passed.
The difference between component and unit testing
In essence, these two levels represent the same idea, with only difference being the fact that component testing uses real objects and drivers as function parameters, while component testing uses specific values.
Integration testing is intended for checking connection among components, and also interaction with different parts of the system (operating system, equipment or connection between different systems).
Integration testing levels:
- Component integration testing – interaction among the system components is checked after conducting component testing.
- System integration testing – interaction among different systems is checked after conducting system testing.
Integration testing approaches:
Bottom Up integration
All low-level modules, procedures and functions are gathered and then tested. After that, next level of modules is gathered for integration testing. Such approach is useful if all or almost all modules are ready. Also, this approach helps determine overall percentage of application completeness.
Top Down integration
First, all high-level modules are tested, and then low-level modules are added. All lower-level modules are simulated with the help of stubs that have the same functionality. Later, these stubs are replaced with real active components as soon as they’re ready. Thus, testing is done from top to bottom.
“Big bang” integration
All, or almost all ready components, are gathered together as a complete system or its main part, and then integration testing is done. Such approach saves you time. But if cases and their results are wrong, then integration process becomes really complicated, and it may hinder your testing team from achieving the main goal of integration testing.
The main goal of system testing is checking both functional and non-functional requirements to the system in general. At this level such bugs as wrong usage of system resources, unforeseen data combinations on the user level, environmental incompatibility, unforeseen use case scenarios, absent or wrong functionality, etc., are detected. In order to minimize the risks which are connected with system behavior in this or that environment, it’s recommended to use the environment which is close to that that will be installed after the project is released.
Generally, two approaches to system testing are marked out:
Requirements based – for each requirement test cases are written, which check the fulfilment of this requirement.
Use case based – use cases are created on the basis of future app/software usage. One use case can be determined by one or more scenarios. To check each scenario, test cases are written which after that are tested.
It’s a formal testing process which checks system’s correspondence to requirements and is done with the purpose to:
- Determine if the system meets acceptance criteria;
- Decide by a customer if the project is done.
Acceptance testing is done on the basis of a set of typical test cases and scenarios, which has been developed with the requirements to the project. The decision on doing acceptance testing is made when:
- A product is of proper quality;
- A customer knows product acceptance plan, where the actions connected to acceptance testing are described.
The duration of acceptance testing depends on the customer. When he decides that software meets his requirements, then the software is released.