Friday, April 21, 2017

The complete guide for Software integration testing | David Tzemach


Integration testing is a testing approach that we use to test the integration among two or more objects that should work and interact together. During the software development life cycle, we will see that integration tests are done on different objects that are not directly related to the system components.

תוצאת תמונה עבור ‪Integration‬‏

  • Integration tests between systems and OS.
  • Integration tests among the system modules (Testing the interface and communication among modules).
  • System integration testing (interfaces with external organizations, integration of system packages, etc.).
Another term that I will use in this article is “Interface”, an interface is a connection that connects two modules and the testing of this connection called “Interface Testing”.

Integration testing process

There is a basic process that you can use in an integration testing project, the process contains a few basic phases that are relevant to almost any other testing project.
  1. Analyze the requirements and specification of each module.
  2. Make sure that the person/team that run the tests are familiar with the technical details of each module and the overall system architecture.
  3. Now that you acquire the technical data, Review the Risks and determine the approach to remove them.
  4. Determine the testing strategy with a corresponding test plan (Test Scenarios, Test cases, expected results, test priorities etc.).
  5. Test execution (Executing the tests and open the relevant defects).
  6. Review of the test execution results and re-test if necessary.
  7. Review and approval of the testing phase before preceding to the next testing level (System Tests).

When to start integration testing?

Integration testing is performed after component tests and before system tests.

[Unit Testing] -> [Component Testing] -> [Integration Testing] -> [System testing]

Why do we need to use integration tests?

There are many reasons that can explain the need for this type of tests, let’s examine two of them:

  • Integration tests can lead to many situations that can trigger defects that will appear only in specific situations such as conflicts and dependencies between two modules.
  • Although each component is tested and approved (Prior to the integration phase), there is always a chance that the interface that allowing the communication between the modules contain defects that may trigger further defects in the integrated modules.


Module A should be integrated with Module B, both modules are tested and ready to interact one with each other, now let’s assume that the interface that should pass that output from Module A into module B has a defect that does not allow him to encrypt/Decrypt the data.

As a result, the two modules will fail to interact and sometimes, Module B will receive a corrupted and unexpected data that will lead to a massive failure.

One major thing that you should remember is that usually, each team/developer is assigned to develop a specific component and therefore in some cases he does not have the knowledge about neither the technical nor logic that is used to build the other module.

 Integration testing will allow us to test this “Uncertainty” and to validate that the gap is appropriately tested to allow the modules to work together. 

Integration test techniques

There are many techniques that we can use to successfully run this type of test, I will review them, but when the Hour comes, it’s your job to understand what is the most relevant technique for your testing project.

The Big Bang technique

This technique is actually very simple…. Before performing the tests, Development team will integrate ALL components/Modules at once (simultaneously) and then tested as one big system, once done, the integration tests will start for specific components/modules.

תוצאת תמונה עבור ‪Big Bang integration testing‬‏

Make sense when you need to test small systems
Consumes the integration testing time (the integration tests can start only when the whole system is tested)
All integrations are done before starting the integration tests
This technique is not relevant to large and complex systems.

Very difficult to trace the root cause of failures (Interfaces are not isolated during the tests)
Increases the chance to miss the small interfaces that need to be tested (All modules are integrated and tested at the same time)

The incremental testing technique

In this testing technique, the testing is done when modules that are logically related are integrated one by one and tested, this approach will continue until the last module is integrated and tested.

To use this test technique, we will need to use Stubs and Drivers that will help us to run the tests without the need to implement the entire module (Simulate the communication and data transferring between the modules).

When using the incremental approach, we can use two different methods called “Top-Down” and “Bottom-Up”.

Top-down integration testing 

When using the Top-Down technique, we will make the tests starting from the top higher module to the last module (Each module is integrated separately) based on the control flow hierarchy and the software architecture structure (we will use the top module and progress towards the lower modules that existing in the hierarchy).

תוצאת תמונה עבור ‪Top-down integration testing‬‏
Due to the nature of this technique, we will always have a TOP module that can interact with a lower module, the problem begins when the lower module is still not developed or just not ready for integration, as a result we cannot run the tests which affect the project timelines.

To overcome this problem and reduce the waste of time while waiting to the readiness of the lower module, we will use “Stubs”, stub is a term that represents a code snippet that can be used to accept the request from the top module and return a result similar to a real module.

It’s easier to find the Root cause of defects (A Single integration is tested each time)
Although stubs are similar to the real module, we will still need to make further tests once the module is ready, which consume more time.
This approach will allow the team to rank the major flows first, as a result, the most important defects will be found and removed before other defects that are less important.
In complex systems that built with many modules, we will need to develop multiple stubs
Comparing to the “Big-bang” approach, we can save time because we do not need to wait for all modules to be developed
In real world testing scenarios that involve complex design logic, you may have trouble to predicting how the stubs will react during the tests.  
often, you will find that the development of stubs will cost more than the actual module development

Bottom-up integration testing 

Based on the logical name of this technique, we can understand that we will start the tests from the lowest module of the application and gradually progresses towards the Top modules of the application until all modules are integrated and validated as a whole system.

תוצאת תמונה עבור ‪Bottom-up integration testing‬‏

The problem with this technique is similar to the problem that we had in the “Top-down” technique when you start to test the integration between two modules that one of them is still not ready to be integrated and tested (The higher module in our case).

To overcome this problem in the “Top-Down” technique, we used “Stubs” that are not relevant to our approach were you need to use another simulator called “Driver” that will allow you to use the driver to trigger/call the functions from the lowest module and to simulate the test inputs to the tested module.

Defects that are found in the lowest modules are easier to detect
The whole system is not built until the creation of the last Top module
It’s easier to find the Root cause of defects (A Single integration is tested each time)
The critical design flows are tested at the end which, increases the risk to find critical defects in this flow
Comparing to the “Big-bang” approach, we can save time because we do not need to wait for all modules to be developed

Entry and Exit Criteria

Like any other testing phase, integration tests should start and end based on a few basic criteria

Entry Criteria

  • There is a technical document that describes the expected behavior of each interface.
  • All major/critical defects from the early testing phases are closed and verified.
  • The test environment is ready to support the test scenarios.
  • The modules are integrated together and ready for testing.
  • There is a document that contains the test strategy.
  • Each component is tested and approved.
  • Each component has a list of Unit tests.
  • All risks are analyzed and removed.
  • All modules are identified.

Exit Criteria

  • All test cases from the test plan are executed and approved.
  • All major/critical bugs are re-tested, fixed and verified.
  • The test plan is signed –off.
  • A test review is done.

Best practices

  • Make sure that each component is tested and approved before executing the integration tests.
  • Make sure that you have a detailed technical document that explains how the interactions between each two modules (interfaces and how they should work).
  • In any case that it’s possible, automate your tests, otherwise, you will run each test manually per the integration of each module.
  • Make sure that you familiar with the modules to be integrated (Especially the design and architecture of the modules).
  • Determine the integration test strategy, this strategy should allow you accomplish the testing goals. 

1 comment:

My Presentations