| » Quality Assurance | » Software Testing | » Process Improvement |
| » Risk Analysis | » Software Usability | » Software Development |
Software Testing - Test Levels
Unit testing
Starting from the bottom the first test level is the Unit Testing, sometimes called Component Testing. It involves checking that each feature specified in the Component Design has been implemented in the unit.
The problem with a unit or component is that it performs only a small part of the functionality of a system, and it relies on co-operating with other parts, which may not have been built yet. To overcome this, the tester uses special software to trick the component into believing it is working in a fully functional system.
The Unit Tests can be performed on the units and modules while the programmer is coding them. Units and modules committed to the code repository are not allowed to have any known bugs.
Integration testing
In Integration Testing the separate modules will be tested together to find weaknesses and bugs in the system. It is a fact that two components that have passed all Unit Tests, when connected to each other produce one new component with potential faults. Integration Testing is not focussed on what the components are doing but on how they communicate with each other as specified in the System Design. The System Design defines relationships between components, and this involves stating:
- What a component can expect from another component in terms of services.
- How these services will be asked for.
- How they will be given.
- How to handle non-standard conditions, i.e. errors.
Integration Testing also includes partial performance testing of the system, including parsing performance, memory consumption and CPU usage. This way any bottlenecks in the system can be identified and the affected modules reworked. The produced metrics contain the results of the integration test, for example failed method calls or parsing times. The tests are organised to check all the interfaces, until all the components have been built and interfaced to each other producing the whole system.
System testing
System Testing compares the system specifications against the actual system. Test cases are derived from the systems use cases, and the functionality of the system is tested based on these tests. In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In effect it is one giant unit. System tests produce metrics that describe the stage of the project. Metrics are the fail/pass relation for the test cases. System Testing can involve a number of specialists to see if all the functional and non-functional requirements have been met. In addition to functional requirements System Testing usually includes the following types of testing:
- Performance - Are the performance criteria met?
- Volume - Can large volumes of information be handled?
- Stress - Can peak volumes of information be handled?
- Documentation - Is the documentation usable for the system?
- Robustness - Does the system remain stable under adverse circumstances?
Acceptance testing
The goal of Acceptance Testing is to verify that the user requirements have been achieved. The customer performs Acceptance Testing in the evaluation phase of the project, but also participates in acceptance testing at intermediate stages. It is similar to System Testing in that the whole system is checked but the important difference is the change in focus:
- System Testing checks that the system that was specified has been delivered.
- Acceptance Testing checks that the system delivers what was requested.
Release Testing
Even if a system meets all its requirements, there is still a case to be answered for the benefit of the business. The linking of Business Case to Release Testing is looser than the others, but is still important.
Release Testing is about seeing if the new or changed system will work in the existing business environment. Mainly this means the technical environment, and checks concerns such as:
- Does the new system affect (or serves as a component of) any other systems?
- Does it have acceptable performance under load in current hardware setup?
- How will the end user be impacted? (hardware needs, software needs, documentation, learning curve)
Regression Testing
In today's software architecture one system may become the component of another. It follows that all the above types of testing could be repeated at many levels in order to deliver the final value to the business. In fact, Regression Testing occurs every time a system is altered.