This podcast covers DevOps culture, testing, and how the two mix in modern app development.
Join the DZone community and get the full member experience. In today’s Quality Sense episode, Federico has a conversation all about DevOps and testing with Sumit Agarwal, the Lead Cloud Architect for a global fin-tech leader with over $4.5 billion in revenues that helps clients get ahead of today’s challenges. Listen to today’s episode where they touch upon the origin of DevOps, testing and dealing with legacy code, and making the necessary culture shifts to successfully implement modern software delivery practices. Relevant Links: Quality Sense, a Software Testing Podcast · S3E6 – Sumit Agarwal – DevOps and testing Hello, Sumit, how are you doing today? I’m very good. Hi, Federico. Nice to be here. Thank you so much for joining. I saw that you are also an organizer of different conferences around the topic of DevOps. Can you tell me a little bit about that? Sure. So I’m involved with All Day DevOps from a culture transformation track perspective. Derek Weeks, who is the co-founder for All Day DevOps, he actually credits the track to me. We were out at a dinner while he was visiting London and we got talking and I presented at the first, All Day DevOps conference, and I just mentioned to him that I believe what was missing was a cultural transformation track given DevOps has such a heavy culture component. And he said to me, if I wanted to run it, I’ve got it, so I then hosted from the next year on the culture track. I think this year was the first time that I actually moderated other tracks instead of the culture track. But it’s 24 and it started long before we were hit by COVID and everything went virtual. So it was the first 24 hour live virtual conference to get DevOps conferences, to people who didn’t have travel budgets or were in remote parts that didn’t have DevOps conferences. And then when I moved to New York after attending my first devopsdays New York, I actually got in touch with the organizing people and started working with that committee. So that was 2019,2020 and COVID hit us right as we ended devopsdays New York,2020. March 5th was when the conference ended and everything pretty much locked down. If it had been towards the end of that week, we would have probably had to cancel the conference. Oh, just in time. Just in time, yeah. So, yeah, my love for the DevOps community started with me attending devopsdays in London. And then Andi Mann, who’s with Splunk, we got talking and he introduced me to All Day DevOps. So yeah, the community overall is fantastic at sharing and promoting good ideas. Yeah. One of the few positive aspects of this pandemic is that we have the possibility of attending conferences all over the world without extra budget for that, right? Yeah, indeed. Yeah. And talking about DevOps and the culture around DevOps, what’s your view on how testing is related to DevOps? So, I think the name just happened, DevOps the name just came about because of the history of it with a Birds of a Feather session, and then Patrick Debois setting up DevOps days Kent, and the conversation from there going into, how do we… And I think, agile was already a thing. And so scrum, agile, were already things and so when they use the word dev, they kind of assumed we were talking about dev teams, which included testing and QA as a function within dev. And the conversation was about how we get agility to infrastructure and the operations aspect. “ So the name, DevOps, didn’t exclude testing, we’ve heard DevQAOps, DevSecOps, but that wasn’t the idea of it all. It assumed that QA was already part of that dev wording. “ And so, yeah. And then there’s the continuous delivery aspect that comes into it and I think you can’t do continuous delivery without that staying incorporated into it. The whole idea of DevOps as Gene Kim has talked about and everywhere else. Pipelines or automation on pipelines is an integral part of the DevOps culture, the DevOps mindset. The whole idea is increasing feedback loops and shortening those feedback loops, the cycle time. And by speed of delivery, you actually want to make it less risky and risk equals testing in some respect. So I believe in all of this, testing and risk reduction is at the heart of DevOps. We want to have more confidence in what we’re deploying into any environment. So we want to move left on everything. So whether that’s unit testing or any other aspect, it should be incorporated into. I really like talking about the culture around DevOps, because I have seen that many people confuse the term DevOps with continuous delivery or automated pipelines or things like that, but what’s happened with the so-called manual testing or exploratory testing. How is that connected with DevOps? The thing is, and as I was talking about being more comfortable with software releasing or releasing software, and we then start talking about, and Martin Fowler spoke about the testing pyramid, there’s so much that automated testing can do that there is still space for manual and exploratory testing. So what DevOps and automation doesn’t mean that you can replace that human aspect of it when something that automation can only cover so much, if what needs to be in a certain place, you could make it transparent on a screen and still have the automation pass. You could probably check the colors, but how many permutations and combinations and then there’s the whole accessibility aspect of what if I’m color blind? And does everything match up? And yes, you could automate all of that, but the amount of time you would spend to automate that versus actually having a human test that manually or exploratory best thing, it doesn’t take away from that fact. And you still need somebody who has a testing mindset to come up with what needs to be tested and what should be tested automatically every time we’re putting it through the system versus, or through the pipeline versus what should be done once. Like I built it, I’m not going to be changing some of that, and that’s more of an exploratory thing. Yeah, I mean, again, UX and design, etcetera, you can’t automate tests. That is something usable that has to be very much a manual thing. Yeah. The mindset, I think this is the key here, is like having the mindset and then with this testing mindset, you can decide which things you should automate in order to be more efficient and less error prone or improving your processes. But also there are many things and aspects that you should continue doing enough in a manual way. I mean, with the agile delivery, what are you changing more frequently and what is likely to break, you automate that piece, but what you don’t change and what isn’t adding value. If you end up spending 50 days writing an automated test for something that never changes you’d really be not adding value to your testing process. So there’s the space for manual testing on that front. You have a background working in a big financial company, I think when talking about agile, many people tend to think of small scrum teams or maybe start-ups. How is it different in a big corporation? So I think with a big company there’s multiple challenges. One, you’ve got a huge amount of scale and there’s the whole legacy aspect as well. We have systems that were written in the ’80s and ’90s, well before TDD was a thing or test automation was a thing or waterfall ways of delivery of those systems, and they continue to make a lot of money for the organization. So there’s been partial rewrites, there’s components that are added with more modern technology, ways of delivery have changed on those things from waterfall to agile, but still the legacy aspect as, and there’s various different definitions of legacy, some people call it legacy equals money-making, legacy equals non-tested code, so from that perspective, I’d call it a combination of all of those, that there may be bits and pieces that are tested from a regression testing perspective.
