Large group system development for small groups

The Continual Build and Test technique (CBT) of software development ensures that acceptance tests are successful by helping to identify which functions are truly necessary for release.

By Dennis Brandl August 1, 2009

www.controleng.com

Control system software development is usually performed by a small group. However, techniques commonly used by large groups can also be used effectively by small groups. For example, if you are using a waterfall development method, or the SCRUM ( www.scrumalliance.org ) and Agile ( www.agilealliance.org ) methods, there are some large group techniques for handling Final Acceptance Tests (FAT) and Site Acceptance Tests (SAT) that work well for small group use.

Employing these techniques is important because there is often management pressure to move to a SAT before you have finished a FAT. Unlike other engineering disciplines, in software engineering it is difficult to look at software and quickly see if it is ready for site deployment. This means that software sent to a site is sometimes not functional or has parts that do not work.

One way to avoid this problem is to use a technique known as the Continual Build and Test (CBT) cycle, along with the use of multiple build directories. Continual builds may seem to be incompatible with a waterfall method of development, but the CBT approach can be used during the coding and testing phases of the project. Using a CBT cycle means that you will always have a “ready-to-ship” system, but one without complete functionality. CBT starts by using an automated test-and-build system. This means that “make” files, “Ant” files, or command scripts are used to automatically build the software and run a set of tests. The best method is to run the CBT cycle every night with the automated tests used to validate the nightly build. When a new function or feature is added to the nightly build directory, related FATs must then also be developed and added to the nightly build directory. The new or modified FATs test the newly added elements. Commands to execute the FATs are included at the completion of the build process.

In the CBT approach there is a lot of pressure to not “break-the-build.” All developers have the responsibility for running unit tests, ensuring that their code builds, and therefore having a good expectation that their code will pass the FAT. They perform these tests in their own local “sandbox” directory. Everything that a developer works on is in his or her own sandbox. This does make the “make” files more complex because the build utility must check the local sandbox for files and then check the build directory for unmodified files. In the morning, all developers are responsible for checking their part of the build and addressing any problems that came up during the FAT run.

Once the daily build has been successfully built and the FATs successfully run, the build directory should be moved to a “distribution” directory. The same CBT cycle should be run on the distribution directory and the resulting code provided for user tests. The distribution directory is always a “ready-to-deliver” system. At predefined intervals, or when the required level of functionality is reached, the distribution directory files can be copied to a “Final Build” directory, and the CBT cycle can run again. The final build is now ready for SATs.

Using the CBT method, the question never comes up if testing should be cut short, but instead becomes what functions or features are really required for the release. That’s why the CBT approach is one of the most successful methods for large projects, but can also be used on small projects to remove problems of sending unworkable code to sites. This method allows developers to work in their own sandbox and in an integrated build and test environment.

 

www.controleng.com

Author Information

Dennis Brandl is president of BR&L Consulting in Cary, NC, www.brlconsulting.com . His firm focuses on manufacturing IT. Contact Dennis at dbrandl@brlconsulting.com .