How can you reduce iterations in your integration cycle?

Do you have volatile integration cycles where many of the builds are not even testable? As a result are you wasting QA effort? Do you end up extending your integration cycle or worse yet release product that has not met your quality goals?

This problem is very common. It does not matter what you call the cycle (Alpha, pre-alpha, Beta, etc.), the impact of entering this period with broken software is profound. You may say that is exactly what this period is for and I will respond that I suggest there is a better way.

Today many organizations complete development and handoff their code to QA for test development and testing. QA must test three things: new feature tests, regression tests and system end-to-end tests. New feature tests will test features that are new to this release, regression tests should test the existing functionality and previous bug fixes, and system end-to-end tests include interoperability, configuration, stress and performance testing.

In my experience, most problems arise from new features. This makes sense because this is where the changes are made. It gets worse if a new feature changes underlying infrastructure or affects a broad cross-section of the product. Often teams endure build after build during an integration cycle to overcome the effects of new features and get to the point where they can find out about regression and system end-to-end tests.

So what can you do? The answer is a very simple concept but will take leadership courage to change. The answer is to move new feature testing and bugfixing before the QA handoff. The answer is to actually use your integration period for integration and not unit correctness.

The new feature's tests should be automated and integrated into the regression test suite before QA handoff. In addition any bugs that you fix to release the new feature to customers should be fixed before QA handoff.

The result will be a more effective integration cycle. The result will be a longer development cycle. This may appear as just a longer overall cycle for a release but in my experience it reduces the overall time for a release and insures better quality. It will also reduce frustration of your team in having to integrate a set of partially working new features.

This dovetails nicely into a train release model as well. No new feature can get onto a train unless it has complete automated tests and bugs fixed.

Philosophically this goes back to the definition of done I spoke of in a previous blog (http://heavenstone.typepad.com/heavenstone_inc/2005/10/index.html). It gets the whole team thinking about moving quality earlier into the development cycle. Because it makes completeness more self-contained within a project, this method can help managers work with employees on areas like ownership and accountability.

Try this and watch your teams be more successful.

More later ...