Your transformation toolkit

Advance your enterprise testing strategy with our transformation toolkit.

Learn more

Agile testing

Continuous Testing and DevOps: A Chat with Ingo Philipp and Eran Kinsbruner

Two of the industry’s leading evangelists recently sat down to chat about DevOps, Continuous Testing, and the evolving role of the software tester. Here are a few highlights:

Driving Change at the Enterprise Level

Ingo: So how do you drive changes at the enterprise level? You have several departments, and they are still siloed to some degree in those departments. Usually you have a lot of independent or dependent product teams. How do you handle the way all those teams make use of practices, make use of tools? What’s the best way to manage that huge process?

Eran: That’s one of the biggest challenges, because different teams will use different processes and different technologies. Mature enterprises that are able to figure out the glue between people, process, technology across different silos are very advanced in their DevOps pipelines and software releases. When they are still working in silos, then when you are trying to integrate different software from different products, things break.

Ingo: Yeah.

Eran: When things are being integrated at once, and not in a very synchronized way between different silos, things break…and this is what blocks DevOps maturity. An enterprise that I’m working with has a software automation architect that oversees the entire software pipeline. He’s responsible for looking at the technology that serves the entire organization. He sees technology as a freeway. On a freeway, you have cars that are moving fast and slow, but you have some toll roads. He’s mixing and matching technology—open source free tools and tools that you need to pay for. But, at the end of the day, they all work together, under one framework, that can serve the enterprise. That’s when people process technology come together, into one software release.

Ingo: I like that. I love that analogy of the freeway. So the toll stations—that, tells me you also need governance to some degree in order to keep it going, to keep the flow of your product delivery at the end of the day?

Eran: Definitely. Governance, software updates, feature requests as well. Each individual will have his own unique requirements, so definitely governance. Enterprises are very good at governance, in general. They need to also govern the software testing mechanism. Even if it’s open source, it still requires some governance.

Maintaining DevOps Culture

Ingo: DevOps for me is a cultural movement. I think that was also the reason why the movement was created by Patrick Debois back in late 2007, early 2008 or something? He did it by saying where we are right now, just sucks because of all those mismatches and misconceptions between all those people along the whole CD and CI pipeline. Then he mentioned multiple times that creating a healthy corporate culture including development, testing, business, and operations is hard, but maintaining the culture is even harder. Do you have any suggestions on how to do that?

Eran: Definitely, it’s a hard challenge. Maybe in my third book, I can address it, but obviously maintaining software, culture, people, technology…all of this is a very hard thing to do, especially in today’s digital transformation. We see plenty of new technologies coming up: AI, machine learning, etc. Maybe we’ll see even specific roles being introduced into the DevOps world that are all about maintaining and maybe keeping up and even growing existing skills. I think today, and that’s at least my personal opinion, DevOps today is a very precious goal, and an objective for many organizations, but it’s very hard for them to reach the goal.

I think it goes back to the people…to the skill set, to the mindset. A few years ago, there was the digital officer role, etc. Maybe we can think of some DevOps role which is all about keeping up, maintaining, measuring, applying continuous testing, continuous improvement within the entire organization, working and matching between silos within these teams. I think there is a missing role, in my mind today, that kind of addresses all these tough questions that we are seeing today, the things that actually blocks the entire software release velocity.

Ingo: Absolutely. I see it once in a while. You have those DevOps engineers, really DevOps teams, managing the practices, managing the tools, giving guidance to these teams—not just for continuous testing, but also for development. So I absolutely see that point.

The Evolving Test Automation Skill Set

Ingo: Now you mentioned the skill set: the tester, developers, every person needs to adapt to the change. It is often said that we need to rethink, we need to reconsider, re-engineer, especially software testing. How do you see the future role of software testing in those fast-paced development environments?

Eran: I think that’s a wonderful question. I’m attending many conferences where I speak with practitioners, and we’ve seen the evolution of software test on automation test engineers, software developers in test. Today DevOps teams are doing testing, they are very responsible. Everyone is responsible for testing.

Ingo: Yeah we all have the same finish line. Right?

Eran: Exactly. Everyone wants to release software in the highest quality possible. I think that today software testers have the biggest opportunity, compared to developers. Developers are developers, and they are very prestigious and they have very important goals. So  testers, in today’s DevOps world, have a bigger opportunity to grow their skills, to grow their importance. Especially when you see things such as machine learning and artificial intelligence. Smart testing, smart reporting, smart analytics in the digital era of mobile web, IoT, these kinds of technologies. I think if today’s testers, test automation developers will embrace the new machine learning technology, see how they can leverage existing tools, open source solutions. See what’s broken and try to leverage these new trends on machine learning, etc., and bring a new layer of smart … I’d say advanced… capabilities on top of these open source tools or even commercial tools. I think it will make them the new champions in the DevOps team. And the developers, by the way, will not report to them but will definitely honor them in a much greater way.

Ingo: I really like that. So you are essentially talking about some kind of data-driven approach to testing. We are heavily influenced by data from production or by data regarding your CI and CD pipeline or all the artifacts you have in your test case portfolio. Basically, you have those machine learning or algorithms or AI in general that helps you to improve your testing, in an incremental way.

Angie Jones and the True Purpose of Testing

Ingo: Angie Jones once said in that when technology advances, our testing approaches also need to advance.

Eran: Yep

Ingo: But she always says to go back to the basics. and remind yourself about the essentials, about software testing. You are basically an information service, to provide technical information about the risks to your developers to your product. These people can then make their business decisions, shipping decisions. You’re saying data and the data-driven approach that is what accelerates that process?

Eran: Definitely. Love Angie Jones. She has plenty of great ideas and curiosity. A good tester is a very curious one, one that always searches for the unknowns. Because what’s known—all the green passing tests—we take them for granted. We are looking for the red. We are looking for how to break software.  Always, as testers, we need to find new ways to address how a user would try to use the software. You need to always try to use the software the same way.

Ingo: That’s a good point, addressing the user. So, as a tester, you really need to know for whom you are building your product. You need to know your stakeholders. And as also, sometimes, I see testers lacking that information, not even trying to grab that information. It’s so important because the reason why we create software is to solve the problems of our customers. Our software is just a solution to their problems and that’s all there is. If the problem isn’t solved by our software, then the product doesn’t work.