Once mechanics finish opening up an automobile given for periodical repair and servicing, each part is cleaned, oiled, and checked for failure. After re-assembly, the mechanic also checks if the different parts, which worked fine independently, perform expectedly in combination with each other. If not, then the purpose of the automobile is rendered useless.  

This is the principle on which Integration software testing also works on. Every component of a software application has to undoubtedly be tested when working as a unit; however, its performance as a module of several units has to be evaluated. This is easier said than done; one of the major issues that crops up is coding of individual components of software, which invariably are done by different software engineers. Integration testing has to evaluate if the logic used by the developer in coding is as per expectations of the software module.  

Another key issue necessitating integration testing is the change in the structure of data when it moves between interacting modules. As far as modern software applications are concerned, those need to be integrated with third party payment systems or social media, which needs to work seamlessly for the user. This makes integration testing a necessity.  

The most important aspect to be tested when integrating units is the interface between them. For example integrating legacy systems with new ones or softwares of two different enterprises might create issues.  On the whole, the functionalities of the software should not be lost upon integration.  

This might sound simple, like assembling a plastic construction toy, but it is riddled with complexities. For example, in consistency with DevOps philosophy of software development, one cannot wait for the entire software module to be ready to start integration testing.  

Testing has to start as and when unit testing is completed and integration starts; it occurs simultaneously with development of the software (DevOps).  

Integration Testing is broadly categorized into:  

  • Big Bang testing 

This is where testing is done after integration of all modules. This is useful only for small software as an error is detected much later in the SDLC. This translates into a higher cost of fixing the error (a DevOps unfriendly approach) 

  • Bottom-up approach 

Testing is started from the lowest or innermost unit of the application and progressively moved up. This is advisable when a bug is detected in the lowest unit of the program as it becomes easier and hence less costlier to fix.  

  • Top-down approach 

This is the opposite of the Bottom-up approach  

  • Mixed (sandwich) 

This is a combination of bottom-up and top-down approach, but it requires a larger workforce which is also highly skilled, making it costly.  

To Quote a real-life scenario  

A leading Amerian retail store offering fashionable jewelry and accessories at affordable prices for youngster with a presence across 27 countries was Aspire’s client for Integration testing of their software application.  

Their broad requirements was coverage of SFCC, SFOM, SFCMC, WMS, store-picker app and Avalara validations. However, the testing procedure was tricky as it involved tough deadlines and co-ordination across different time-zones for properly syncing real-time testing of WMS.  

Aspire’s testing experts came up with a comprehensive solution which provided a zero-defect leakage and 100% test coverage with 300 SFOM end-to-end test cases covering order types, products, checkout options, payment options, promotions, and shipping types.  

Explore our Retail Integration Testing services here!

Follow us on Aspire Systems Testing to get detailed insights and updates about Testing!

Latest posts by Siddharth Prabhakar (see all)