Everyone takes responsibility for all aspects of quality and testing, including those related to deployment pipelines, monitoring, and observability.
A DevOps culture is, to me, the same as what an agile culture was meant to be. We don’t work in silos, we don’t wait for another team to do something for us. We share our knowledge and help others learn the skills, and are there to support each other as needed.
Don’t underestimate your ability as a change agent. The secret is to find your allies.
Lisa also shares a set of handy questions to get started with building relationships with ops people.
How about you, what does DevOps culture mean to you?
And how do you build those all-important relationships?
I’m so glad you enjoyed the post, and thanks for starting a conversation here! I’ve met a lot of testing professionals who think DevOps is for someone else in the organization. My experience has been the opposite. A few years ago I used the term “DevTestOps”, but someone pointed out to me how many testing activities are central to DevOps. Collaborating to assess risks, to strategize how to deliver a new feature, to think how we’ll know if a new change is valuable to customers, that all involves testing. We testers make big contributions.
Thank you @lisacrispin for raising this issue. The roots of DevOps are in Deming’s 14 Points for Management. Deming’s philosophy also was an important influence on agile. The 14 Points include psychological safety, which is an important point for me because so much depends upon it: Drive out fear to improve psychological safety – TestAndAnalysis
Definitely! And it’s reflected in the larger community. For example, I joined the DORA (DevOps Research and Assessment at Google, who do the State of DevOps survey and report) community. I thought it would be all platform engineers and SREs, but the members are from a wide variety of backgrounds. And most conversations end up being about testing in some way!
I’m not that familiar with Deming’s work, to be honest. So cool that people like him were talking about the need for psychological safety even years ago.
I am also a member of the DORA Community, and found its disucssions really interesting. One of the discussions led me to write this: Are you testing output and outcome? – TestAndAnalysis It is great that you are reading and John Willis’ book it is a good introduction to Deming’s philosophy. I have been talking with him recently too
@lisacrispin I have been thinking about this. I find that if I understand the history of an idea I understand the idea better. John Willis, who is one of the creators of DevOps, talks about the history of ideas in our space. The short version of the history of ideas he speaks about is: Deming → Toyota → Lean → Agile. This means that you find Deming’s philosophy in Toyota, Lean, Agile and DevOps and is why I find Deming’s philosophy useful. Do you find the history of idea useful too?
For sure! Interestingly, in our small breakout group in today’s DORA community discussion, someone asked if there was any history written about the growth of Scrum, XP, agile from the mid 90’s to the mid 00s. Some folks talked about agile being a reaction to waterfall, and DevOps being a reaction to agile. That’s maybe too simplistic, but I think we do need to learn from history. I’m told that the John Willis book is a good way for someone like me to learn more about Deming’s work, so I look forward to that.
Rosie, it’s interesting. I’m not so much an “insider” in the DevOps community - though, I think we are ALL part of it. When I think of my own “testing community”, it encompasses the MoT community, the Agile Testing days community, and a lot of people I’ve met over the years. Years ago people talked about “schools of testing” and I was never a fan of that idea. You are a wizard of community building, I’m interested in your thoughts.
Devops culture is closely tied to testing but I think its only tied to the “when to do testing”.
All the other Ws and Hows are more on the testing side.
Recently, I’ve noticed some DevOps knowledge advocating all code and no hands on approach towards testing. That, I don’t like.