Quality Assurance in Agile ALM
An ALM strategy always contains an organization's quality plan. In an Agile ALM solution, this includes Test Driven Design or Test Driven Development (TDD). So automated unit tests are necessary, along with the ability to have some metrics on those automated tests. Let me emphasize that the metrics are not meant to be punitive; they are meant as information for the team. For example, using a metric like code coverage can tell a team that all the code they have developed has a coverage level of 86% against a goal of 95%. In that case, the team should examine the reasons why their coverage is at 86%.
However, the tool cannot directly tell the team whether those tests are good unit tests. Teams must perform code reviews through pair programming or some other mechanism to determine that. As previously mentioned, automated acceptance criteria can be used for quality checks as well. Some teams use tools for Behavior Driven Development (BDD), which can help in this regard too.
Most tools also include support for automating GUI testing. Since GUI testing is very fragile during some phases of development, use this feature with care. When your product has maintenance releases with new features, GUI testing can help reduce regression testing costs greatly. But if your team has good TDD and BDD tests in place there is not as much need for automated GUI testing. Most tools allow you to track metrics on these automated tests as well.
Whatever methodology or tool your team uses in your quality process, the process itself is another pillar in your ALM strategy.
Below are some examples of tools that can be utilized for quality assurance. This list is by no means complete, but these tools support Agile methods.
DevOps in Agile ALM
One aspect of development that gets overlooked is the involvement of infrastructure groups with a product. The DevOps approach encourages greater collaboration between the development team and the infrastructure departments, in particular the operations group. ALM practices work well with the DevOps concept because they prescribe stable, consistent development environments that help assure product quality and seamless deployment.
Different environments need to be set up depending on the product (Web facing, desktop, or mobile). For instance, a Web product team may need integration, QA, staging and production environments. If these environments are set up in a haphazard way, your risk of introducing defects into production increases. The assumption is that the environments are set up in the same way. Keeping your environment stable and having a consistent, easily deployable build go a long way to eliminating variables between environments. This is critical to the devops concept, which includes a build system that takes the source control and builds and deploys it in a consistent manner on each environment.
Some Agile ALM practices in devops include continuous integration practices, where a team deploys to an environment once a day or sometimes every time they check in code. Some teams are using continuous deployment to quickly deploy to production, following all the good practices they want.
Picking ALM Tools
Choosing Agile ALM tools is a team decision. Development teams have different experiences and may be more productive when allowed to use the tools they select. I urge organizations to listen to their development teams and allow multiple ALM tools to be used. Also, allowing teams to pick their own tools (within some parameters) talks to the self-organizing nature of Agile teams. Organizations should give development teams some power in selecting the tools and making the ultimate decisions.
Armed with the right tool or set of tools, a development team can incorporate ALM into its Agile process and start reaping the benefits of Agile ALM.