From Testing to DevOps – A Career Move That Makes Sense

Maciek, a senior DevOps manager who started in test automation, talks through why testers should consider moving into DevOps. He covers how the two roles are converging, what AI changes about testing work, and what skills actually transfer between them.
Hey, are you looking to move from testing to DevOps? If so, this episode is for you. We have an awesome guest joining us. It's been almost eight years, I guess nine years since he was on last. We have Maciek. He's a senior DevOps manager at an AI driven test automation platform with over a decade of experience driving software quality and delivery speed. He is passionate about SRE DevOps best practices and continuous learning. He's been on the joined us as a speaker for one of our automation guilds as well. So I'm really excited to get his perspective of why he made this move. And I'm sure a lot of people have been thinking this as well. Should they move from testing to DevOps and what it takes if that's you like again, you want to wait all the way to the end to find out as well. You don't want to miss this episode. Check it out. Hey, before we get into this episode, I want to quickly talk about the silent killer of most DevOps efforts. That is poor user experience. If your app is slow, it's worse than your typical bug. It's frustrating and in my experience and many others I talk to on this podcast, I frustrated users don't last long. But since slow performance is as sudden, it's hard for standard error monitoring tools to catch. And that's why I really dig SmartBear's Insight Hub. It's an all in one observability solution that offers front end performance monitoring and distributed tracing. Your developers can easily detect, fix and prevent performance bottlenecks before it affects your users. Sounds cool, right? Don't rely anymore on frustrated user feedback. But I always say try it for yourself. Go to smartbear.com or use our special link down below and try it for free. No credit card required. Hey, welcome back to the guild.
Thanks. Thanks for having me. It's a pleasure and an honor to be back. As you said, we've had a long history together. It's been kind of subsurface for a bit, but here we are. So thanks for having me on.
Yeah, you just opened up another memory pocket. I think you joined me to do a session on White. The White framework, correct? Yeah.
Yeah, that was one session. Yeah, that was when I was exploring a lot of different test automation frameworks. And that one was interesting to me because if I remember correctly, it utilized the desktop in a good way, which is at that time what I was really lacking from a lot of test automation frameworks. So that's why I use that. And it was a Blip in my career for sure. But a memorable one.
Absolutely. Nice. So I mean, last time we spoke you were knee deep, feet first, I guess into functional automation. Maybe a little bit about your journey. Why moving from testing to the world of DevOps? What happened? What was the moment that made you do this?
Yeah, it was, it was a bit of a natural progression, to be honest. I never really meant to let go and testing and if I'm being honest, it still has a near and dear, you know, kind of like part of my heart. But what really happened is an evolution of what I was doing and I was really pushed along the way due to the shift left movement.
Right.
So I know this is still a thing in the industry that we talk about all the time, moving testing closer to the development team, moving testing closer to the developers. And that's kind of what I did. Right. I went from being a tester that was essentially helping teams to test. Then I became a little bit more of a senior tester that helped teams, that advised teams how to test. Then I moved into a quality architecture position which was advising an enterprise how to test. And then as I started advising teams more directly, I started noticing that enterprises were really focusing on training their testers to be more aligned with the development practices, which meant that they were either developing tests as first class citizens or starting to develop code and tests at the same time, which really helped the enterprise that I worked for. Rocket Mortgage or yeah, Rocket Mortgage, still it's called rocketmortgage now it's called Rocket. But you know, that enterprise really focused on providing value from testers by utilizing their skills that they learned as test automation engineers in coding. So I all of a sudden found myself looking and advising folks who were asking me development type questions. And so what the problems I started solving for them really focused around automating their development quality related questions, which led me into the world of things like pipelines. And so from pipelines I started noticing that there was a trend of needing help with that aspect. So I started looking at Jenkins, I started looking at CircleCI, Azure DevOps. I don't know if it's called Azure DevOps anymore, but that really led me into that world. And as I started looking at pipelines, I also started looking at, well, how can I essentially ensure that the pipelines are behaving like I want them to and that the applications that are being rolled out by the pipelines are reaching the state that it is expected of them? Which led me into observability. So a little bit away from Testing. But you could see where I'm leading with this, right? So once I got into the world of observability, I was like, holy cow. Grafana.
Right.
For example. And so that's where I started really focusing on the DevOps perspectives, and I started being exposed to DevOps principles, SRE principles. And from there, it was just one thing that as I. As, you know, you said we last talked 10 years ago in my life, there have been many, many life changes in the last 10 years, specifically three little ones that now ask me to change diapers and, you know, do all sorts of things that require my time and energy. So I. I'm glad that I aligned my change in energy output to the different stages in life. Right? So I learned a lot before I had. I had to be involved with my kids. I had to. I love being involved with my kids. You know, I am involved with my kids. But before, essentially before, there was a different set of an energy that I had to expand outside of work, and I learned a lot there. And I kept my blinders off and expose myself to DevOps, expose myself to anything that anyone threw at me. And then I realized when I had my first kid that, like, the amount of energy I have after. After work or after hours has drastically been slashed, which is a stage in life. It's neither bad nor good, but it is a stage in life, right? So I think the tip I have for people trying to make this switch that, like, I realized is you got it. You got to pick the right time. And sometimes it's okay to, you know, say, this is perfectly. I'm. I'm good at where I'm at, and it's good to stay here, but as soon as you feel that urge, you can. You can make the jump, right? So from a blinder's perspective, it's. It's good to be good at what you do. It's good to have a niche.
Right?
It's good to focus on one thing at a time. But it is also good to open up your horizon and know when you should make that switch or when you shouldn't make that switch. And that's kind of like the thing that I learned over the last 10 years is, like, I had the opportunity and I took it, and I learned a lot. I. I took some risks. I went from maybe, maybe. Maybe this is. It's worked out so far for me, but maybe it won't in the future. But, you know, I went from working to. To the second largest independent mortgage provider in the United States to a Series A startup to a series B startup. So like, scary, you know, but, but the opportunities at smaller companies to advance into, into different, into, into a place where you have to wear many hats and learn is, is very, very lucrative and nice. So the tip is it's fine to have. Let's. I have an analogy. It's fine to have sunglasses on, not blinders. Right. So you're not blinded by everything coming at you at once and you can focus, but sometimes it's okay to kind of like look into the sunset and see what's ahead.
Love it. Love it. I'm gonna use that for the title. So I guess what's kind of tripping me up, maybe I'm wrong. Is it functioneyes, a automation company, Testing company. So you're doing. So you were in automation, you moved to DevOps and then you moved to a company doing DevOps for a functional automation company. Am I getting that right? Let's see.
Yeah. One of the big reasons I moved to functionize is because of the subject matter expertise. Like, I couldn't think of a better place to scratch my automation itch and provide value to the company as a whole on a strategic level through my experience and still learn a lot of DevOps stuff and be able to kind of like lean into the, the stuff that I'm currently doing.
Right.
Because at this sort of company, you know, I, I'm, I'm very comfortable in conversations dealing with what the tester needs or what the tester has felt or how it fields to, you know, to run test automation or build test automation. And it's very interesting because we are using AI for the bulk of our, you know, we have, we have tools for. The company sells tools to generate tests via AI. So it's, it's very, very interesting from like a perspective of, of the client, because I used to be the client.
Right.
So when we talk about products, I'm like, ah, yeah, I've done this before. You know, I know what Cypress is. Oh, I know what Playwright is. Like, you know, these are our competitors. So it's nice to be there but also be focused on the DevOps perspective for that company. So it's almost like I'm using my background to drive forward my future.
So what do you think? If someone's in DevOps and they've never dealt with a testing team before, what does a tester need from.
So from a DevOps perspective.
Yeah. So if you're a DevOps and you need to get them into the pipeline, no one knows how to do it, they don't necessarily know the functional testing background of automation that you do. Do they need to know certain things or have in place certain things in order for it to work really well?
I think the relationship between testers and DevOps is, in my opinion, it's similar to a developer and DevOps. Right, so like DevOps and testers can. And I've been on both sides now.
Right.
So I was a tester and I worked very closely with DevOps team. Yeah, I've done this before. You know, I know what Cypress is. Oh, I know what playwright is like. You know, these are our competitors. So it's nice to be there, but also be focused on the DevOps perspective for that company. So it's almost like I'm using my background to drive forward my future.
So what do you think? If someone's in DevOps and they've never dealt with a testing team before, what does a tester need from.
So from a DevOps perspective.
Yeah. So if you're a DevOps and you need to get them into the pipeline, no one knows how to do it. They don't necessarily know the functional testing background of automation that you do. Do they need to know certain things or have in place certain things in order to retail work really well, I.
Think, you know, the, the relationship between testers and DevOps is, in my opinion, it's similar to a developer and, and, and DevOps. Right. So like DevOps and testers can. And I, I've, I've, I've been on both sides now.
Right.
So I was a tester and I worked very closely with DevOps teams and I'm DevOps and I, and I still work closely with testing teams, but I look at testers as a different type of developer almost. Right, So a different type of client, but not drastically different. So like a tester's, a tester from a DevOps perspective requires things that allow them to do their job well and efficiently. And from a developer perspective, it's similar, except developers value things like getting their code through the pipeline quickly. Testers value things like making sure that their tests run quickly and provide feedback to them in a way that is easily consumable to them. So I think that the thing that the DevOps team should know about testers and should really focus on is what matters to the tester, what outcomes matter to the tester. Just like what outcomes matter to the developer. The developer might want to ensure that their code is shipped to a specific environment, whereas a tester wants, wants to know that the code was shipped to the environment while satisfying their quality gates, for example.
Right.
So I think it's a partnership and it has to be a partnership between, you know, it's almost like, do you remember the Three Amigos from back in the day? Right. So it's like the modern version of the Three Amigos where you know, your testers provide requirements and DevOps of things that they want to see in the pipeline and developers do the same and then the DevOps folks try and satisfy those requirements and work with both teams to ensure that their expertise is reflected in the pipelines. Right. So that's one piece in the pipeline. I mean, from an observability perspective, one thing that is really interesting that I've noticed is that testers gain a lot of visibility due to the observability that DevOps provides. Right. So while, you know, we have different functions in big corporations like operations, that operations will look at observ, the traditional observability dashboards that look at, you know, let's say the golden signals, like saturation, latency, stuff like that. But nobody necessarily looks at the functional output or like even business dashboards which kind of tell us whether the behavior of the application is what we expect it to be. But testers, our role as a tester is to kind of drive that.
Right?
To ensure that what our requirements are set as are reflected in when the application is built. And so the end part of that journey is to watch when it's rolled into an environment, whether it's staging, production, whatever.
Right.
And so from a Tester perspective, the DevOps person can provide them with a lot of value by showing them or helping them build this type of observability, which may not be traditionally focused on non functional requirements. It may also be right, but it doesn't have to be because we can, as testers, we can ask for things to be customized and observability to be built for custom types of behaviors from the application that we test beforehand and expect to continue to see once the application is shipped. So that's a lot of rambling, I think. But in general, I mean, the partnership between the DevOps teams and the testing teams or the testers themselves, if they're embedded inside of teams, is very fruitful because we can benefit from each other's expertise.
Nice. So in there you did mention the company is AI based. Does that change your DevOps strategy? Like how do you know something that's non deterministic almost to know that it's in the pipeline and it's working correctly? Before you say release it.
Yeah, yeah, it's, it's, it's tough. I think the, the best way, right is again looking at the outcome and we have specific like internal signals that we measure that once they start rising above what we expect. Um, you know, for example, a lot of the AI that, well, the AI that, that we build satisfies a very high rate of element match for the automation framework.
Right?
That's kind of like, that's a bit of our secret sauces. We, we have models that say, okay, your page is loaded. We know this to 99.999% certainty because of the data that we've gathered over seven years. And by comparing the data that we've gathered the seven years over the many different inputs we have to this model, we can tell that the page, therefore it's safe to click on an element. The next model will take over and say, hey, the element that you're looking for traditionally was here. It moved over to here. We think this is the right one. We've seen this many, many times before. Therefore here's your element. Go click on it.
Right.
And so from, because of the data that we gather, it is non deterministic to an extent, but from a different perspective, the percentage chance that it is not going to be matched is relatively low. And so we eat our own dog food, we test our own stuff using our own products. And so we are able to feed our test to our development as it happens and use our shoot the user software to ensure that it is being developed to the best, to the highest of quality. So it's a bit of a loop, a reinforcing loop and it's not perfect, but it's a pretty high rate of confidence.
So if someone's listening and they're a tester, is there small steps they can do to see if this is the right career move for them?
Yeah, definitely I would. So ironically, I have one of our, I just recently had somebody from within our company asked kind of a similar question where they reached out to me and said, you know, like, I'm really interested in this, like what do I do? I think I'm still trying to match them with the proper meetings without fire hosing them. But essentially what I, what I would suggest is maybe start shadowing the DevOps team. There's a lot of great books and resources that will reflect to the people interested in how to make this career change. But at the end of the day it's little tiny steps, but the steps have to be aligned with value. It's one thing to learn something, to experience something without adding value to either your own perspective or the company you work for. Perspective. But if you find an opportunity that nobody else is kind of like fulfilling, that is a small step. Like maybe for example, generating a dashboard, right? Or implementing a standalone Grafana server or launching a Docker based, you know, or launching a Docker based Prometheus server or something like that. Like those little steps that may not be little to some people, I understand that might be daunting. But anything which aligns value that, that your team is asking for and how you can provide it, that would be a good first step. That's kind of how I started doing these things because we started seeing that there were gaps. The one thing to mention in that growth pattern is make sure you identify that you are growing and that you're venturing into something you don't know to your team so there are no surprises. Or the team thinks that you're an expert and if you do make a mistake, you're kind of, you have a backup, you know, you have an established kind of like, I don't want to call it a cya, but it also is just being transparent and honest that you're learning.
So you're also in a unique position once again, as we mentioned, because you're working for a functional automation tool that uses AI. And some testers might be looking into other areas to move into because they're afraid that AI is going to replace them. So for being from the DevOps lens, looking at your testers at a tool that makes AI based testing, should they be worried about their careers that way or do you just see it changing or morphing? What are your thoughts on it?
Yeah, I mean, I will be honest and then kind of recognize and acknowledge the fact that it is scary, right? There's a lot of push into AI and there is a lot of this kind of fear that it is going to replace some testers and replace not just testers, but, you know, developers. There's AI is supposed to take over the world, right? At the end of the day, maybe it will, maybe it won't. The one thing that I've seen that is very true is that you have to find a way to utilize the UI to make your own process either more efficient or faster or better.
Right.
And the AI in AI in general is only as good as the data that it's trained on. And so if you're in a position where you are a tester that knows a lot about the business context of Your subject matter that is a good position to be in. And you can even utilize AI to make that, use it to your advantage.
Right?
For the small tasks like, you know, I use Copilot in, in my development all the time. And I'm, you know, I, I, I'm not, I don't fear that it'll take over what, what I need to do because I understand that the more I use Copilot, the more time I have to contextualize my, my learnings. And that is something that Copilot doesn't have access to learn because it, you know, it doesn't have access to the internals of our application, our business plans, stuff like that. So a human will always be better in my opinion, at judging context, making snap decisions without previous knowledge, intuition, all type of stuff. So it's definitely a nervous world to live in if you've been, you know, performing a task that other people are telling you that is going to be replaced. But it is, it's your choice to either, you know, kind of dive into it and use it to your advantage or, or pretend it's not going to happen.
Right.
And I have no idea if it's going to happen or not. I mean, I work at an AI startup, so I should be telling everybody it's just a matter of time. But at the same time there's a lot of nuance to those discussions. And so it is a scary world. But it's up to you, how do you take that, how you internalize and what you do with it. So I just do it one step at a time and figure out how to use the AI and what it's applicable to it and what it isn't applicable to for your context.
Love it. So with DevOps, obviously are there any hot trends that you're interested in or you see on the horizon? AI. I know AI has impacted everything. I don't know about how it's impacted DevOps, but like MCP servers, does that have anything to do with DevOps, what you're doing? Do you care about that?
So I operate a lot in gcp, so in cloud based technologies in general. And so I've seen AI, you know. So for example, when you log into, as a DevOps person, you log into, you know, a cloud console and right away there is Gemini or you know, whatever the AWS or Azure equivalents are telling you. Click on me and I'll send you a report, I'll show you a report and like, one of the core things that I pay attention to is cloud costs As a manager at a small company and I don't know how many times I've generated a report and been like this is totally not what I expected or want to look at, right? And so it's there. This is Google's AI on Google's cloud platform, right? So there's a lot of stuff which AI is good at, but the contextual pieces that you're, that I sometimes need, it's not that good at yet. So I'd say that the trend there is evolving, but it is not mature enough to be used every single day from a, from a, you know, from, from a perspective of, you know, in the cloud, for example. However, what it is good at, you know, are simple tasks. Like if you ask, I may or may not have done this a few times, but if you ask, you know, ask Chat, GPT or, or Gemini to translate a file that is in a slightly messed up YAML format into a terraform file, it can do that in a second, right? So that type of stuff is what I use AI for to satisfy those like mundane tasks that I'd have to go and do on my own. So that's one trend that I see a lot of my developers, a lot of my DevOps folks doing too. But the things I think which are still hot to us at a startup are things that allow us to see a bigger picture perspective of our infrastructure and our applications in an easy way. And I haven't seen AI be able to do that well yet. A couple other trends which I've seen that I've been bombarded with in the last year or so are cost savings for cloud spend, right? So like automated cluster turnoffs and you know, like downsize and stuff like that. And that again is if you're running a simple environment, if you have, you know, a very vanilla setup, it's pretty good at that. But if you're running a simple environment and you're, you need that type of tweaking, it just means that you haven't done it yourself and I bet you could get it accomplished quickly yourself. Anyway, so, um, anywhere where there's like manual intervention that has been done by a human, there is like a footprint of AI. But I, I, I haven't really seen like a super great success yet. But for the simple things to make your life a little bit easier, you know, like translating test cases or not, not, not test cases, sorry, translating YAML definitions and stuff like that, which could be probably applied to test cases into different frameworks or generating test cases. That's something which we actually do as well. We offer an AI driven test GPT agent to translate test cases from natural language to a functionalized test, which is really cool. So those trends, that type of simple translation, we still have to guide our tests, our framework, in a little bit of a manual way, but it certainly makes the lives of our customers easier and it makes my life easier too. So there is, there is definitely some input from AI, but it's not like if somebody tells you, it's just like it's going to head it out of the park, it's going to take over, you don't need to be here. I think that's, that's a load of baloney.
Absolutely. All right, so pretend you're a DevOps hiring manager. You get a resume from a tester that wants to move into DevOps. What are you looking for? Skills.
Yeah.
Tools.
Yeah.
What pops for you?
I think the thing which naturally I expect from a tester is a high level of curiosity. So that is one thing that I would definitely look for and also what I would look for and I expect from a tester. So in general, when I was a tester, I learned new context all the time.
Right.
In order to be a successful tester, what I had to do is really understand the application I was testing, really understand the team dynamics of who did what and figure out who to go for to write successful test cases and get the proper context. So that sort of learning experience really benefits a DevOps person as well, because the troubleshooting that comes with DevOps is kind of similar to finding out why a test would fail.
Right.
Because you're essentially debugging. So I would look for folks who have a pretty extensive degree of learning, different types of projects, not necessarily different types of or many different industries. The industry aspect is interesting to some people if you're dealing with a lot of, how do I put this? Like, a lot of like laws and different types of certifications, like HIPAA privacy type things. But overall, I think the level of learning and experience, showing a high level of learning is very attractive to me as a DevOps hiring manager. And if I were to be looking at a tester, I think I would look for somebody who was involved, directly involved in a team as opposed to working on a QA team. So that's where like that transition, that's what I did. So based on my experience, that's like near and dear to my heart. Because as a single tester, you get to be exposed to the developers really closely and you start seeing the types of problems running into the types of problems in the testing world that you run into DevOps as well sometimes.
Awesome. Okay, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps efforts? And what's the best way to find or contact you?
So I think the best way to contact me nowadays I'm not as active on X or Twitter as I used to be, so just email me, that's probably the best way. Or add me in LinkedIn and I think you could provide that contact information in the show Notes and the best piece of actionable advice to give to somebody who's looking for to advance our DevOps experience as a tester is start to shift left and try and provide your developers with a little bit more speed and DevOps type questions or answers.
All right, before we wrap it up, remember frustrated users quit apps. Don't rely on bad App store reviews. Use SmartBear's Insight Hub to catch, fix and prevent performance bottlenecks and crashes from affecting your users. Go to smartbear.com or use the link down below and try for free for 14 days. No credit card required. And for links of everything of value we covered in this DevOps Toolchain show, head on over to test guild.com p197 so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation, software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to Collaborate visit test guild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve with lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tests are showing the secrets to behold.










