Automation in Agile

If there is anything that I have learned in my software development career it is that all development is Agile whether you call it that or not. Agile is fast, lean, dynamic and unforgiving. The development team is in a constant tug of war with requirements and at the same time trying to maintain quality. This poses a great challenge which Agile teams must learn to overcome. How do we balance quality with new functionality? The simple answer is automation. Automation is key for any successful Agile team.

Automation is simply the process of automating tasks within your software development and testing process. In a true Agile environment, software development is performed at such a fast pace that if there is anything that can be automated, it must be automated. We need to free up the development team from repetitive tasks to focus on building new things and fixing bugs. There is hardly any time to waste. One area where automation has existed for some time now, is the build process. If anyone has ever written a build script that compiles the application and puts out a released version of the software, then you have done automation. Every time the build fires whether using any build technology such as CruiseControl, Nant, or MSBuild, the build is automatically kicked off compiled, packaged and deployed to a server as a release for testers or anyone else to pick up. This is essential for virtually any software team out there, regardless of size. Automating the build eliminates one of the basic tasks that have to be done regularly and possibly multiple times a day. This keeps the team free from having any valuable resource tied up so that the team can focus on the more important aspects of software development.

Now we come to a slightly more advanced form of automation called Automated Testing. Once a build is created successfully, to assure it’s a quality build, a set of basic tests must be performed on it. This can be called a build verification test or a smoke test. The basic idea is to make sure that the piece of software that was just created is any good. Does it install? Does it even launch? Can it be deployed on a server? Whatever your software may do, there will be a set of very basic features that it must be able to do say it works, even if it may have bugs further down. This is something a lot of QA teams do as part of their daily routine. Their job is to verify and give a green light that the build has passed the basic tests and can be tested further for more regression, adhoc or exploratory testing. The challenge is that if your team wants to be Agile, this process should also be automated. A set of automation scripts or tests need to be built that perform this task unattended or automatically as frequently as possible; if not after every build then at least once a day. As the team is focusing on building new features or completing user stories, the automation is providing the necessary confidence and support to make sure that no major functionality is getting broken and the software still can be considered stable to be potentially shippable. This also reduces any unforeseen major bugs to creep in and surface when it comes time to close out a sprint or an iteration. Giving the team and its stake holders, greater confidence in the software they are producing.

While automation can be applied to many aspects of the development process, these two areas of automation are absolutely essential. Getting an automated build and automated test will give the team a strong foundation to build upon and increase development quality and speed. Remember, automation saves time and time is money!