Integration testing is not a new topic for software testers—any introduction to software testing or software engineering includes a discussion about integration testing. However, in the current dynamics of product development and confirming quality in the agile world, the definition (both narrow and broad), significance, and scope of integration testing have increased manifold. What are the changing facets of integration testing that teams need to make note of?
Traditionally, integration testing has focused on confirming how independent modules of a system work together when the individual pieces are brought together as one whole system. This basic definition of integration testing is still the same; however, what has changed is when, how, and how much of it is done. Previously, integration testing was one piece in a sequential and staged engineering life cycle coming in after unit testing.
Today, it is continuous integration testing that is the trend that most organizations adopt in the agile life of continuous development. And if continuous integration needs to be the backbone to support ongoing testing, a large portion of integration tests need to be automated to run in an unattended manner. The tester manually interjects to determine the integration testing scope, identify any product changes that necessitate additional scripting/testing, monitor automation outcomes to analyze results (both pass and fail), manage defects, and keep a constant eye for additional exploratory testing. Automation lends itself to enabling integration testing on an ongoing basis. While this is one important change in how integration testing has evolved over the years, teams still have complete control over the integration scenarios when it happens at an “intra product” or even “intra organization” level.
Today, teams are required to go beyond these bounds too, given the inter-product scenarios they are having to embrace. Several external APIs are being leveraged, several plug and play technologies are interfacing with one another, including mobile, several product collaborations require support, and data may not be available internally (external data feeds may have to be mandatorily ingested). All of these take integration scenarios and associated testing to a completely new level, requiring external vendors to also partake in the integration life cycle. Multiple iterations of integration testing may be required to cover not only the functional pieces of the modules that come in together but also non-functional areas such as performance, security, and usability, as these are significant pieces that may fall short of expectations when modules are stitched together.
Given how closely users are involved in product engineering and reverse feedback in the current setup, it wouldn’t hurt to have a round of user testing overlap the integration cycles to get user feedback early on, even before formal user acceptance testing can commence.
Such are the changing facets of integration checks in today’s software world. Integration testing has come a long way in its evolution and will play an increasingly important role in the years to come.
