We were recently having a debate around what is the ideal and most effective / efficient way to do integration testing in complex environment with large number of applications to try to get software delivered.
In an organization that has a number of different application teams doing work and releasing independently. These teams independently are "agilish" and they do unit testing and functional testing early on in their cycle and can deliver when their changes are in their own application silo without any other impacts. That being said, when it comes to integrating more complex changes that have larger impact on other apps and teams, and having to get into the environment with every other team that is making changes, it causes large perceived bottlenecks in our ability to do proper integration testing.
The problem exists where there is a perceived "integration testing bottleneck" due to a few reasons:
- The perception that a separate set of folks (outside any of the individual teams) need to do this work
- Its quite possible that each team is doing "too much dev" as they don't realize that the system as a whole can't absorb so much change given the integration testing that gets required so we are wasting time developing features that we can get shipped.
The only recommendation so far is to have teams push their changes into the integration environment as soon as possible (so changes are visible to all teams as early as possible and issues get detected as early as possible) but I wanted to see if there are other recommendations for how to "optimize" in this situation around large integration testing.
Any experimental and unorthodox ideas are welcome (technical, organizational, etc). Also, any case studies or references to companies who allegedly do this well and have best practices would also be great.