Application Patching and DevOps Code Testing – Sune Engsig, Leapwork

This is Textron TV. Hey guys. Thanks for the throw.

We're here with TuneIn NC who's vice president of product management for leapwork. And we're talking about testing in the lack thereof, especially as we're starting to deliver more and more patches into the software supply chain to deal with all the issues that have been outlined as a result of security issues and Technical debt and all the things that go along with that and it turns out to be a bigger headache than we ever thought soon. Hey, welcome to the show.

Thank you. Glad to be here. What is the fundamental problem because it seems like we have this insurmountable amount of technical debt that we're trying to address and yet we're building and putting out these patches and we're not necessarily maybe doing everything.

We should with those things in terms of making sure that the patch or the Cure isn't worse than the disease, right? Absolutely, and you're going to thank you Mike her pleasure for it for being here. Just if I'm ages briefly introduce myself and and leapwork.

So we are a no-code test automation company focusing on all of those skilled and experienced testers out there who can't do any coding and enabling them to contribute into the automation agenda. So getting to the answer to your question what what gives what's what's really going on? Well what we can see is that and obviously we've done this risk radar research.

and from that understanding that really 85% of us CEOs thing, you know, they've gotten to a point where where they're accepting and then we can always discuss how voluntary that is, but where they're accepting to to release software that hasn't been probably tested and obviously on as long as it's it's been, you know patched later on but but as we all know Some of these since some of these incidents or issues resulting from faulty software can be very impactful indeed. So it's it's quite the contrast that we seeing there and I guess the interesting part of that conversation is why are they finding themselves in a position where they need to to make these dispositions? Well, let's jump into that because are they making a conscious choice or is it just kind of the back end of a fall out of a process that someone flawed?

Well, I think maybe it's a bit of both. It's conscious in the way that most organizations indeed. They do some sort of risk assessment.

Right? But it's like it's like, you know drawing out an insurance policy of sorts in terms of saying right. I'm I'm betting on these and these and these events and then I'm going to try and cover myself for those and then of course Mayhem begins when when the event that occurs is is not feeling into that pattern and thus comes these unexpected events or behaviors in their production systems.

And of course it again goes back to the fact that you know, the the plate of the CEO and and the CEOs QA department is is ever growing and the stuff that they need to cater for and care for I think you said seeing that beautiful in terms of saying all the stuff be it maintaining Legacy architecture and applications be it adopting to new glor. Trends and tendencies in the marketplace, etc. Etc.

It just leads to you know, a continuous and growing effort when it comes to ensuring the overall business continuity across if you are a fair Global Enterprise, you know, we easily talking across thousands of systems. So how do you cater for that as as an organization? And obviously you can't do that without doing some sort of prioritization based on risk assessment, right?

And then the the challenge if becomes then apparent if yeah, I have risk assessment here, but I still I'm still on to Staffing. I'm still under investing in QA. to my best convince, you know, but best observations is that you know, a lot of organizations are not really sort of on terms with just how much effort and investment that needs to go into QA.

We hear all the time that testing and QA is going to ship left and developers are gonna take more responsibility for the testing yet. The it's not clear to me that they know how to build tests. It's not clear to me that they even know what the test results are telling them.

So once your sense of where we are in that conversation and you know, who should be doing the testing where and when Um, well, I certainly I certainly buy into the concept of you know, the stuff that developers do in talking about shift left. You know the more that they can qualify and and validate the better, but what we also need to understand is no developers are sitting in in a context where they typically oversee the full scope of the application or the solution that they're working on. Typically each of these developers are working on their little piece of apostle really and and while they may be in a position where they can validate, you know their own piece of the parcel maybe also the neighboring ones those full complex and advanced Solutions out there requires a much more holistic approach to to Quality and to the definition of what good looks like and at least in my experience most developers are more engaged as they should be more engaged in, you know, driving great code and solving complex problems and making cool Solutions, which is I think On the immediate level more important to them really than the resulting QA not least because you know, it's further down the pipe compared to where they're sitting, right?

And I basically, you know, I really do believe that the whole shift left thing while certainly a relevant push towards driving quality at the atomic layer, if you will and addressing frequency and addressing. This is something that we need to do all the time, you know, all those things are good, but the idea that it will alleviate or remove the need for doing comprehensive end-to-end testing from the user's perspective I think is faulty essentially. There's a lot of people who are trying to figure out how to integrate testers into their devops processes and you noticed early on that.

A lot of those testers are not programmers per se so they're not very comfortable with something like a CLI, but how do we integrate testers who are not programmers into a devops workflow? We need to figure out a way to to enable these testers because I absolutely agree on your perspective on this and we need to figure out a way to enable these testers to contribute effectively to the task that needs to be solved which is to drive automation. Now in my experience the conversation about facilitating and driving automation has been a an entirely it driven agenda.

So you've had developers sort of being challenged with. Hey guys, we need automation how you're going to solve this and obviously their response is going to be yeah, we're gonna build some code. So I'm gonna build some code sitting right next to the other piece of code that will automate that piece of code and everyone will be happy.

The problem is that I guess this is what also one of the main drivers why automation is still despite of this approach being going on for decades is still at a lackluster coverage. I mean, it's only like 15% of Enterprise scope worldwide. According to Captain Gemini that's been automated at this point.

And one of the reasons for that of course is that we're running out of Developers. Um and that you know, they are busy doing other and greater things than automating, you know us and this is a ever running technol right QA scope. It just goes on and on and on so it's literally it's like painting the the Golden Gate Bridge right when you're done in the one and you start in the other one and it's it never stops.

And and on the other hand we have this great Paradox of having all these skilled qualified testers super good at what they do understanding requirements understanding how to map this to test case is creating that meaningful context and it and execute on that and and then having them being restricted from this automation agenda due to that code barrier. So long story short. We need to figure out how to remove that language barrier and we need to figure out how can we enable these people to tell a machine what to do?

in other words, how do we enable these these qualified testers to to drive full-fledged automation automation that will fit seamlessly into the CLI into the pipeline and and deliver on that concept and that Prospect of automation within QA but without having us to You know forcing us to dive into this whole right? We need to have a fully enabled developers Department in my QA organization. It's it's not gonna fly.

Have we got the right focus when it comes to security we talked about patches. It seems like we're talking a lot about devset jobs and we want to maybe hire security engineers and add them to the whole processing yet. We already have this quality assurance process.

So maybe are we Thinking about this incorrectly and we should be thinking more about how security becomes part of the QA process. Well, I would like to attack that even sooner and say security needs to be part of the design. If you are not incorporating that entirely into your design both functionally and non-functionally, you're a bit late into the game when you get to to QA, at least that's my belief and so But it just it just, you know covering all of those variations and combinations of issues that you might encounter both from the functional Qi gui-driven perspective or is it it's in the non-functional code-based department.

It will require massive amounts of testing and it requires testing to an extent that is completely out of bounds for most organizations because you know, just getting them to that point of being able to execute tests on that scale for each release whilst at the same time on the other side of the fence, you know, promoting an agile where work which when which means that you trigger new functionality into your Into infrastructure on a on a scale which you know, just five or ten years back was was unheard of, you know, all of those things adds up and and they just drives into the point that we need to get to that automation context where these functions features capabilities requirements can be addressed. And and convert it if you will into an automated Cadence as quickly as possible and again in my world that pretty much rules out, you know a code only based approach at least. We all start out with the best of intention somebody puts a project together.

There's always time at the perhaps and maybe middle somewhere along the line for testing and yet we probably moves along in the first thing that gets cut is the testing. So yeah, we kind of ensure that the testing doesn't just kind of Fall by the wayside. That's a good question.

That is the nature of the Beast right? So so you have a lot of moving parts and a lot of Fairly flexible deadlines in a project except when it goes live and then as you approach that and and there's two weeks left and testing still hasn't begun. You know, what do you do?

So I absolutely agree and how do we take care of that? I think one of the important messages I was talking about previously in terms of investing into quality in investing through that into automated quality. It's a different regime and it's a regime for CEOs and CEOs to sort of say okay guys enough now, we've spent the last 10 15 years promoting and implementing agile.

And we are scraping by when it comes to testing and quality most organizations I talk to well. Yeah, they're super proud with having this edge of framework up and running and then they still have this sort of a brick wall manual testing approach where you can create functionality pretty fast, but then you still have a six-week like deployment cycle to actually put it into production. So which is, you know, removing a lot of that momentum that they were aiming for long story short.

We need to we need to invest into QA these organizations need to embrace the fact that the ambition and the capability that they've developed for themselves again over the last decades fueled not least by all this digital transformation, which is really putting a lot of CEOs and CEOs on the spot having that running without Some sort of of armament on the testing and and the quality side. That's that's going to put them into into worse situations then some of them have already experienced and and I think it's one of the key points also from our research that it's one of the things that that the the CEOs are saying that yeah, they have relying on manual and they've underested under invested in in kuwa in general and in automation. It's you know in particular and Be some of those challenges coming out of these organizations because they've gone beyond a conversation of yeah.

I've done a risk analysis. It's risk analysis plus bare minimum plus. What can I hopefully achieve in a time frame that is reduced and reduced due to that problem that you described earlier.

Right. So once you're best advice to folks given everything that we're looking at today and the issues around quality and testing and we have this massive amount of technical debt. It's easy just to throw up your hands.

It is and obviously don't do that Embrace this this agenda of automation coming from another perspective than the the code driven it based approach. Start looking into how can we utilize those resources that we have in our organization those resources that are actually capable of doing like 80% of the task. In fact, you could argue they have the most important knowledge to solve the work of QA because they understand the requirements and they understand how to convert those requirements into tests.

Now wouldn't it be great if we can just have automation coming out of these guys and then having them working closely together with the developers in this tightly knit scheme that will fit into that automated pipeline without compromising on maintainability scalability stability predictability of your Automation in QA because obviously those are fundamentals that you need to obtain for your durable automation solution. So have you know have an open mind when you get into that conversation that there is actually you know, there is a world out there Beyond coding. All right, folks testing is not always gotten their respective deserves, but it's clearly going to be front and center going into 2023 and Beyond because we have so much stuff to fix.

It's just not funny student. Thanks for being on the show. But Asia, thanks for having me.

All right back to you guys in the studio.