It is hardly possible to use software that fails to connect to third-party enterprise systems or whose modules fall apart. To prevent such issues, test teams perform integration testing.
As one of the key points ensuring a project success, integration testing comprises component integration test cases (cover the interaction between integrated modules in one system) and system integration test cases (cover the integration of several interacting systems).
In this article, we explore a case from our software testing practice to help you grasp the essence of integration testing better, namely, integration testing of an e-store.
Integration testing: Project overview
The project featured a B2C e-store for a large multi-industry company running chains of gas stations along with roadside diners, gardening centers, as well as retail and wholesale stores. The customer already had a B2B e-store and an ERP system with affiliated BI and accounting modules. The new e-store had to be integrated with these systems.
As the project proceeded, the customer asked the development team to add new functionality to the ERP system. These were invoices to be sent to the customer’s buyers and suppliers. Meanwhile, the existing B2B e-store had to remain fully functional. To allow for this, the project team reproduced a copy of the production database and worked in an emulated test environment.
To implement integration testing efficiently, the testing team mapped the project structure:
Relying on the project structure, our testing team developed the integration testing strategy that covered two integration types:
- Invoice functional unit + ERP system (component integration testing).
- New B2C e-store + ERP system (system integration testing).
When deciding if they are going to automate the testing process, the team was in two minds. On the one hand, automation reduces time and efforts for repeatable tasks requiring extensive concentration. On the other hand, automation of integration testing can be tricky. To be effective, it requires substantial sets of repeatable or at least predictable data. In our case, ERP system was updated with new diverse items every other day. Pricing policy (discounts, sales, loyalty programs, etc.) also changed oftentimes. So, the team opted for manual integration testing.
Component integration testing example: Invoice unit + ERP system
The development team deployed Invoices, a new functional block of the ERP system. These invoices had to be sent to the customer’s buyers and suppliers. The team had to assure that the invoice unit was able to process queries from the ERP system. Key queries concerned purchase, sale and return procedures.
After the testing team fully understood the scope of work, they developed manual test cases (20) to cover the interactions above. Component integration testing discovered a number of critical bugs. Most spectacular defects considered incorrect pricing for Return procedures (both incoming and outgoing).
For example, the new module didn’t process discounts. If a product was on sale, the customer received the invoice featuring the regular price. Another critical defect concerned VAT. Invoices contained amounts of VAT different from those in the waybill. This could hurt the customer’s reputation badly.
Some defects could hamper the ERP Administrator’s work. For instance, ERP failed to browse edited invoices (incoming and outgoing) showing an Error message.
Bugs fixed, the testing team continued with a trickier case of integration: new e-store and the ERP system.
System integration testing example: new B2C e-store + ERP system
This type of testing had to verify that the ERP and the new e-shop were seamlessly connected and responded to mutual queries. Most important integration points included:
- Same prices in the ERP and the shop.
- Correct goods on sale.
- Correct information processing in the ERP system if a good is sold/returned.
The success of integration testing for these modules was critical. If something went wrong, the e-store customer UX would be hampered.
Testing uncovered various integration issues with the severity ranging from medium to critical. The most important bug was the e-store crashing when an e-shopper added an item to the cart. Another critical bug covered the e-store’s inability to process the amount due for several items when the user pressed Enter button.
As for bugs of medium severity, the most significant one considered the rounding of the amount due. While for users this bug was insignificant or even pleasant (in case of rounding towards a lower cost), it wreaked havoc in the customer’s accounting module. Verifying that the accounting documents and the ERP data added up involved considerable efforts of the manual testing team.
All in all, integration testing in the project took about 15% of overall testing efforts.
Integration testing is a complex two-fold testing effort that makes an important part of any more or less complex project. It covers component integration within one system and system integration with external systems. Integration testing requires an effective strategy based on:
- Good understanding of the product structure and the interconnections and dependencies between its modules and systems.
- Project specifics. This is crucial for choosing a testing method (manual or automated). For instance, automation doesn’t pay off in projects relying on large sets of changeable data.
Though detailed theoretic explanations are important, real-life examples are always necessary to back them up. Practical integration testing examples should help you plan and run efficient integration testing in your projects.