distributedlife

There are two places you can first integrate a build for a release candidate. I’ll call these early integration and late integration and take place before or after functionality testing respectively.

Early integration runs on the premise that the sooner a system is integrated the sooner the stability of a system can be gauged. The coders will work on separate systems or parts of a system, they unit test and then integrate their code lines into the release candidate.

The problem with early integration is that if you do find a problem, you don’t know if the root cause is a functional problem or an integration problem. If the code is functionally tested in isolation before integration then you know the problem is related to integration.

One of the arguments against late integration is the cost involved. The assumption is that functional testing is performed twice, once in the functional environment and once in the integration environment. The integration environment shouldn’t be a repeat of all the functional tests. There is always going to be crossover but it shouldn’t be 100%. A capable tester should be looking at the suite of test cases and deciding which ones are to be run once and which ones are to be run twice. For heavily integrated code, [unless there are mocks], there will be less emphasis on functional code. For more isolated code then the number of integration tests is obviously reduced.

Late integration gives you better visibility into the cause of defect. If the defect is in the functional build the problem more than likely relates to your code. If it is an integrated build then you know it’s an integration problem. Any defects you do get during function testing can be fixed by short cycles between the coding and testing teams. The impacts of these changes only affect the scope of one system or component. If the system was being continually integrated after each and every change all testers would need to re-do their integration tests each and every time, except for the last cycle it would all be for naught.

Worse than this is the rippling effect of defects in a system that is integrated before its time. A problem is uncovered and a fix is applied to the integration build. The testers start to retest the code when another defect is found, uncovered or created by the first fix. The second fix has a chance to reveal more problems and again and again the problem continues. The testers spend all their retesting and chasing defects across the system than is truly necessary.

Another advantage of late integration is that after functional testing, user acceptance testing can commence; the system may not be completely integrated but enough of the system can be shown to the end users. They can get an understanding of the workflows, they can truly visualise what was just a concept in their heads. If this happens after integration and the system has missed the mark then the integration needs to be undone. This is my next point.

If you have an integrated build which has a number of changes in it and at some point a decision is made to remove several changes due to quality, then the work involved in unpicking the dropped changes or the remerging the valid changes adds time to the lifecycle, after this integration testing has to occur again.

Late integration is all about giving a code the best chance of being of high quality. Different testing foci are applied to the code and the release candidate in an expanding view of the system. Each level of quality is assured before the next begins. Early integration should really be called premature integration.