I am an Affilate!

I hope you get value from any product or service that I recommend. :) Just to be transparent, I may get a share of any sales or other compensation from the links on this page. As an Amazon Associate I earn from qualifying purchases. Thanks if you use any of my links, I do really appreciate your support.

Who Does Integration Testing? (Example/Black/White Box)

Integration testing is a pivotal part of testing and one of those areas that is always covered in the ISTQB syllabus. However, who actually does this and what is it? These are the questions I plan to cover in this article…

Who does integration testing? Developers and testers perform integration testing depending on the level of testing. There is a component as well as system integration testing that will be tested by their respective resources.

Now that you know who does what, let me go on to explain exactly what it is, the objectives, what types of defects you may expect to get from the process and more…

Why do Developers and testers do integration testing?

As discussed briefly, Integration testing is a term that encapsulates system as well as component-level testing. Therefore, there are different resources that perform each of these levels.

Component level

At the component level you would expect to see a developer doing the work.  This is because they need to be intimate with the component and have a deep understanding of how the component works.


At the system integration level, this is typically done by testers. They also need to have a deep understanding, but not of the component, of the architecture of the system and how these interfaces should interact, are you with me?

What are the objectives of integration testing?

Integration testing is an important part of the Software Development Life-cycle (SDLC). There is a number of objectives in this process and for that reason, I will give you an overview of this now.

Reducing risk

At the integration level, we expect a level of confidence in the systems that are to be integrated. Whether that be the components or the systems themselves.

However, integration testing reduces the risks before getting into further levels of testing because there are basic integrations that may not be quite correct.

A quick example of this could be a basic XML file interface which is misinterpreted by two separate parties (but more on this later).

Finding defects early

The benefit of finding defects early is reducing the cost further down the line. The cost of fixing defects towards the end of a project is substantially more than at the beginning or earlier stages.

Therefore it is important to capture the defects as early as possible. During integration testing is a perfect opportunity to see glaringly obvious integration issues such as what I mentioned earlier in a previous section about XML interfaces.

What types of integration tests are there?

As discussed earlier there are different levels of integration tests at the component and the system level. But let me give you more detail on each of these levels…

Component level integration

At the component level, we are focused on the interaction of the individual components. This is a lower level than the system.

This is after a developer completes their component testing (unit testing). And then take it one step further to confirm that the component that they have just unit tested can interface with the next component in line.


System-level integration testing usually happens after system testing (Click here to see why multiple rounds of system testing is recommended). It is essential to confirm that the system has been tested before going into integration.

The objective here is to prove that the system integrates as defined in the specification with external systems, for example, web services.

Examples of test basis items.

So far we have discussed the objectives of integration testing and how it works between a component and a system level. But what will be used to confirm how the integration should work? This is where test basis items come in..

Examples of test basis documents are as follows:

  • System (or software) design documents
  • Use cases
  • Interface definitions
  • Sequence diagrams
  • etc.

Typical objects used in integration

During integration there are a number of different objects that can be used at both levels, as you can imagine. But, to give you an idea of these, I will list down a few of these objects to give you an idea.

  • Databases
  • Interfaces
  • APIs
  • Microservices
  • etc

Common issues and defects expected in integration

Once you are in the actual integration test phase it is a good idea to find as many defects as you can, as I explained earlier. However, what kind of defects can you expect to see?

Component Level defects

At the component level, typical defects include data issues, interface problems, or functions that may not be handled correctly. E,g, causing indefinite loops or system component errors.

System-level defects.

At the system level, you will typically see defects around the actual system interfaces. one of the biggest issues that I personally experienced during my integration testing is XML interfaces that integrate with external systems that are hosted by third parties.

This usually comes down to ambiguous design specifications. These specs could be interpreted in two different ways. Or even data items that were not correctly defined and left open for debate.

It’s amazing the number of man-hours that can be lost just by a simple field not being defined correctly in a design specification.

However, this is the purpose of capturing these things at the integration level and not later on in the process when it cost more money.

The danger of complicated systems

Integration at the surface level may sound straightforward but it can get very complicated depending on how large the system is.

Also, it depends on how frequent and how far into the integration testing. Whether that be at the component or system level.

For large systems, for example, financial-based systems can be very complicated. Especially when you’re dealing with multiple third-party vendors that have to interface with different systems.

My experiences with it…

I remember dealing with a client who specialized in vehicle finance applications. During my time working for this client, I experienced a number of challenges with simple interfaces into their system.

During this process, one of the key things that helped push the project through was regular contact with the client and clearly defined specifications.

When is integration testing performed?

Briefly, we talked about integration testing at the system and component level but when is this usually done?

At the component-level, these tests will typically happen immediately after a component has been completed and unit tested.

However, logically speaking you need more than one component completed before the integration can be tested, obviously.

Therefore there may be a reliance on a collaboration of developers working together so that they can make integration happen.


As for the system testing, integration, as you can imagine, happens after system testing. Ideally. And again,  there is a dependency on the 3rd party system being available.

Therefore, you can be at the mercy of third parties and playing the waiting game if they are not ready when you are.

Is integration testing a black box testing activity?

You may be wondering how integration testing fits into the big scheme of things, right? Is it a black box testing activity or a white-box? The reality is, it can be white or black box testing depending on the test scenario. The best way to explain this is with an example…

Let’s start with a white box testing example. A white-box integration test could be the integration of how two web services integrate, at a component level.

Example of a black-box integration test…

An example of a black box test in this context could be, testing the integration of a vehicle finance system with an external credit referencing agencies system, in particular, making sure that the XML feed from the external agencies system integrates with your system.

Why is integration testing necessary?

So far you have learned about what integration testing is, its objective, etc. But why is it even needed? This is the question I will help to explain now…

Integration testing is essential because if dependant systems or components cannot talk to each other the system is useless, are you with me?

For example, from a system integration perspective, imagine that you have a credit checking online app, but you can log in and see your profile, but when you click the “get credit score” button you get no response because the interface to Experian is not integrated correctly, would you be happy to pay for that service? are you with me?

This is a simple but powerful example of how critical integration testing is.

What types of integration testing is there?

In integration, there are a few different ways to actually implement it. Each one has an inherent risk associated. Let me explain what they are…


This is one of the riskiest methods. It essentially means that all integration will be tested together and fingers crossed, it will work. The problem is identifying what has caused the issue in this method. If there are so many integrations at once it is a real challenge.


As the name suggests, the testing will start at the top-level components or systems and work its way down the integration tree.

An example would be testing the login page loads the profile page of a CRM system.


As you can imagine, this is the opposite to top-down testing. The integrations at the bottom will be tested first until you reach the top. So, following on from the previous example, the login page would be tested last.  This method is only really effective if the components or systems are ready at the same level.


Talented Tester Support

Skip to toolbar