Automation in Agile
Automation in IT can be defined as a set of programs/steps which can be performed independently to achieve required functions and leads to the reduction of manual effort and improvement in code quality. Automating the repetitive procedures can provide real value to the projects which are getting executed using Agile methodology.
Automation is a vital component of maintaining agility, and it is a top priority for the entire team, as seen by defined practices/disciplines and a commitment to continuous improvement. Automation is used in a variety of ways, including continuous integration/builds, unit, functional, and integration testing, and continuous/automated deployment.
By reducing manual effort, automation in software design and testing eliminates risks associated with human error. It spares developers and testers from repetitive activities and allows them to focus on the more critical aspects of system quality, thus improving build and testing effectiveness as well as operational efficiency. Build and testing automation also ensures reusability and scalability, which in turn translates into significant cost savings.
Some of the areas where automation can play an important role are:
- Code build and deployment
- Unit test execution
- Generating code coverage reports
- Functional & Performance test execution
- Generating code quality metrics reports
- Generating coding conventions reports
After the process has been identified, the Team is recommended to investigate how to automate the process and identify the tools that could assist with automation. Also, the Team needs to estimate the level of effort required to implement the automation against the total cost and risk of manual procedures. In most cases, the decision boils down to cost versus benefit analysis. This module covers overall concepts of Automation and the areas where Automation can be implemented along with the associated tools in an Agile project.
One of the key principles and benefits of following Agile methodology is faster feedback. This feedback includes feedback from the Clients, Product Owner, and Delivery team members. Often the term “Fail Fast” is used to emphasize that it is better to fail earlier so that impediments can be corrected based on the feedback.
Agile projects usually will have shorter release cycles in order to get early feedback from clients. Though the functionality delivered is less, it is more important to deliver the right functionality. From the delivery view, it is important that the team (developers and testers) should be able to deliver faster. It is imperative that any repetitive manual tasks should be automated. This will free up the time spent by team members on these repetitive tasks and focus on delivering more value (might be another story) to the users.
The complexity of a typical enterprise application development and deployment process involving multiple branches and multiple projects adds a huge cost overhead and risks to the organization.
Some of the benefits of using automation in these cases are listed below:
|S.No.||Typical Manual process||Automated process|
|01.||A tight control is needed on individual components for monitoring the overall process||A Transparent process as the progress on all components are more visible and risks can be identified more easily|
|02.||Higher repetitive efforts during deployment||Reduced efforts during deployment|
|03.||The Risk of manual execution error is high||Once standardized, the errors are avoided|
|04.||Could run into quality issues||Once standardized, a high level of quality is maintained|
|05.||Inconsistent results as the process are dependent on the persons involved||It gives standard results always.|
Some typical real-life instances:
- Scenario 1: The developer is supposed to make changes to existing functionality. After completing the development, the developer must test the changes made. Now, if there are no existing unit test cases, the developer must be performing unit testing for the entire functionality again. This will in turn increase the time taken for the changes. If the test cases are automated through various unit testing frameworks using x Unit, the test cases can be run quickly and validated immediately. The developer can focus only on testing the changes and creating unit test cases around these changes.
- Scenario 2: After completing unit and integration testing, the developer must promote the changes to QA/testing environment for further testing by the QA team. If the promotion to the QA environment involves multiple requests to the infrastructure team and a few hours delay, this will create a bottleneck. It will be an impediment to the overall team, as there could be multiple stories that need to be promoted to the QA environment.
Usage of Automation in Agile:
1. Automation in Development:
- Unit Test suite: Unit Testing is one of the basic building blocks for Continuous Integration. Developers can have a series of their testing automated as simple unit tests and make it available along with their versioned codebase. These tests should be living test suites i.e. they should run to success at any point in time. Whenever a code module is changed, the corresponding unit tests should also be updated and ensured that the test cases are passed. The automated unit tests are the first line of defense and a crucial part of the “Fail Fast” approach. Various unit testing frameworks that are available are – JUnit (for Java), NUnit (for DotNet), utPlSql (for Oracle PL/SQL).
- Code Quality Analysis: Static code analysis needs to be performed to identify and quantify the code quality metrics like standards, security risks, and adherence to best practices. As part of the development practice, code quality checks should be run. Only after attaining satisfactory quality metrics, the code should be checked into the version control tool. Some of the key tools for Static Code Analysis are CAST, SONAR. Note that developers can make use of the IDE (Integrated Development Environment) integration capabilities of these tools to integrate static code analysis in their development process.
2. Automation in Build:
Continuous Integration (CI): The aim of practicing Continuous Integration is to maintain a build environment that is able to generate “Production Ready” builds. As part of this practice, the following actions will be performed:
- Analyze the code for quality
- Build the code
- Execute unit test cases
- Upload build artifacts
- Post-build and test results
- Alert the team with results
This can be achieved effectively through automation. For further details on CI practice, please refer to the study material on ‘Continuous Integration and Associated Tools’ of this course.
To aid in this practice following support systems are required:
- Source Version Control tools: Through “hooking” (proactively notifying other tools when new code changes are made) or “polling” (other tools have to poll the Version Control tool to determine whether new code changes are made), any new code changes should be determined and communicated to other tools by the version control tool. Example – Git, ClearCase, SVN
- Build tool: A robust tool/framework that helps in maintaining and code build more easily. Example – Maven, ANT.
- Static code analysis tool: As described in the above section, these tools are used to check the code quality. Example – CAST, SONAR.
- Build repositories: A robust repository to maintain the builds that can be uploaded/downloaded/searched with ease. Example – Nexus (for maven builds)
- CI server: Interacts with all the above components and performs the actual build of the application along with the execution of tests either automatically or just by a click of a button. Example – Jenkins, Hudson.
3. Automation in Deployment:
Continuous Deployment (CD): A mature Agile team extends the Continuous Integration practice so that the application can also be automatically and regularly deployed into multiple environments (realistically lower environments like DEV and QA). This is required to maintain “Production Deployable” builds. Any deployment issues will also be validated, as part of this process. This is known as Continuous Deployment.
A typical CD process includes:
- All Continuous Integration steps
- Deployment into needed environments
- Execution of smoke tests
- Publish the outcomes of the deployment
- Alerting the team with results
Usually, an enterprise application will follow multi-tier architecture which includes multiple technology (Example – J2EE application with Oracle backend). So, to achieve deployment automation in a multi-tier architecture, there should be an automated orchestration.
For automating the deployments, the delivery team can have a custom script or use an automation framework like uDeploy. The CI build servers like Jenkins/Hudson can be configured to perform the CD activities as well.
4. Automation in Testing:
With the nature of the Agile methodology, the software that is developed iteratively will be subject to testing multiple times either as part of the system integration testing or regression testing. So it is imperative to automate test execution as much as possible. There are various testing automation frameworks that are available like Cucumber, FitNesse, QTP, etc. that help in writing and executing the test cases. It is recommended to create the automated test cases right from the beginning of Sprint execution in parallel with the User story development.
Once the test cases are automated, they can be scheduled as part of the build servers to be triggered automatically. This will ensure that the tests are run often and the failures are reported as early as possible. Following are the various stages that can be automated:
Today, automation is an exciting focus area for technology organizations and a lot of technologies and tools are emerging in it.
- LiquiBase: This is a tool that tracks the changes that are made to the database. The changes to the database are maintained in an XML. This helps in subsequent Rollback of changes or applying a change in one environment to another. This can be used to create/roll backtest data for unit test cases or to move the changes from the DEV environment to higher environments.
- Chef: This is a tool that automates the deployment and management of infrastructure. With this tool, Infrastructure is treated as versionable, testable, and repeatable similar to the application code.
Challenges in Automation:
There are many obstacles to implementing automation in Agile projects. These are:
- Pressure from Product Owners: Product Owners would like to get their working product out and may not be willing to let the team spend the time on automation frameworks that might benefit long term. All the stakeholders must be taken into confidence on the benefits of automation. Return on Investment (ROI) can be calculated on the adoption of automation and used for articulation.
- Maintenance of automated scripts: It is important that the automation scripts are well maintained along with the production code. Enough support to be provided to the team to ensure that the changes to the maintenance of the automation scripts are taken up along with business priority. As the total number of automated tests increases, the time taken for building and executing the tests tends to increase. The team should decide on the priority of the tests executed along with the build and ensure that needed refactoring of automation scripts is performed to improve, wherever possible.
- Lack of follow-through: Though the delivery team adopts the best practices early in the development process, the team might lose sight of the vision and may compromise on the automation activities. The delivery lead or any member of the team should constantly remind the team in case of any deviations.
- Agile Maturity: Development team might have the mental makeup of giving preference to the code than the automation scripts or frameworks. The team should be trained appropriately and instill the practice of creating automated tests along with development, for sustainable maintenance of the application.
- Timing of Automation: Automating the build process when the project is nearly over, provides very little benefit. It can, however, save dozens, if not hundreds of hours when automated as soon as development/ testing begins.