DevOps is taking software development by storm… Here’s what it means for testers.

DevOps is a little word that has become very much the trend. It comes from uniting the words Development and Operations, with the idea of joining two worlds between which there is usually a lot of friction. One speaks of “DevOps culture” perhaps because it is something that’s more related to people and their ways of working, and not only with technologies; it is about uniting two things that are historically separate: software construction (development) and the operation thereof. It’s also about uniting more parts of the different worlds involved in the creation and operation of software.

DevOps Culture

A DevOps culture proposes to generate a culture of learning, communication, and feedback cycles at different levels. It’s not just a technical thing, much less a role, even though you often hear “I’m a DevOps” or “Looking for a DevOps for a very cool company.”

Typically, something like this happens: there’s an idea, change, requirement, etc., the developers work on writing code, they put together a package that is passed to the operations and they are the ones that put that into production, and from there it goes into the hands of the user. After that, it’s the operations people who keep managing it, and are responsible for everything that happens on the production side. There is a typical conflict of interest between development and operations that often causes difficulty and delay:

• Developers want to give the user the product as soon as possible (more so within agile methodologies, possibly aiming to put changes into production as often as once a week).
• Operations does not want to put something in production that might cause problems, then have to regress, recovering backups because the last change broke the database or the system crashes, and then users call… and they are the first line of support.

This demonstrates a huge source of friction between development and operations, which affects the business. And this does not happen due to the tools we use. As Jerry Weinberg’s second consulting law states (from his book, “The Secrets of Consulting: A Guide to Giving and Getting Advice”),

“No matter how it looks at first, it’s always a people problem.” Jerry Weinberg Click to tweet

DevOps is a culture. It not only deals with the technical parts, but it has a lot to do with the human components and with the processes. To overcome the possible friction, communication is fundamental. Interaction is also essential and the way in which responsibilities are divided and shared implies an Agile approach that involves not only the developers, but also the operations team.

And DevOps culture is not only adopted because it’s the “in” thing. It’s used to reduce the time between the birth of an idea to its release.

According to a study mentioned here: 

From the same article mentioning the study, I borrowed the following image, because I think it represents the concept of DevOps culture very well. It shows all stages of the development process, with continuous feedback, continuous integration, all surrounded by real-time communication.

The Evolution to DevOps From a Testing Perspective

Something I found particularly interesting was Katrina Clokie’s way of viewing DevOps from a tester’s point of view, from her book, “A Practical Guide to Testing in DevOps” (A book I highly recommend!).

She shows in three different figures, how the relationships between testers and everyone else involved in software development have changed throughout the evolution from waterfall to Agile to DevOps.

In waterfall, we have the tester interacting with different roles, but since the testing is independent, it finds itself siloed, isolated from the rest of the team.

Then, in Agile, you see there is just one team, with a more horizontal structure, all sharing responsibility for quality, without distinguishing as much all of the different roles.

But here as you can see in Agile, the development ends when the “package” is passed over to operations to then release into production. In the team’s Kanban, we would see that the concept of “done” implies that the code is production ready, but it is still not in the hands of the client. Agile always praises “the team” but it fails to include operations team members, support, etc.

I think the signs are clear, DevOps emphasizes having the right conversations, at the right time, across different teams to maximize outcomes.

Are you working within a culture of DevOps? Do you think it’s here to stay? Let me know in the comments!

Recommended for You

We Want Our DevOps Venn Diagram Back – Plus One! 
[Infographic] What is a QE?