Integration Testing

What Is Integration Testing

Suppose there are several small systems, each of which works well.

The developers performed unit testing and made sure that all the necessary unit tests (Unit Tests) have passed.

These systems need to be combined into one. A logical question:

Will the new large system work as well as its parts?

To answer it, one has to perform system testing (System Testing).

It usually requires considerable resources, so other questions arise:

Does it make sense to test the whole system at this moment?

Do the parts interact with each other correctly?

These questions can be answered only after integration testing (Integration Testing).

A Lyrical Digression

Skip

Let us consider an analogy far from IT. You have a warehouse and two detachments of recruits: firefighters and peasants. You need to check how fast the firefighters carry water, and how the peasants sow wheat. The result will be, for example, a thousand litres a day and one hectare a day. This is an analogue of system testing: the field is sown, the water is carried.

But what if, approaching the warehouse, every firefighter takes a sieve instead of a bucket, and the peasants have to use the remaining buckets?

Water is carried in a sieve, and they sow through a bucket - does it make sense to spend a day on such a test? Will it give you any useful information? I think the answer is obvious.

To avoid problems, you need to put a person at the exit from the warehouse who will check whether the recruits are taking the right equipment or not.

This will be integration testing of the interaction between the recruits and the warehouse.

Definition

INTEGRATION TESTING is defined as a type of testing in which software modules are integrated logically and tested as a group.

A typical software project consists of several software modules coded by different programmers.

The purpose of this level of testing is to identify interaction defects between these software modules when they are integrated.

Integration testing focuses on checking the exchange of data between these modules. Therefore, it is also called «I & T» (integration and testing), «string testing» and sometimes «thread testing».

A couple more comments on what can be considered integration testing:

Consider a situation in which a developer has performed a unit test. In this test interaction with a database is implied. A stub was used instead of the database.

This is still a unit test; there is no integration testing here.

The developer performed the same test, but with a real database, even if it is some test DB.

This can already be considered integration testing, since the interaction with a real DB was checked, and not with a stub.

Why Do Integration Testing

Although every software module undergoes unit testing (Unit Testing), defects still exist for various reasons, such as:

• A module is usually developed by one developer, whose understanding and programming logic may differ from those of other programmers.
• Integration testing becomes necessary to check how software modules work together.
• During the development of a module there is a high chance that the requirements will change on the client side.
• These new requirements may never have undergone unit testing, and, consequently, integration testing becomes necessary.
• The interfaces of software modules with the database may be faulty.
• External hardware interfaces, if any, may be faulty.
• Improper exception handling can cause problems.

An Example of an Integration Test Case

Let us consider a simple example with pictures.

Suppose I am a tester from Aviasales and I want to check how the integration with the site works Booking.com and at the same time make sure that the hotels are visible on the map.

Here is what my test will look like in a simplified form:

Test Case ID is the number of the test. Test Case Objective is the goal. Test Case Description is the description. Expected Result is the expected result.

Now let us go through the actions step by step.

You need to go to the site Aviasales and choose some route.

Suppose I miss Costa del Sol and want a ticket to Malaga , fill in the forms and press the «Hotels» button

The transition to a new page has been made, but I am still on the same site.

You need to press the «Find hotels» button

The transition has been made; the booking site mentions Aviasales. The integration Aviasales - Booking works.

Let us check the Booking - Google Maps integration. Press the «On the map» button

The hotels are visible on the map. The Booking - Google Maps integration works.

It is interesting why Aviasales has an integration with Booking when they have their own hotel aggregator - Hotellook

I hope it has become a little clearer to you what integration testing is. Of course, the example given is very much simplified. In the real world one would have to test in far more detail. The main thing that would be emphasised is checking that the commissions, that is the money, go through. And that is much more difficult than clicking through a couple of pages by hand.

Let us continue to explore integration testing, focusing on its various types.

Approaches, Strategies and Methodologies of Integration Testing

The Big Bang Approach

In the Big Bang approach, most of the developed modules are joined together, forming either the whole required system or a large part of it.

Then testing begins.

Advantages

If everything works, this way can save a lot of time.

Disadvantages

However, if something goes wrong, it will be difficult to find the cause. It is especially hard to make sense of the results of a big bang when the tests and/or their results are not recorded in enough detail.

The whole integration process can become much more complicated than with bottom-up or top-down testing.

All this can prevent the goal of integration testing from being reached within a reasonable time.

From all of the above one can conclude that the Big Bang approach is a potentially fast but risky approach.

The Incremental Approach

With this approach, testing is performed by joining two or more logically related modules.

Then other corresponding modules are added and checked for correct functioning.

The process continues until all modules have been joined and successfully tested.

The incremental approach, in turn, is carried out by two different methods:

• Bottom-Up
• Top-Down

Stubs and Drivers

The incremental approach is carried out with the help of dummy programs called stubs and drivers. Stubs and drivers do not implement all the programming logic of a software module, but simply imitate the transfer of data with the calling module.

Stub: called by the module under test.

Driver: calls the module for testing.

How to make stubs?

Of course, everything depends on what you are making the stub for. A round manhole needs a round cover.

If you need a stub for a REST API, you can read detailed instructions in the following articles:

«Stubs for a REST API on Flask»

«Stubs for a REST API with SOAP UI»

In SOAP UI the term Mock Service is used to denote stubs

The Bottom-Up Approach

In the bottom-up strategy, each module at the lower levels is tested with the help of the modules of the next higher level , until all modules have been tested.

The help of drivers is required for testing

Advantages

Localising errors is much easier. It is immediately clear which test fails because of which module.

No time is spent waiting for all modules to be developed, unlike in the Big Bang approach. To move testing forward, it is enough to have only certain modules one level higher.

Disadvantages

Critical modules (at the upper level of the software architecture), which control the flow of the application, are tested last and may be subject to defects.

That is, everything may work well, but a small mistake in the implementation of the business logic at the upper level will force all the testing to be redone.

An early prototype is impossible, so if you need an MVP quickly and the presence of some errors is not critical, then with Bottom-Up testing you can wait a little and perform at least a few tests at a higher level right away.

The Top-Down Method

In the top-down approach, testing is performed from the top down, following the control flow of the software system.

It uses stubs for testing.

Advantages

Localisation of faults is easier.

The ability to get an early prototype.

Critical modules are tested in accordance with their priority. Major design flaws can be found and fixed first of all.

Errors in the implementation of business logic will be visible right at the start of testing.

Disadvantages

Many stubs are needed. If not all modules have yet been implemented at the lower levels, they have to be imitated. This is additional work for the developer or the tester.

Modules at a lower level are tested inadequately. Some errors, especially in unlikely scenarios and corner cases (Corner Cases), may remain invisible until a certain point.

The Mixed Approach - Sandwich

The highest-level module is tested separately.

The lower-level modules are tested bottom-up.

Advantages

It gives confidence in the lower-level modules, plus the overall readiness of the software for release is immediately visible.

It is good for large projects in which realistic deadlines have to be set.

Disadvantages

Extra time is needed for coordination and for involving a potentially larger number of testing participants.

How to Organise Integration Testing

1. Preparation of the Integration Test Plan
2. Develop test scenarios, cases and scenarios.
3. Execution of test cases followed by reporting of defects.
4. Tracking and re-testing of defects.
5. Steps 3 and 4 are repeated until the integration is completed successfully.

A Brief Description of Integration Test Plans

It includes the following attributes:

• Testing methods/approaches (as discussed above).
• In-scope and out-of-scope items of integration testing.
• Roles and responsibilities.
• Preconditions for integration testing.
• The test environment.
• Risk mitigation plans.

Entry and Exit Criteria of Integration Testing

The entry and exit criteria for the integration testing phase in any software development model

Entry criteria:

• Unit Testing of Components/Modules
• All high-priority errors are fixed and closed
• All modules must be successfully completed and integrated.
• The integration test plan, test case and scenarios must be signed off and documented.
• The necessary test environment for setting up integration testing

Exit criteria:

• Successful testing of the integrated application.
• Executed test cases are documented
• All high-priority errors are fixed and closed
• The technical documents that must be submitted are accompanied by release notes.

Guidelines and Tips

• First determine the integration testing strategy that can be adopted, and then prepare test cases and test data accordingly.
• Study the architectural design of the application and identify the critical modules. They must be checked according to priority.
• Obtain the interface designs from the architecture team and create test cases for detailed verification of all interfaces. The interface to the database/external hardware/software application must be tested in detail.
• After the test cases, it is the test data that plays the decisive role.
• Always prepare mock data before execution. Do not choose test data while the test cases are being executed.

Article author: Andrei Olegovich