Quality development

When it comes to in-house software development, quality plays second fiddle to nothing. There are plenty of tools, processes and best practices out there to enable a development team to deliver on quality demands and expectations, writes Roman Konovalov, managing director of Aroma Software.

  • E-Mail
By  Roman Konovalov Published  September 4, 2006

|~|romansep2200.jpg|~||~|Achieving software quality has been a hot topic in the computer industry for at least the last decade. In that time, many new methodologies and techniques have been introduced to help IT management improve quality and deliver better software products.

It might not always be clear to IT management that the development organisation needs to be moving towards new techniques and methodologies such as Rational Unified Process or different methods of agile software development.

There are numerous best practices to aid quality improvement in software development. For this review just two of them are considered - automatic daily builds and automatic unit tests.

AUTOMATIC DAILY BUILDS

As its name implies, automatic daily builds mean that all the source code of the product currently under development is compiled and linked every day. This job is performed automatically without any human intervention. In a typical scenario, these builds are performed overnight when nobody is in the office. ||**|||~||~||~|So, for example, at 2:00am every morning the system gets the latest source code from the development team's source code repository and starts building the entire product. Once completed, the IT manager or team leader gets the latest snapshot of the current development project.

Automatic daily build is a great opportunity to check that developers have not broken the entire system consistency and that it is at least possible to compile and link everything into binary files without errors. After a daily build is complete, the status report can be sent out to the entire development team with a summary of the build progress and the result.

When development practices that do not use automatic daily builds hit problems with new source code, very often, when the rest of the team want to re-start work on the project the next day, they cannot. This is because there are unresolved issues from the previous day.

The system under development is not in a consistent state. It might be very difficult to find the source of the problem. This is especially true in large projects, with a high number of developers working on different components. Compare this to an automatic daily build fail where the point of failure is known and the developer responsible can fix it as his first task the following morning.

Another good aspect of automatic daily builds is that communication between the developer and the tester is improved. If the tester finds a bug in the program, the developer starts fixing it. The next day, after the daily build has completed successfully, the latest system binary files are available for the tester to verify the problem has really been resolved.

As one of the additional options, a team manager might want to decide that after automatic daily build is completed successfully, the install program is generated for the entire system to make it easier for testers to deploy the latest version into the testing environment.

It would not require much effort for an organisation to start using automatic daily builds. Many tools can be found on the Web for both Java and .Net worlds. Products such as Cruise Control are distributed under BSD license and are free to use. Cruise Control is a really simple application. It integrates with many software configuration management tools such as Rational ClearCase, Visual Source Safe, CVS etc. Cruise Control provides many very flexible ways to set up automatic daily builds. It can, for example, be done at a specified time or every time source code changes are detected.||**|||~||~||~|AUTOMATIC UNIT TESTS

Another good practice for quality improvement is automatic unit tests. Unit testing is actually a validation that a particular part of the program is working properly. A programmer usually performs this task to ensure that his part works correctly. Unit test includes the standard test actions that a programmer has to run every time he makes changes to the source code.

Manual unit testing has several issues. It is time consuming for the developer to continually run tests. Additionally, there always are components of a program that, while having been developed and well tested a long time ago, have to now integrate with what is under development. Any changes to the new parts might affect the older components. Suddenly, the old features do not work properly or the entire program stops working.

These issues are not resolved even if automatic daily builds are running because daily builds check how the changes made by developers during the last day are compiling and linking together. Additionally, if a developer runs unit tests manually even daily, it also does not help much because he usually tests his own changes only and it is difficult to predict how they might affect other components of the program.

Automatic unit test is something that can help. All unit tests are run automatically every day, logically, after the daily build is completed so as to test the basic functionality against the latest version of the program that has been built during the daily build.

As with automatic daily builds, there are also a number of open sourced and free tools available, such as JUnit. Implementing automatic unit testing requires more effort than automatic daily build. Daily builds are more or less about putting all components of a program into the right order, deciding the time of running the build and defining a way to send out build status reports to team members. Automatic unit testing requires more work, especially if it is an on-going project.

In the case of a new project, automatic unit testing is simpler, because the team only needs to learn how the unit testing tool works and invariably can start using it from day one. However, in the case of an on-going project getting up and running with the automatic unit tests might be more time consuming. This is because, most likely, managers might want to define unit tests for the components that have been developed some time back.

In the case of a large project, this might be a major issue or challenge because of there could be a huge amount of completed work. But even so, there is nothing preventing the team from starting to use unit testing for the components that are under development and to create unit tests for the older components at the time the team makes changes in them.

So why are such automatic tools not used more widely by development teams today? One reason is the time spent learning how to use the new tools and adjust to working to the new procedures. They are delays that some organisations are not prepared to endure. But such reasoning is seen as being very short sighted. A week spent by the development team getting familiar with the automatic tools is a small price to pay for all the down-the-line benefits that such tools deliver.

Software development always seems to demand we get the final product out of the door as quickly as possible. But we often forget that there are smart ways to improve our work and do the same things faster and of better quality if we invest a little time in learning.

Once automatic procedures to run builds and unit tests daily have been deployed, teams will gain more and more time as development continues because problems will be caught earlier. This means that the developer responsible will be more efficient in fixing the problems because he remembers the changes he made yesterday. If the developer only finds out about the problem in his code two or three weeks down the line he would definitely need more time to recall the details of his work and what he was doing.||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code