Agile projects often involve heavy use of automated tools to develop, test, and manage software development. Developers use tools for static analysis, unit testing, and code coverage. Developers continuously check the code and unit tests into a configuration management system, using automated build and test frameworks. These frameworks allow the continuous integration of new software with the system, with the static analysis and unit tests run repeatedly as new software is checked in.
The tools usage in Agile projects must supplement people interaction but should not replace it. In Agile software development projects, there are many tools that are being used in various situations. Few examples of tools are: Developers use tools like SONAR for static analysis and code coverage, JUnit for code coverage. Developers also use configuration management tools like SVN, where they can check in source code, unit tests. The configuration management tool will compile and build the code with test frameworks.
Examples of few tools that are commonly used with build automation are:
- Make
- Ant
- Maven
- Gradle
- Jenkins
- JUnit
- Subversion
- GIT
These common toolset and build scripts allows for customization when needed, giving their customers flexibility to configure the tools to their individual needs. They support centralized controls and reporting, decentralized execution (Identity-based security). They can be easily deployed on the existing infrastructure where possible.
These automated tests can also include functional tests at the integration and system levels. Such functional automated tests may be created using functional testing harnesses, open-source user interface functional test tools, or commercial tools, and can be integrated with the automated tests run as part of the continuous integration framework. In some cases, due to the duration of the functional tests, the functional tests are separated from the unit tests and run less frequently. For example, unit tests may be run each time new software is checked in, while the longer functional tests are run only every few days.
One goal of the automated tests is to confirm that the build is functioning and installable. If any automated test fails, the team should fix the underlying defect in time for the next code check-in. This requires an investment in real-time test reporting to provide good visibility into test results. This approach helps reduce expensive and inefficient cycles of “build-install-fail-rebuild-reinstall” that can occur in many traditional projects, since changes that break the build or cause software to fail to install are detected quickly.
The goal of automated tests may also be to check the build function and its stabilization. Any build failure immediately warrants an action from the developers and testers. This can quickly help other developers not to get delayed due to build failure.
There are 3 kinds of builds, namely Fast builds, Full build, and Push-To-QA build.
- Fast build is triggered when it detects the source code changes, and it also detects complication, unit testing or packaging errors. It also performs the static code analysis and provides a web based build report on the code coverage. This build can be customized as per the team
- Full Build is scheduled usually twice a day, it is same as fast build, and it deploys into DEV server
- Push-To-QA build is scheduled On-demand and it deploy the latest DEV build to QA
Automated testing and build tools help to manage the regression risk associated with the frequent change that often occurs in Agile projects. However, over-reliance on automated unit testing alone to manage these risks can be a problem, as unit testing often has limited defect detection effectiveness. Automated tests at the integration and system levels are also required. There are frequent changes to software/application in Agile development, effective use of build tools and automated testing helps in managing and minimizing risks related to regression issues.