Unlocking Rapid Delivery - perspective of a shift from DevOps to QAOps

Thank God I have a microphone, because fun fact about me, I speak really slowly, so microphones are the best thing that happen after QAOPS framework.

Slide. Good. Nice. So, I'm Marcella. I'm an engineering manager, and I just turned 14 years in outsourcing. I'm much older than that. My whole experience is in outsourcing. My background is in quality assurance, and this presentation is not about me, obviously. It's about QAOPS.

Please raise your hand if you heard before about QAOPS. Okay. And about QA, that was my second joke. Thank you. I have so good jokes that I need to mention them. So, I'm really happy that I'm not forced to start this presentation with showcasing the QA value, because, believe it or not, there are still clients out there that they need to showcase the QA value. They need presentation about the QA and what's the value and things like that. So, I'm very happy I'm not starting with this today.

So, we're going to start with definition of QAOPS. It refers to maintaining software quality by approaching you with DevOps mindset. About this DevOps mindset, we're going to talk today, because this is actually the key to the whole, this approach in DevOps. For application development, actually, the key here is about collaboration, right? Development teams and operation teams are working in complete synergy, right? So, DevOps, it's more like an inclusive approach. The backbone of the DevOps approach is actually the CICD, which I'm not going to explain how it works. I have here, I think, a characteristic image of how it works, but usually when you build an application and you release its first version, after the initial release, you may think that some, or maybe a lot of things could have been done better, right?

So, you start working on implementing changes. You start working on doing a lot of improvements. Continuous integration is actually the practice of integrating the whole, these new changes into the main branch, right? So, after integrating these to the new branch, you will start automating, you will start automating so you can check the functionality. After that, you don't have to wait for the new release date to merge those changes. You can do that very, very quickly. You can update them through this process. Continuous delivery is actually the next step after continuous integration, after continuous integration.

And it's about making all the changes available to the customers, increasing in this way the customer's satisfaction. Maybe there are some of you that think that this QAOps is just another buzz word and it has no meaning. Why is that? It's still DevOps, but it's just another reinvented word. So, I highlighted here what I believe is the most important in terms of comparing those terms.

So, in DevOps, focus is more on deploying software quickly. So, this is the quick, while in QAOps focus is more on ensuring the quality of the software. Here we have some concepts. First of it, shift left testing. QAOps advocates this so-called shift left testing, meaning that you need to start testing as soon as possible, so early in the stages. Why is that? Because we all know that having testing early in the development process will reduce the cost of fixing the bugs after releasing the application. Collaboration and communication. Also, QAOps is a great advocate for collaboration and communication, fostering shared responsibility. This is also a key concept, shared responsibility between teams. And this also increases finding issues really early in the process. Continuous testing. Like I mentioned before, this is done through the CI-CD pipeline. Automation is actually the core of the QAOps approach. And continuous monitoring. This refers to monitoring the application actually in production. And in this way, you will find performance issues or even user experience-related issues in real time.

Let's talk a bit about principles and best practices. So, culture of quality. This is really important. You need to establish a culture of quality. And again, like I mentioned before, shared responsibility for software quality among all team members. So quality is not about QA engineers. I believe it's a shared responsibility. Test early and test often, like I said, like I mentioned before. Begin testing as soon as possible in the development process. Automate everything, but do not automate everything.

Everything that is possible. So focus on automating repetitive tasks, including test, risk creation, execution, and reporting.

Continuous feedback loop. You need to promote cross-functional collaboration to leverage the skills of all team members for obviously quality improvement. Cross-functional testing. Testing teams. Encourage continuous feedbacks and improvement of feedback, communication and retrospective. Pretty sure there are many of us that don't like retrospective, but believe me, they are really important.

I believe, which is my personal belief, that the best candidates for having or for implementing this QAOps approach are the startups. And I want to take the opportunity and mention about a Romanian startup, which is called TimeWorks, and their mission is building the leading data processing platform to make your time work for you. Because time is money, right? Why are they early adopters? Well, their main goal is obviously their product, but their product quality. So they are early adopters of this QAOps approach by fostering a good collaboration between their teams. Started to integrate everything they do, continuing with... starting with repetitive tasks, continuing with their testing types that they are doing, like unit testing, integration testing, and so on. And then they are fostering good collaboration between them and their small community they are building it. So they're paying a lot more attention to what the customers need, their user needs, and so forth. Good.

Speaking about the implementation steps, I can tell you that they're not... this is not easy. So it's just like in life, you need the right tools and you really need the right weight, right? So selecting the right tools, this can be quite challenging because you may think that it's better to have for QA... from a QA perspective, just to have an automation framework that is useful for UI and another one for back-end testing. But actually, you may have to think that you will double your work in terms of maintenance. So keeping always in mind, what's the goal? Goal is the product and the quality of it. Next, integrating with DevOps pipelines. This is all about integration of automation into the CI-CD pipeline. This will ensure continuous testing and faster feedback. Defining test automation strategy. This is also important to have a good test automation strategy in order to resource sorts of testing that you need to do for your product. Test data management. You need to ensure that you have proper test data management to create in this way realistic testing scenarios and obviously to avoid data-related issues.

And continuous monitoring and reporting. This is also to track the performance and identify quality issues. There are many challenges, but I highlighted here just a few of them, which I believe that there are the most important ones.

Cultural shift. I believe that fostering a culture of collaboration may be challenging. This is not only challenging for bigger companies, but also for the startups or for the smaller companies.

Tool integration. You may want to integrate everything, but you may think that this will require effort and expertise and you may not have it. So this is a really big challenge.

And last but not least, skill gaps. This is all about training, training, and again, training. If challenges are accepted, then QAOps also have some benefits. First of this list of benefits is reducing time to migrate, which I believe is really, really important. Higher software quality. Collaboration and communication. I think I mentioned this a lot in my presentation, but this can also foster a positive working environment. I know that we as developers and maybe as engineers in general, we don't like to collaborate more. We just want to lock up in a room and create our own piece of code and that's it. But this is not about having a lot of meetings. This is about processes and about better collaboration. Cost savings. Early defect detection and automation can reduce the costs of fixing the defect and continuous improvement. This leads to continuous improvement in processes and products. Just to conclude, the shift to QAOps is not just a methodology change. It's more just like a strategic move to unlocking rapid and high quality software delivery. I believe that QAOps will leverage AI and machine learning for intelligent test case generation, advanced monitoring, and so on. I believe that this will lead to some sorts of guidelines in terms of software development processes and that AI-driven insights will help teams make informed decisions and more important, optimize testing effort. Good. Thank you. We only have a few minutes, so I'm going to go ahead and get started.

The first question is, what are the tricks or do you have... Could I just get the questions popped up here? Thank you. What are the tricks or tips to establish a quality mindset in the organization, not only among QAs? Yeah, this is a really good question. When it comes to mindset, it's all about educate people. Like I mentioned before, my whole experience is in outsourcing, and there are three types of clients. One, the client that wants an application from scratch and that he doesn't force you to use any tools, so you have the full autonomy to choose the right tools. Second, start from scratch an application, but they are forcing you to use their tools, let's say, they're forcing to use an automation framework just because of reasons. And the third sort of clients are the ones that are having already an application going, and they need to outsource resources and help them with the process. It's very hard for all those three types of clients, because if you already entered in an existing team, you will need to change the whole mindset, the whole processes and everything. If you're starting from scratch with your own team, it will be much easier, but if you're starting from scratch with their team, it will also be challenging. So, just to conclude here, it's all about educating people and team members. And this takes time. You need to invest. Trainings, trainings. So that's great if you have leadership that buys into the need for that training. Do you have any tips for where you don't necessarily have that buy-in, but in order for this discipline to be successful, you need to be able to enact this, this training, this education? I don't think you need to force anything. You can start. And if they don't want, I don't believe that forcing people to do trainings or do whatever, I think is good. It's not the best practice. Thank you.

So, the next question we have, wow, we have so many questions coming in. This is wonderful. Thank you, everyone. So, the next most upvoted question is this.

So, QA Ops would be a new role? I think this is more in a inquisitive type of question. So, QA Ops would be a new role in Dev Teams, or is it just the name for a more active QA involvement in the development process? That's again a really good question. Fun fact, I've seen on LinkedIn that there are a lot of new job titles like DevOps QA or Release Manager, and their description was all about this QA Ops framework. So, they needed more like a DevOps engineer to do also some quality assurance work in a release management environment. This is not actually a role. QA Ops, it's just a framework. And I believe it never meant to be a role, but companies due to this trendy trend, they use it for fancy functions, roles. Trendy trends being the technical term, of course. Yeah, yeah, yeah, yeah.

So, this is a kind of adjacent question to that one. So, on a glance, it looks like QA Ops is involved throughout the delivery process. So, does that mean it has to be a jack of all trades? Like what are the specific skills required to be a QA Ops practitioner? I believe that QA role had come to an evolution. When I started back in 2009, I started as a manual QA, and I was only doing manual work. Then I transitioned into automation, and then into leadership and management. I believe that that sort of quality control work that we used to do back in the days, this is not what QA means today. So, in terms of skills, I believe that you don't have to necessarily know automation to work in a QA Ops approach, but that would be nice to have. But I don't think it's necessary. You can hire people that know automation if you have resources and money. But you need to understand the whole CICD integration process, and you need to know the product. This whole approach is about knowing the product and how to speed up the development. So you need to be involved in all those, let's say, activities that we don't want to be involved, like grooming, planning, and I've seen a lot of teams and a lot of people that were saying that QA has nothing to do with development, planning and grooming and so on, but this is actually important. So, just to conclude, because I'm speaking a lot and I'm not going to every point, I believe that you need to have some DevOps skills, but not only. You need to have also communication skills, or soft skills, and also to know the industry that you are working, the product. This is really important. In order, okay, for the tech part, obviously you also need to know automation. Yeah, it does sound a little bit more like jack of all trades.

I mean, obviously, forget the master of none for a moment. Yeah, it sounds like, as you say, DevOps plus an additional set of skills. Yeah. Interesting.

This next one is a question which I don't think we were ever going to avoid because it seems to be the theme of every tech conference in this current moment. Are you using AI for any of your testing activities? If so, how? If not, why not? That would be interesting too.

Me and my team are actually working to a new platform, AI platform for testing. There are a lot of them on the market. You can generate test cases. You can log issues automatically. You can integrate test management tools with CI, CD pipelines and so on. But our goal is to have completely new AI testing platform that could be customized for every client needs. Sure. Maybe I'm from another world because I only work in outsourcing and maybe in product things are going different. But you may ask why we're doing this from scratch and not using the tools that are already on the market. And I say that the clients are very different with different needs. And we believe that this is the best thing to do. So this is actually an ongoing process.

I also use GPTA like many of you, I believe, and Copilot. But I don't think this can replace the humans. It's just for having more, like productive way of working, helping. And that very much echoes some of the things that have already been said today. Olga's talk earlier was very much coming up, if you're remote, spoilers. There are elements of, yes, it can help you be more efficient. It will not do the work for you. Or, I mean, it could do the work for you and probably quite poorly. So it's about augmenting your practice, especially the menial repetitive work to allow you to be more efficient, not remove the work entirely.

I have one other question. It's been asked in a few different ways. What kind of training do you think people need? We spoke about the need for training and education, but more specifically, do you have any suggestions on what kind of training teams will need? Well, it depends on the product and what you are developing.

It depends on the teams and their skills and what they need to improve. Maybe you have a team full of automation engineers, so you just have to work on training them how to use Jenkins or other CI, CD pipelines. So it depends on the team, on the product, it depends. It's mostly technical trainings that you can do, but not only technical. You need to also, like I mentioned before, you need to be a very good communicator and to step in when needed.

Yeah, fascinating. Thank you very much. So just a reminder, once again, we have, there are still more questions and we're out of time to ask them right here on the stage. There is a speaker Q&A section around by the front. And if you're online, you can get to it from the timeline to continue asking more questions.

Please join me in giving a massive round of applause. Then we're going to take a short break or ability to move rooms. So a few minutes before the next talk begins, but let's not skimp on the round of applause. Please join me.