Testing Life Cycle – Part 1

Testing should be considered as equal the development process. Each step during an engineers programming activity has a corresponding testing activity. While each logical module adds to the growth of the software, these parts and integrations must be tested in different ways, following different approaches. The first part of the “Testing Life Cycle” series covers component and integration tests.

Component test

A component test generally tests each software module against its specification. This happens isolated form other modules to prevent external influences. It should not be mixed up with debugging as it’s not about eliminating bugs but about a structured way of identifying errors.

Component tests follow several goals:

• Test for functionality: Ensures, that the module fulfills the specifications functional requirements. A modules functionality is defined by its input and output parameters.
• Test for robustness: So called negative tests, which care about an appropriate exception handling. Therefore, the component is triggered with special cases and irregular input parameters.
• Test for efficiency: Efficiency of a component is defined by its use of ressources like memory or computing time.
• Test for maintainability: Maintainability includes those qualitites which influence how easy the component can be extended. Code structure, modularity, comments or documentation are the criteria.

Component tests are usually performed as whitebox tests on code level. The tester (or more common the developer) can simulate the flow of the program or the used parameters by manipulating the code itself. Modern component test follow the test first principle which means that all tests are considered before implementation starts. In this iterative process, the code is improved as long as all tests pass successfully.

Integration test

An integration test builds up on previous component tests of each single module. Groups of those components are assembled or integrated to a larger element or system. Tests in this step consider the interaction of the single parts with each other. So the goal is in finding error within the interfaces or the interaction with other components or external systems.

The main goal of the test is identifying faulty interface specifications or error in data exchange. The following error conditions are typical:

• Interface error: A sending component transmits none or false data so the receiving component can not work properly.
• Functional error: Communication works, but the involved components interpret the data different.
• Performance error: Data is transmitted correctly, but at a wrong moment or to slowly.

The chosen integration strategy is critical. Based on on the project plan and the system architecture, not all components are finished at the same time. The following strategies can be a help for planing:

• Top-down integration: The test starts which a component which is called once and calls several other components. The minor modules can be replaced by stubs which are replaced step by step by their real ones as they are finished.
• Bottom-up integration: The test starts with those components that do not call any further ones. The complete system is integrated step by step by high level modules.
• Ad-hoc integration: The components are integrated and tested as they ared finshed with development and component tests.
• Backbone integration: A program and process skeletton is set up which is filled stap by step with finished components.

What should be avoided is a so called big bang. This means that testing is not done before all components are finished and integration is tested all at once. With this situation it’s complex and time-consuming identifying the faulty components and get the whole system running at all.

The next part of the series will cover system and acceptance tests.