If it doesn't fit together it is not complete.

If it doesn’t fit together it is not complete.

Integration testing is a type of testing in which components (software and hardware) are combined to confirm that they interact according to expectations and requirements. Integration testing is an important testing technique in any project, and perhaps even more so in Agile projects and programs, because it is core to the concept of the “definition of done.”  While important to Agile, actually performing integration testing can be difficult unless you have layered the technique into the Agile framework you use. In order to be able to perform an integration test of any sort you need a test environment that closely mirrors the target (or production) environment, a comprehensive build of the software, data that exercises the connections inside and outside the application and a test plan (including test cases). Thoses are the basic requirements for integration testing however there are all sorts of “nice to haves” that you can add such as test automation software, automated test scripts and an automated data build. You can survive without these extras, albeit any test will take longer.

Without an environment to run an integration test, the results will at best be ambiguous. The test environment should mirror the hardware and software configuration that the project will run when delivered as closely as possible to ensure that the results you see are predictive.  The goal is to understand how the software will work when the project is installed in production. While very few test environment are an exact mirror.  Examples of differences between test environments and production include debugging and test monitoring tools. As many have learned the hard way (whether Agile or not) is that every substantive difference between production and test is a potential failure point when we implement.

The second requirement for adequate integration testing is a comprehensive build of the software. This where Agile projects and programs with daily builds make integration testing much easier. Continuous builds (also known as continuous integration) are an important Agile technique that ensures that the parts fit together as work is done.  Continuous builds are nearly always coupled with either regression testing, which answers whether the changes made have broken anything, and/or smoke tests, which checks the major functions to make sure they still work.

The third must have is data for testing. Having carefully crafted test data ensures that you actually are testing what you want and need to test. The data for an integration test should be generated prior to each test run.  As projects add components or functions, the process that is used to create the test data must be updated or will risk missing testing the integration of a new component. The process of creating test data should be as rigorous as the creation of functionality that will be installed. One mechanism for accomplishing this level of rigor is to rebuild the test script and data as part of user story creation.  The tests will fail until the new functionality is implemented.

The final, and perhaps most controversial requirement, is a test plan. A test plan of some sort is needed to make sure the team knows how they are going to ensure that all of the components (software and hardware) actually work together and then prove it. How the test plan is documented, I will leave to the discretion of the reader (should include the approach and how the tests will be accomplished and how it will be maintained – note these can all be documented as tasks on a Scrum or Kanban board as easily as a Word document). I have seen automated integration test scripts that would suffice nicely for a test plan. The test plan should only include what is absolutely needed so the team can be assured that the all of the application’s components have been successfully integrated and that the application then integrates with the overall environment

Integration testing is an important part of how an Agile team works.  In many organizations the teams spend their spare time building the test harnesses needed to automate the process, so that it can execute outside of the teams’ core work hours. Testing makes their life easier in the long run and helps them deliver more value. When organizations start to ask questions about how integration testing can work in an Agile environment, it is usually a sign.  A sign that it is time to add some of the more technical techniques to the project management oriented Agile framework. The combination of continuous builds, with nightly regression and integration testing are hallmarks of a highly efficient Agile team.  Can integration testing be done on an Agile project or program? The question that you might ask is how can you be Agile without through integration testing.