I personally think the answer to my title question is an obvious “yes.” But I do see a lot of discussions about how the DevOps movement and/or culture has “killed” testing or has removed the need for testers. Let’s talk about that.

Developers have to understand a lot of complexity about the environment they will be shipping software into. Similarly, production operation teams need to increasingly understand the internals of the software they ship.

The quality aspect is right there! It’s front and center. And one of the ways we determine the presence or absence of quality attributes is via testing. So, of course, testing fits into a DevOps context.

Wider Testing Focus

That said, to see this does require seeing testing as a mediating mechanism. And to see that, you must see testing as a design activity. And when you do — when you truly see testing as a design activity at all levels — do you start to open up your options.

So testing, as a function, needs to be pushing information into the developers and product proactively. This is as opposed to reactively having those teams pull information from testing. The reason for this is because if teams are pulling from testing, it means they are likely looking for nothing but test reports about execution. That’s testing as an execution activity, not a design activity.

If those teams are getting pushed from testing, that means testing is informing, guiding, and encoding their decisions. That means testing is putting pressure on design at various points, such as when we talk about what to build and then when we build it. That’s testing as a design activity.

In modern software environments, testing does this with the minimum of artifacts and tooling, relying instead on the dynamic collaboration and communication of teams who share in the development process.

Wider Developer Focus

This is why testers should probably become developers.

And that’s also why we, collectively, need to focus on delivery.

A Delivery Focus

What matters is that all members of the development team work with the delivery and customer teams to understand what the customers need to be successful. Focusing on finding the simplest solutions that provide the right amount of value, consistent with or knowledge of what that value actually is. Everyone on the team is responsible for turning the functionality requested by the customer into software that provides value.

And part of that focus on delivery, particularly if that delivery is more rapid, requires testing.

A Sustainable Delivery Focus

Software development is ultimately about change. We want to get those changes into production — to users — in a sustainable way.

Software can always be changed. That’s not the trick. The trick is to do it safely and at a reasonable cost. Generally our goal is to deliver more value with less waste in less time and with greater opportunity. “Waste” here refers to churn and rework. “Opportunity” here refers to opportunity costs.

Okay, so let’s ask this powerful question: Can those changes be given to users are soon as they are implemented? That’s a key question our industry is grappling with.

Let’s ask another powerful question: Could quality still be achieved if development was done directly on production?

If so, how? If not, what’s the minimum that has to be done to achieve confidence in quality?

Those discussions are interesting ones to have in any context, but particularly in a DevOps context. I say these are interesting because what always comes up when taking these questions to different logical conclusions is that there is some minimum amount of this thing we call testing that has to be done.

So, yes, testing fits into DevOps. In fact, it’s integral to it.

A Revised Focus on Done

And this let’s us also have better conversations about what “done” means. Being extremely simplistic here, DevOps in a nutshell allows us to combine definitions of “done.” Traditionally — but also simplistically — we can say the following held true:

• For developers: “done” means that requirements are implemented in code.
• For testers: “done” means that the code is tested.
• For operations: “done” means that the code is released.

Now, however, everyone operates off of the same “done”: when the product is in the hands of customers, providing value to them and allowing for feedback.

And this is where we tend to get into discussions about “being continuous.”

A Continuous Focus

To be able to deliver continuously, first you have to define “continuously.” And probably whatever definition is used will mandate that automation is required. And it is. Automation is a way to leverage the most important asset in this chain: the human. We use automation as a tool to support testing.

Whether the automation is doing testing is largely irrelevant in the context of the above more important discussions. To me, automation is doing testing as an execution activity; it is doing a limited subset of the testing execution that we know we can entrust to tooling.

But there’s still a whole lot that we can’t entrust to tooling. There’s still a whole lot of human that has to go on as well.

So, yes, testing does fit into DevOps. In fact, it’s impossible to have effective DevOps without testing, of both the human and machine variety.