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!
