My last blog on Agile software development discussed why the Agile release train methodology works well for Axcient. We develop and release on a fixed six-week schedule, with one week planning, four weeks development, and one week QA testing. Agile has various benefits for small and medium-sized businesses (SMBs) – for instance, it enables us to develop first-rate code, quickly complete fixes, and release frequent enhancements. However, it does lead to some challenges on the QA and testing front.

Releasing on a six-week cycle doesn’t leave much time for integration testing – particularly for functionality, which is finalized late in the six-week cycle. This drives the need for continuous integration. As the name implies, continuous integration means that everyone commits to trunk frequently, typically every day. Functionality that is incomplete is still checked in, but disabled.

At Axcient, we have invested in a high-powered build server so builds are completed very quickly. Hudson is used to kickoff builds at every check-in. The net result is that build breakages are essentially non-existent. In the rare event one does occur, everyone knows about it in a few minutes and the problem is resolved quickly.

We have also gone to great lengths to maintain a functionally stable trunk branch. QA engineers are paired with developers such that all code is verified on check-in. Trunk builds are verified continuously. Regressions on trunk are ‘all hands’ efforts. The management of builds and branches is a key area of focus for us, as it allows us to overcome any QA testing challenges and maintain a smoothly running Agile process.

My next blog post will continue on the theme of QA testing, looking at testing methodologies for the SMB environment.

jpeebles