Continuous Delivery and What the Heck Happened to QA?
By: Chris Mathias
Tags: DevOps, QA, Continuous Delivery, Software Development

Continuous Delivery (CD) is often considered a stakeholder’s dream. No waiting for long QA and UAT cycles, think of it: get it built: ship it. And you know what? Continuous Delivery is really pretty cool. But it’s not a free-for-all, as some people may purport. What it really requires is far, far more responsibility and discipline — and most importantly, collaboration — than what was inherent in traditional models.

I am currently implementing this process right now, and it has been an intense learning process. Recently while working on automating deployments with Jenkins, I was listening to a radio show and it became clear to me WHY CD works.

The program was talking about how people become engaged in their work, and how the assembly line and many facets of the industrial (factory) age optimized output while entirely disenfranchising people (workers). Often in my core-dev days, there were times I felt like a factory worker in a classic systems development life cycle. Now, as a technology leader, I have the blessing, even the mandate, to make sure my crew feels engagement and ownership.

Classic SDLC “I develop code, and throw it over the fence. QA reviews, tosses it back or sends it forward. Operations asks questions. UAT sends it forward or throws it back. In traditional development, we have “industrialized” software production much like a factory approach turns making a simple pen into a fourteen step process, each step done by a different person.”

In this classic model, a developer is involved in the various stages of the life cycle, but often doesn’t feel committed beyond their invisible wall — the hand off to QA. How can we help them feel committed to all phases?

Why I Think CD Works

I have been a fan of Agile for years. And then CD came along. I thought I knew how to run the process. I thought I knew how to get products shipped. And I did. I do. CD doesn’t change shipability or quality. It just shortens the Agile cycle. CD elevates my contribution, my commitment, and my responsibility.

How does it do this? Let’s look at a few more questions to get the answer.

What the Heck Happened to QA?

Once upon a time there were developers… They wrote code. They copied the code to a server. If there were issues, they fixed them on the server. If they were careful, they remembered to copy the same changes back down to their own computers. (then we invented source control)

As it turned out, we broke stuff more often than our customers liked! Thus, the position of QA was created. Someone who was responsible for making sure the code really did what the developer claimed, before it went out to the public audience.

Then we decided UAT was an important step so we added that. So now, once QA made sure the code worked as advertised, UAT checked to make sure it worked as it was intended.

At some point, we realized developers didn’t always make good admins. So, we made sure we separated those roles and pushed developers back to writing code. And what did they do? They monkeyed around. They got complacent. They started throwing code over and hoping for the best, relying on QA and UAT to sort out and solve the problems.