DevOps can be a big scary thing. Culture change, constant collaboration— whatever that means— a big new set of tools… it’s a lot. What most teams want is to have a smooth running software development pipeline. I have stopped using the phrase “DevOps,” and now I say “Continuous Delivery.” There are many reasons for this.
First, Continuous Delivery seems not as scary as all the big issues that surround DevOps. Second, it seems Continuous Delivery is what teams are really looking for. Third, my work mainly deals with developers and testers rather than IT, Release Engineers, configuration management, or Ops—that side of the DevOps triad is not my focus, nor the people I focus on.
There are a few forces happening at the same time pushing us in this direction.
The first one is the huge influx of tools that are making environment problems go away. Whether you are using containers, virtualization, cloud, on-premises cloud, or EaaS—there is a flood of tools automating IT tasks or moving to the cloud where many of those issues change or go away. The infrastructure-as-code movement and the tools to make it happen are only going to grow in use and ease.
Infrastructure-as-code also puts access and more control over environments and data in the hands of developers than they have had in the past. Programmers can control when code is promoted to the next environment, and the business can more easily control when code gets to customers. This is a big benefit of the new flood of tools and services. They are key to Continuous Delivery and, if the business chooses, Continuous Deployment.
There are many cultural and political changes that go along with DevOps. Just as with Agile implementation, I see many companies sidestepping or ignoring these cultural changes. All of these are topics for articles by themselves.
What I want to focus on here is testing in Continuous Delivery. Focusing on this phrase sidesteps so many of the difficult, or political issues associated with DevOps, and instead allows teams to focus on getting the product ready.
Using Continuous Delivery as a manufacturing production line with modern practices, such as Lean Software Development from Lean Manufacturing, gives us easy-to-understand ideals and practices to improve our efficiency. This is regardless of a toolset, or where we are in Development integration with Ops.
I often describe Continuous Delivery as the Lean practice of “quality at every step.”
Irrespective of whatever the organization is doing with tools, environments, task automation for environments or cloud, every Continuous Delivery pipeline needs quality at every step. Add some new code—unit test it. Make a new build—test it. Move to a new environment—test it. Integrate any service—test it. Add a new service with new data on a new environment—test it a lot.
On top of all of this, testing needs to be automated. So, the most important way to look at the impact of Continuous Delivery on test teams is that you better have all your tests automated—and automated smartly—because every time there is a change somewhere, some subset of automated tests needs to run in order to validate consistency.
Make the code change, then run a small set of tests, and do another build. Make a bigger change, or move to a new environment—then run a bigger set of tests.
Regardless of what you call your practices, your tests need to be automated so that anyone on the team can rewrite them if necessary, including any tool the team chooses to move the product to the next step in the development pipeline.
We will be kick-starting this issue on “Mega Trends in Testing: Continuous Delivery, Production Line, and the Deployment Pipeline.” We have some excellent contributors this month from the CD field. Eric Minick from IBM gives us an interesting take on CD, and Alex Martins from CA Technologies advises us on the best way to get your team ready. In order to help really grow your CD skills, we have chosen the best book for our practice, with a special guest Bas Vodde from Odd-e, here to tell you all the things you need to know before you delve in.
Don’t forget to check out our hit video series on all things DevOps and as always, we have a trending issue to discuss in TA Corner about how “Dockerizing” in TestArchitect makes for a winning combination.
What’s more, we have the results of our Testing in Continuous Delivery survey. Remember, we’ll be launching our third survey in our State of Software Testing Survey series, and this one is entirely on automation. Please take it, and share it with your networks, or other team members, the more answers we get, the more accurate of a picture of our industry we get. Our next issue will also be on Test Automation.
