Intro to DevOps for Testers

Level-Set: “What Is DevOps?”

DevOps is a transformative way of managing Enterprise IT as a whole. It impacts everyone involved in the process of building and then delivering a capability from idea to reality. The key priorities of DevOps are developing a thriving culture, viewing capabilities as strategic initiatives instead of baseline cost centers, and automating the delivery pipeline for products which allows continuous delivery of capabilities. The continuous delivery of capabilities is only possible if testing is completed from start to end of the delivery life-cycle and if releases are automated.

DevOps Consulting

Automated releases prevent human error when executing tasks for deploying capabilities to production. With automated releases, production deployments for DevOps can occur frequently. If production deployments are small and iterative, the deployments can occur during business hours with minimal human oversight. Along with these automated releases, the automation of infrastructure configuration imaging allows for test environments to quickly backfill with production codebase for immediate readiness for component-based testing.

A Simplified Look at the Traditional Enterprise Model for Capability Delivery

However, in the traditional model of technology delivery, the process is far more cumbersome and prone to error. In this model, the Business Customer builds the feature that is desired to be delivered. The specification is delivered to the Application Development Teams (SDLC team members) based on the specification. Once development is complete, the SDLC delivers the capability to a release team for testing.

Since the testers are receiving the code after Application Development, often the test results are ignored or undercut since testers don’t fully understand the new capability. Furthermore, since development is already fully completed, the cost of fixes identified issues increases dramatically. The original developers now have new projects to work on or do not remember everything they developed. Unfortunately, the costs of fixing defects increase even more when complex business acceptance testing occurs just prior to delivering the capability to Release Engineering/Deployment team. Often times, to make a release date, the issues are introduced in production and the Release Engineering/Deployment team is blamed for introducing issues into production.

However, the fault of issues deploying to production is not the fault of any one central team member, including the developer who didn’t know how developed code would interact with other enterprise systems.

Agility and Incremental Workflows: The Bridge to DevOps

To resolve these issues experienced by teams who practice the traditional model for software delivery, the bridge to DevOps is required. By using DevOps, the enterprise establishes a common goal which is required to achieve success and relieves tensions amongst team members when debating what priority capabilities to deliver.

The first step towards DevOps is committing to enterprise values and aligning goals with those values. If values are established then the DevOps practice follows. Team members can only align with a common goal if they have shared values. This value can be simple but guides decisions during a crisis and ensures that team members behave in alignment with that shared value

Fortunately, the DevOps process focuses on learning how to improve delivery processes. Perfection is not required. DevOps is about getting it right during the process and figuring it out as we go. To maximize the benefits of DevOps, teams should strive towards these primary agility principles:

• Articulate a vision and get buy-in from your internal customers
• Find the minimum requirements for a solution
• Optimize the whole and limit work in progress (WIP)
• Build great teams

These common agility principles are accepted by the software delivery teams (developers) but are more difficult to adopt with team members who don’t develop the capability.

Tying DevOps…to Continuous Delivery…to Testing

With this basic understanding of DevOps, it’s important to understand the immense benefit of incorporating the enterprise testing strategy into DevOps. The greatest risk in the delivery lifecycle to production is during the build of code. By the time a capability is developed in the test, the cost of fixing any issues goes up after the build phase. In the traditional model of delivery, the majority of testing is completed near the end of the delivery life-cycle. This testing is during integration testing instead of during build.

In continuous delivery, the majority of testing is during development to detect issues early-on. Since most defects are caused by code artifacts interacting with other applications the developer didn’t have insight into during development, early detection of these application conflicts reduces the cost of fixing the defects prior to production deployment.

Jez Humble and Dave Farley wrote a book called Continuous Delivery which describes how to rectify all the issues of traditional software delivery. One highlight from the book mentions the Great Team who is aligned to the project or workflow outcome (e.g., mission or vision of company). In this continuous delivery Team, the Business Analysts, Application development, Testing, and IT operations are all on the same Team. All the Team members follow this basic workflow for continuous delivery:

• Business Analyst designs the functionality and test cases
• Application Developer builds the code to fail the test cases
• Software Testers enable the capability to flow through the automated testing timeline. Testers consult developers frequently to ensure capability is tested correctly.
• IT Operations maintains all the Development code, testing code, and Infrastructure code in tight version control.

The success of this workflow is that every member of this cross-functional team is responsible for the delivery process.

Major Implications for Testers

Testers add incredible value to the team by helping developers test more Unit tests since this testing can be executed quickly, cost-effectively, and conveniently. The User Interface tests should be used as sparingly as possible because it can’t be fully automated.

Unfortunately, in the traditional delivery model, the recommended pyramid for testing is upside-down. In continuous delivery, the foundation of the pyramid is Unit testing which should consume the majority of test cases. The top of the pyramid is user acceptance testing which should be the most minimal

testing. In the traditional delivery model, unit tests are typically minimal while user acceptance testing claims the bulk of test cases. The consequences of this upside-down pyramid include fixing defects when they are most expensive and most critical to the business.

The Deployment Pipeline Concept

To take advantage of ideal testing strategies, the Delivery Team creates a hero or story that must defeat the obstacles of quality gates. Each unit test is automated so that every software delivery triggers automatic testing. Moreover, the Delivery Team has to resolve any defects before delivering the next piece of functionality. Although this delivery is ideal, it only works if the software is delivered every day.

Even though this process should include as much automated testing as possible, some processes are too complex and require business acceptance testing. Still, the ease of continuous delivery and testing is based on the unit testing, not the minimal business acceptance tests. As proof of the benefits of automated testing, the maturity matrix for continuous delivery has the most mature teams running only automated tests.

In Summary

Testing and QA is not a separate function: it is a key enabler of continuous delivery. All team members are responsible for code success or failure, including the testers. As per the great Werner Vogels, CTO, Amazon “You build it, You run it.”

Ensuring that developers have the resources to maintain responsibility for their code through development to delivery is one of the greatest methods to release successful capabilities to production. By collaborating with testers and creating automated test cases, this enables developers more control over their code from start to finish.