Integration testing: real-life example

Integration testing does not frequently grab the headlines of the hot news in the Information Technology section. The scale of defects is definitely not as critical as of security defects.

Also, planning for a software release, business stakeholders rarely ask for integration testing giving priority to functional testing, cross-browser and cross-platform testing, or software localization testing to meet the demands of the international audience.

However, it does not seem right to underestimate the importance of integration testing as it is one of the primary keys on the way to a solid product release.

What is integration testing?

Integration testing is the phase in software testing in which individual software modules are combined and tested as a group.

The first thing that comes to mind is the software integration with the payment systems. No doubt, assuring the quality of payment flows is an important aspect to be tested, but not the only one. Today, business relies on a large number of software solutions like websites, ERP, CRM, CMS systems. Smooth communication among them all will guarantee proper users’ requests handling, service delivery efficiency, and overall business success.

In this blog post, we are going to demonstrate what systems might be tested in the QA project and what can be the possible challenges that engineers will have to beat.

Integration testing: project review

Client

A representative of a popular English-language magazine (available in print and digital formats) turned to a1qa to perform full-scale testing of the website.

Product under test

Apart from the website functionality, the team was to check the Subscription Portal that was an integral part of the website and consisted of a few components. This module was of prime concern, as the business relied on it for revenue.

The subscription function was implemented with the help of the following software solutions:

• The open-source CMS system eZ publish that performed subscription data filtering (type of subscription, subscription period, discounts applied, etc.).
• The website through which a user interacted with the system.
• Salesforce CRM software. It stored all users and subscription data. An additional plugin allowed the client’s team to manage the subscription acquisition, create new types and review the existing ones.
• Zuora SaaS software to process billing and payment flaws.
• Mule ESB service bus to enable data exchange between the components.
• The database as a BI tool.
• Salesforce Marketing Cloud software for online marketing.
• Drupal CMS used to function instead of eZ publish. At the given moment, it contained data of the registered users and serves as a tool for publishing articles, video and audio content.

The subscription workflow is the following:

1. User’s data is gathered.
2. A user is provided with a possibility to subscribe after filling out the personal and payment information forms.
3. The subscription order is handled by a third-party contractor.

Project goal

The client was planning to free the process of the third parties involvement. For this purpose, it was important to make sure that the developed system could function properly on its own.

Testers’ task

The a1qa team was to ensure that the whole system made up of the above-mentioned components was able to solve the necessary tasks.

a1qa integration testing strategy

1. Key business processes, covered by the system, were defined: buying, cancelling, freezing, and renewing a subscription, changing the billing information, etc.
2. Test documentation was developed with the consideration of all possible variations. In the project context, variations are all possible flows (e.g., subscription can be cancelled by a client, or automatically if the payment was rejected by a bank). The documentation was to include checking things, like whether the subscription can be performed successfully for all products within each business process.
3. Testing included a systematic execution of every business process from the start (where it was initiated) through all the transitional steps and to the final business process (or processes), checking that all the data was transferred correctly and the expected outcome happened.

Most processes included data transferring from one module (most commonly Salesforce) to the rest.

If the starting point was not SF, the information went from the starting module to MuleESB, and then to SF. After that it was spread to the rest of the modules (again, via MuleESB).

All in all, integration testing took about 40% of all the a1qa efforts.

Challenges

Surprisingly, but the majority of the integration testing difficulties were caused by the poor requirements elicitation at the very start of the project. The requirements of poor quality caused defects and the overall system instability.

What was the problem? Initially, the requirements were prepared by developers and looked like a number of User Stories in JIRA, containing only the headings without any explanation.
The a1qa team initiated the changes in the requirements preparation process. Description and Acceptance Criteria became the fields that should be filled for every Story. Subtasks were also created with a clear definition of who was responsible for its fulfillment.

Integration testing: automate or not automate?

Test automation is a complicated question and requires detailed consideration of all the pros and cons.

Integration testing automation needs an even more detailed approach. On the one hand, automated scripts reduce the QA time. On the other hand, automated tests are effective only when dealing with continuous or, at least, predictable data sets.

With subscription, it is not often the case – the data is updated regularly and randomly. Therefore, the testing was mostly manual.

Only at the later stages of the project, the automation was put into practice. What test cases were automated? The key business processes were selected. Each business process had a number of variations written. Only the test cases that covered the most stable business processes were automated.

With such an approach, automation guaranteed maximum coverage at optimized costs.

Results

The project is still on, though, even now it is possible to conclude that the system works properly. While each component is performing its function separately, all together they help to reach the goal of the non-stop business processes operations important for the client’s business.

Bottom line

For a project with complex business logic, integration testing can’t be neglected.

For effective testing, defects and flaws detecting, the QA team must:

1) Understand the structure of the product, knowing how all the modules interact;

2) Know the specific aspects of a project. It is important for preparing good test cases, tests analysis, making a choice between manual or automated testing techniques.