Open Sourcery: Vanquish Your Open Source Testing Silos – DevOps Unbound Roundtable

Hey everyone. Welcome to another devops Unbound. Live Roundtable Edition.

I'm your co-host Alan shamal CEO of texture on group and welcome. For those of you have not been on one of these before devops I'm bound is a semi-weekly actually by weekly video series. So that means every other week.

We do a episode of devops Unbound and we explore. Just different areas of interest within devops exploring some of the dark nooks and crannies that make up the ever-expanding. It seems devops world.

Every two to three shows. However, we do a special edition like this and devops about where we ask you our audience to join in and not only to join in but to help Drive the show right? We have a great panel lined up for you here today.

But what we talked about to a large extent will be driven by you in the audience by your questions your comments and so forth. I'm gonna go over with you how to interact with our Panel in just a moment as well as today's topic. But before we do that just a couple of things number one big thanks to our friends at chai centers who are the sponsors are done UPS Unbound and have been over two years.

Now that we couldn't do this show without them and they are as I always say one of the best Partners to work with so many thanks to our friends, which I said this. Secondly, these shows are really dependent on the quality of our panels. And we we are blessed always get great people on our panels.

No different today. We have a fantastic panel. I want to introduce you to some of to all of them right now and then we'll move ahead.

Let me start off with semi regularly here on devops. I'm down Adam are R Kelly and if I miss Finance, I apologize. Alright, why don't you introduce yourself to the audience Adam?

Sure sure. Saw that America Killian. I work at a small company called Dell and some of you might have heard of it.

I I'm a senior director there and I work in their infrastructure server group running a devops group and very excited to be here to talk to you all about open source, and how we handle open source and how we can test open source and reduce those testing silos. Allen thank you very much. Thank you Adam pleasure next up.

Let's she's the First Time guest as a panel member here Paloma Oliveira mispronounce. I apologize. Why didn't you help me?

What's perfect? Expectation it is a great pleasure to be here. I am a developer advocated host labs and I I'm focus on open source communities, which I've been inside and contributing in several ways for oh like a decade now and I'm very passionate about the subject.

So I'm join a lot. excellent Next up I want to introduce and I I don't want to mess up as I say, but it's Andreas Andreas helped me with your last name. but Devin Okay.

Yeah, it's a German accent actually French, but later German. Oh, okay interesting on James. Why don't you introduce yourself?

Yeah, thank you so much for having me on the show Allen. I am coming from the tricentecide. I'm a solution architect with tricentus been with a company for about four years primarily focusing on test management and functional test Automation, and I'm excited to be here to talk about these topics.

Excellent, excellent, and then our next or a fourth panelist, right? is Talia and I don't want to mess up your last name either tell you I apologize. How do you pronounce it?

Talia nassy I see tell you what you give us a little bit of your background. Yeah, so I'm a lead developer advocate for Akamai and I work on both back my own out and kind of the integration of the two services and I I previously I was at AWS as as a developer Advocate on the serverless team and before that I was a test engineer so I come from a testing background. excellent What a great panel last but not least is my co-host of devops.

I'm down. He's also CTO here at extra group. My friend Mitch Ashley Mitch.

Why don't you give them your background? I'm also analyst with sexual research and I go way back as a software developer and running product about my teams both on Commercial products and also it organizations. So a lot of time with testings and appreciate the extreme skill and value that they bring and open source our topic today.

So I'll let you talk about that. But by the way, I'm your Ed McMahon to your Johnny Carson. Which you're dating us totally am.

Okay, so guys before I jump into the topic for the day. I just want to principle thank our audience and I see some of you have already logged on and said hello and where you're from and that's always you're ever since I first started getting on the internet in the mid 90s. So he's been something that kind of gets me going as you see that there's people from all over the world right there.

The internet knows no borders and it's no different today. We have people from Berlin in Brazil and New York and here in Florida, Colorado and elsewhere. So feel free to just log on in that chat window.

We call it our Communications window. It's on the right side of the browser for most of you and you'll see under chat public you can type away in there and and it'll show up. But more than just telling us where you're from it offers a key way for folks to interact and actually panelists any questions you may have so feel free to do that.

And as we get jumping into our topic today, that is a primary way for you to talk now when you put it in public chat like that other people may answer your question in chat, maybe some of the panelists too. maybe other you know people who have logged on today anyone can answer. And talk in the chat session.

So you're free to use that if there's a question specifically for the panel though that you'd like us to, you know, kind of raise up. To the to the level of the panel come to the Q&A section of your Communications window. So that's right to the right of where it says chat and anything you type in there will show up not for the everyone logged in but just here for the panel members and we'll we'll raise that up here and and try to answer your questions.

So that's just a quick word on how to interact with us today and we love the interaction. So don't be shy. Today's topic.

It's a great topic right? It's open source, your evanguish your open source, testing silos in the magical world of Open Source. com about eight or nine years ago now and I think one of the big success stories and also one of the big enablers of devops and devops success has been automated open source testing.

You know, there are a lot of doomsayers when I dunlops first started becoming popular that it would signal the end of QA as we know it would signal the end of the test or the professional tester. Nothing could be farther from the truth. We we see testing has flourished like never before in all of its many different flavors.

and and and use cases, but certainly open source testing tools. Open source testing tools tools like a selenium for instance. have enabled testing to really just claim its rightful spot in the development life cycle, right?

It's no longer a thing. We dread that we don't have budget or time for well, maybe we still do but well, I'll let you guys decide but it's something that is now just so much more built in and so the Automation and the and the the breath of Open Source tools that we have in testing has allowed us to do so many different things one may question though, you know, is it a victim of its own success? Right have we done so much?

you know Automation and use that have so many open source tools that we kind of take it for granted or we're not innovating or it's not living up to its promise. Andreas you're with tricentus attesting company. So we're gonna I'm gonna put the onus on you to kick us off on this topic and then ask the panel feel free to jump in.

Sure, I can I can speak for my experience interacting with several customers out there who are adopting open source Technologies or in the process of it. Some of them are in this journey, right? Because the way I see it is that automation is a journey in itself.

It's very hard for a company to say from this point on we're only going to do automation or we're only going to be agile only devops and there's a lot of moving pieces into that process that we really have to put together through to really get there. But really the I think one of the main benefits of Automation in the past few years that is that it's allowed us to scale right back in the day when we were Doing a lot of development in waterfall methodologies. There was a lot of manual testing that used to be fine for the time.

But now that our entire business runs digitally now that we need several applications that were constantly iterating on and are processes are much faster agile and devops move very quickly. And we need to be able to keep up with that pace. So really open source automation comes very handy when we're trying to achieve that level of scale.

I think that it was interesting though what you mentioned that it's automation of victim of its own success and whether it's a we were using it to find an answer to this challenge of scale and being being able to keep up with with their speed. But as we do so and as we add it automation, we do introduce a certain level of complexity right now. We need to have users that are familiar with the Automation and now we also have to manage that automation which becomes a whole process in and of itself.

So I think it's worth maybe exploring that journey and what it really takes you to to get there to really take full advantage of the Automation and so it doesn't become a a burden to your organization. Right? We don't want it to we don't want automation to add more problems that we had before we wanted to make as leaner faster more agile.

And and that's really when enforcing that process and making sure that we're adopting Automation and open source Frameworks that correct way. It's very important. And we see it all the time with with a customer's dad that we work with.

colonel yeah, I find me. right No, go ahead. I find it quite interesting because hearing you speak I actually relate a little bit with the history of sauce Labs.

That was one of the I don't know the first per se but we were in the starting of the talking about testing Automation and comparing the history of just my the company. I worked for with the history of testing. I'm not sure if like it is a What I see it's interestingly a little bit a developed development together with the technology self and the process of technology and nowadays if we understand the importance of software in human lives, and this is for me.

What is the main point of Technology? Right? Like are you supposed to exist to make our lives better?

But with people using it in a very frustrating way if we don't have ways to test it in the during the two chain in the production before the production after while in use and therefore using this idea of devops apply to testing itself. It makes very difficult to use software in a reliable way and Not true for many sense. It was a lot of in my head condensing a short phrase.

But maybe what I wanted to say is that I don't see that's the end at all of testing I think. It's been totally implemented and into the whole process of the software development not just in the beginning the idea but it's supposed to go along with and of course automation. Help us to save a lot of time and massive work, but you are totally right that if one day we just like we thought oh the robots will still lower works.

It's like a it's not about that but about being kind of organically working with and using the manual testers to do some part of the work but using the power of Automation and to make it more reliable to the end user to the ones that will use it. Adam I think you had something interesting. Yeah.

So what I was gonna say, um and and both Andreas and and poem and make great points a what I was gonna add on to that was um, there are so many there's all vast array of Open Source testing tools that it's easy to fall into silos, especially when you think about the scalability of Enterprise large or organizations, you know group a group b Group C Group D Etc group and Won't talk to each other. Right. So so what to prevent them from pulling down an open source, testing framework and have those open source testing Frameworks all be different across the board, right?

And so One of the things that I think is critically important is is laying out consistency in what we're using from an open source, testing framework identifying clear purposes for them and then creating ecosystems around them so that we have a validity of I should say, we have a level of expertise in these in these open source, testing framework. So we go from you know vast to sculpt we build up a level of expertise in the Frameworks themselves, but that doesn't initially mean that we don't have such a subject matter experts in the products themselves that we're testing and you'll always need the subject matter experts regardless of how much automation you put in there. I mean at the end of the day we can add all them automation we want but are we testing the right things in response to the product and getting back the right?

I should say getting back the right responses. Um, so along with that along with the points that Andreas and in Paloma were making, you know, it comes down to scope. It comes down to ecosystems and it still we still need that that subject matter expertise in the products to actually drive effective testing.

Great, one of the things I one of the things I always talk about when I do talks about testing is what to test and this ties into what you were saying Adam about how do you know like which test to write the two places? I always tell people to look the first is what the product person and just figure out like what are the most business critical product flows that like if this breaks, you know, you're you're entire business is going to crash like these are the important business flows that that we need to to have a business and then secondly to look at data and see like what people are doing the most in your application. So if it's a checkout flow or if it's a whatever whatever your application is, like what are people clicking on the most what are people doing the most and I think between your data and your your business need you have a really good idea of like what's important in your application to test there so You know, I look at it.

You know, one of them the missions of devops is busting silos breaking down silos. And you know when I when you look at devops from 500,000 feet one of the silos to bring down is the testing silo. And the idea was all right, we're gonna move testing.

You know, we're gonna let developers do testing. We're devops Engineers will do testing, you know, we're not gonna have just a silo of testing but you know, when you when you flew that plane down or just 50,000 feet instead of 500,000 feet. What you saw is that we testing itself wasn't a monolith.

There was silos within testing different kinds of tests. For whatever reason some types of testing. Really?

Relied heavily on open source tools. Right it open source. Tools became dominant selenium.

Is great example. In other kinds of testing open source tools. didn't really dominate, you know, we're still very much proprietary type of testing tools that that were that were out there now over time though.

I seen a shift to all testing starting to rely on open source-based tools and then companies like a tricenter. So like a sauce or what have you Ed functionality features value on top of that open source. Foundation Is that is that the way it'll continue to go you think do you think we'll see more and more open source, tools dominating the the marketplace with companies just adding value on top.

Um, so so I'd like this take that right? You don't mind at least start off with no go it it my perspective on that. It comes down to risk, right and and so when we step back and we we turned we go back in our time machine there for a little bit and and we think about open source in the conception of it, right?

It was it was the whole notion around software should be free and we shouldn't pay for soft or blah blah and when you begin to look at products that were creating intellectual property that we're selling software for profit those two those two organizations. Began to clash right? And so it you know, when when a product that was building intellectual property started looking at open source, they said at high risk.

Why am I going to use that? I'd rather build my own build my own thing. I don't know what's in there, etc.

Etc. Etc. Right as we've evolved though.

We've become much more risk averse to a degree when I'm not gonna I wouldn't make a blanket statement that says, you know, you know in a in the in the medical or financial institutions, they're they're not risk-avers there's different levels, but I would say in general there's definitely a more organizations are are open to taking risk and when they begin to think about, how can I accelerate my Automation in my automated testing? Well, I can leverage open source. Ought to help drive that very very quickly.

There's a whole Market out there people who might know selling them for example that I can hire and help to drive that automation. It's becoming very apparent to lots of profitable organizations. That they have that ability to measure that risk versus the reward in many of them are choosing the reward.

I'd rather be in a position that I can facilitate a level of testing where there's a known market for it. It's it's available from a source code perspective. And you know, I I can have a better understanding of what I'm using and then potentially build on top of that.

there Yeah, and just to add to what Adam was saying. I I do think that open source Technologies are an incredible Foundation. They're incredibly useful when it comes to testing and even for for companies like like try something like our own company.

I don't think we would be able to offer the automation technologies that we can offer today. If those open source Technologies had income first a lot of the times what we are doing is just simplifying the process. Creating open source automation comes with its own set of challenges.

It's it's something that can be very time consuming. It's something that requires quite a bit of expertise and knowledge. Sometimes being able to find the users that will be able to create that automation for us is a big challenge as well.

So try synthesis is simply simplifying those processes and make it a more accessible to a broader amount of people but when it comes to the open source Technologies themselves, I think they're gonna continue to be a basis for testing on automation well into the future, but we'll just continue to build systems on top of them that will simplify and make it more accessible for for the end user to be able to contribute to the automation efforts getting us closer to devops in that agile World which right now that's come with a lot of I would say skills that challenges and some maintenance challenges as well. Anybody else thoughts on that? Yes.

So I would actually love to hear more from Adam about what do you understand this risk? But to me my my understanding of Open Source especially for if you think about a collective benefit and in that within software where testing and security would be main points where you can of course have business so I think it's important when we differentiate the idea of openness and benefits of the collective and collaborative work with the idea of free. I mean no money involved right?

There are several possibilities for us to Foster new types of Market. I think it is a challenge for the business perspective for sure got to be more inventive and creative. But if you think about the two chain and the testing environment as That something that needs this potential of the collectiveness.

I'm not entirely sure if I understand the idea of risk and then I would like to hear your thoughts and that I would love to but I agree with Alan that it is one of the this possibilities of marketing and how to introduce business into open source. That's one of the possibilities just like Andres was was quoting right you either make it more easier for the user or you add some value like Data analysis or insights report or something where you will have specific. Specifically wins for your client that only a company would really devoted people well paid for do that can give you as a benefit.

I believe so. Yeah and regarding risk. I mean it comes down to fund which you know, basically fear uncertainty and doubt, right and so, um organizations that I've seen certainly Enterprise level organizations when we step back 10 or more years.

We're looking at open source with that from that perspective saying how could this? The this piece of software possibly. How can I possibly bring it into my into my inner workings and incorporate it sort of day-to-day and how would that end up functioning?

And and there was just too many questions about it and over time as we we've learned and we've seen open source fundamentally has better quality it it has fewer bugs. It's got much better testing overall and it comes back down to the simple fact that As we've sort of gone through the hype curve a lot of Open Source that we have found that's in that plateau of productivity area. Has so many people working on it fundamentally that it would be better than any piece of code that you're going to write in-house.

right and when you begin to look at it from that lens and that perspective it all the sudden doesn't become you fear. All the uncertainty goes away and the doubt begins to dwindle in these Enterprise organizations. Say, okay, I get it.

Let's begin to let's begin to use that and follow that industry trend. So if anything open source low is the risk I think is the point you're making there. Wait when it's when it's You know become a standard like that.

Certainly certainly, yeah. You know, I'm just gonna jumping in just thinking about the progression. I remember.

Working with Dev teams test teams and like we need a test framework. We need to test harness, you know, that's where things like selenium came from this to Give you sort of a way of hanging all your tests together and executing them in some, you know, sensible way and managing the data. But if you look at the kind of Market, I think one of the reasons why there's sort of natural silos.

Is because testing tools whether commercial or open source pop up for software architectures. Let's test service. Mesh.

Let's test micro Services here some specialized tools to do that or technology. This is a job environment. This is Jay meter.

This is Appian for mobile, this is Canary testing, you know. And then there's also applications, you know, here's servicenow. Here's whatever as sap and and Salesforce and so it's kind of a not only a silo but a complex Bevy of tools.

And of course, I didn't even mention SAS and Das and all the different kinds of testing that we can do. It is a bit confusing and it is a challenge to know not just what the automate this is the point of all this set not just automating it is what do we do? And then of that what do we automate so we spend time working on the right things and don't waste our time on stuff.

That's not going to help us, you know, make better software. And I'm glad you bring that up Mitch because we do see. Some primary reasons why those silos get created with the customers that that we work with?

One of them being what he just mentioned the the variety of technologies that are out there. Not only that need to be tested but also the amount of Frameworks and technologies that we can use to test even for one technology. There can be three or four choices of Frameworks that we could use to test that technology and it comes down a lot of times to a matter of preference resources how those teams operate but regardless in in a single organization, sometimes you will have several teams that are doing testing each one with their own tool set each one with their own schedules and at that point it becomes very hard to start sharing that information unless there is a system in place that can do that for you likewise those different things might be even operating very differently.

We sometimes find that within the organization. There's one team that might be super Advanced. They're full devops.

They're executing through a cacd pipeline. Most of their stuff is automated. They're very lean, but then you also have other teams within the same organization.

Who are still you know, testing with spreadsheets in a very manual way and sometimes it really just comes down to the the nature of the process and not everyone's gonna move at the same speed which again creates even more silos because all those themes are operating much differently. And even when it comes down to executing those tests now, you have to figure out a way of how do I combine the results of my manual testers and the results of my automation then maybe he's running through a cacd pipeline Because unless I'm looking at everything I'm not gonna have a full picture right? I'm only gonna get on our major results.

I'm on point. I'm only going to get a manual results and another and then I'm gonna have a logistical nightmare of how do I visualize this to to truly be able to answer the important questions right is my product ready? Can I release?

Is there a little risk am I gonna get fired if I promote this code? So so I I think that we see that across the industry when talking to customers and to me those tend to be the primary reasons why those silos get created and those teams to not work as well together. Yeah, just going off that.

I think one of one of the things that we mentioned earlier too was that it's like QA and testers like are not The Gatekeepers of you know, products and enough the code that goes out and so a lot of times what we see is that you know, when something goes wrong like you blame QA or you blame the testers of like oh, why wasn't this Cod or why wasn't this fix like, oh, let's you know, it was keyway's fault, but I think what's gonna happen more and more often is that the testing is going to be distributed to developers and testers and you know across the team so that like the entire team will own the quality of the product as opposed to like just the QA team and I think that goes with what we were all saying about, you know, the the testing that the testing that the QA person does isn't the only testing that happens, you know, it happens across the entire team. So I think that is a big devops thing right there, right that testing isn't just for testers and I think open source tools have A accelerated that but I also think companies who have built testing tools on top of Open Source testing. Platforms have accelerated that as well.

Yeah and an example of that. I Previously one of my one of the companies I worked for I when I was a tester I used cucumber and gerking together and just like a regular bdd framework. And for those of you who haven't used cucumber and garkin it's it's a very like straightforward language where you write you write like given one then code and it you don't necessarily have to have a lot of programming experience to be able to write tests.

And that's what I love about some of these open open source Frameworks is that you don't have to have you know years and years of coding experience to be able to understand and and write tests. You can learn how to write tests through these through these Frameworks without having a ton of coding experience. And so that that's one of the reasons that I like using specifically Robot Framework with cucumber because I was able to you know, as a new grad as a new grad from college.

I was able to just immediately go in and be able to write tests without Without having you know going through a ton of you know coding onboarding. Well in part of in part of what? Both of both Italian and Andres, I think head on to what you're saying there too.

And it makes that to help trying to answer that that question about those the silos I could think comes back to devops team providing or driving. Consistency in building out a platform which contains both processes but as well as tools so instead of having a sort of a free-for-all. What the devops team has to do in that case is assert.

And layout and say well here are the tools for the kinds of testing that you need to do using this platform through this process. Move forward and go ahead and use it and if there's a gap identify that Gap and then work with the computer different product teams try to fill that. Otherwise, we'll continue to just have those silos forever and ever and ever.

Yeah, and I think like at the end of the day like if it's not easy to write tests like No One's Gonna Do them like whether it's unit tests or integration tests or end-to-end tests. Like if it's not easy to write tests No One's Gonna Do them so or they're gonna you know, give you a hard time about writing them. Yeah, totally.

Yeah, absolutely. This is actually one question that we always ask ourselves and I think at some point and it I would actually really appreciate to hear your thoughts on that that is actually dead. Like how do you make testing part of your work full without thinking?

Oh, no, I have to do the testing now. I really appreciate what Talia said how you approach the testing on? Okay.

So simplify the thing look through the where will the product break and what exactual people using it that is such a beautiful thinking right about how to approach it. But then you go to the the white canvas you're there and you have to actually create this suit and as unrest was saying like you have to do that suit in a way that you can analyze with. All the organization how do you make that useful and you're not writing tests for the sake of testing and I I do not have a magic one.

But I believe that this is where also the idea of Open Source and a specially Open Standards come in handy. Because if you approach open source and open Frameworks from the approach of having a standard that works for everyone we have the possibility to have this Frameworks that like a Legos can connect together and you can start to have something more integrated. Um, yeah, I I think that just goes back to like every team's definition of done like a a feature shouldn't be considered down until all the tests are written for and that's something that worked really.

Well when I was a tester is that until the tests are checked in and they're running in production and you know, everything is is working smoothly and the tests have have completed. Like then if that hasn't happened the features not done. So that's something that worked really well for me.

Absolutely, you know. it goes back to something I said at the top of the show, which is Are we a victim of our own success? Are we?

Do we have an embarrassment of riches right? So tell you mentioned for instance cucumber darker two very popular. Certain kinds would cucumber but two very popular tools in the open source, testing space from someone Mitch.

I didn't mentioned so many of my mind of He how is a team to choose the right tool for the job and even if they have a strong bias and preference for open source, right? How did they choose Adam? You know, you have an organization that I think you said it 15,000 developers or something like that.

How do you how do you choose among all the great options that are out there? yeah, um, so it in that he in that way we have to be very cognizant of What are our Engineers needs are right and satisfy 80% of them? right, and so In in that way, we have to be able to provide objective information.

That will lay out. How will meet with those those needs like I said of 80% of the the organization and and from there then provide consistency in how those different tools are tools are laid out. And then how they they should be they should be used and that's a major part of our role in in our organization.

But it also comes back to the process aspect of it too. So It it there. There's a there's a there's a processes that we have in place.

which are their deliberately so that When we are building a product we go through several phases of of testing before we get to that to that end State and that and that's a that's a those are very very fast Cycles as we go through them. But we might have different tools for different stages depending on the different kinds of testing that work that we're doing but we have to we have to come to that conclusion together as a single a single organization. It sounds challenging but in all honesty.

To be able to provide that ecosystem just simply takes time. It just takes takes time. You know, it's not that the tools aren't there they are.

But it also comes back to there's this notion of what I need versus what I like. Right. And so what what you what you like versus what you need are two different things and so we have to differentiate the things and provide what the organization needs versus what some people like versus what other people like, I mean, it comes back to the age old IDE conversation.

Well, I really like VII versus Emax versus you know, etc, etc. Etc. You know, what?

What do you really need? And what could everybody use successful right similar kinds of conversation here? agreed you're telling you have real-world experience testing.

Right you mentioned. Used to enjoyed cucumber gurk and just putting it in there. How did you choose?

What were the right tools for the job? It was it was a combination of things. One of the things that was important to us is that we needed to be able to test in production and that's something that I stand by it's being able to run your tests in production.

And so with these tools we were able to integrate them with gcp and with all of our other tools that we were using so like Integrations is another reason to use a specific tool because it integrate with the other tools that you're that your teens are using that's a big point. And then again, it's just like the ease of use like cucumber girl can and Robot Framework. We're so easy to use like I could write tests and have them checked in in minutes like it was so easy and it just made the the processes the testing processes and the development processes just so much faster and so much more seamless because they were so easy to write and so yeah.

I'm a huge fan of Robot Framework and cucumber. Absolutely, one of the participants in our audience suggested a couple of others karate almoc. I mean look, there's no as I said, there's no shortage of great.

Tools open source testing tools out there. As we only have a few minutes left. for our audience out here whose grappling what to do Right, I'm gonna ask each of you just like parting words your best advice for people in terms of look.

Just because you're a fan of Open Source testing doesn't mean everything you do has to be based on it either too. Right? But I'm gonna ask each of you to give you your kind of best last words of advice to the audience before we do that.

I wanted to mention, you know, we always give out four Amazon gift cards. Ideas events and we pick some winners this event. We have Laura.

Hope I get this right Lauren C. It looks like very a g. Bernardo M.

And Ned k I hope I got those right our team will reach out and get you your Amazon gift cards for those. so best advice for people Andreas I had asked you to kick things off. So I'm going to make let you go less you have time to talk.

Paloma if it's not too much to ask would you mind going first? Okay, I believe if you're just putting your feet there and starting with the trying to create. Reliable Software I would start with a definitely an open source too that it is not just because it's my passion is because I think you will find through the documentation and support for that.

But also You can start with who's that will. Yeah, you should you should start trying out just get download. Just try it out.

I really like to use it mostly user natural processing languages. So they are easier to really write to those are easier for the heart. So searching for tools that have good documentation either.

I would change that phrase either open source or not. But if they have a good support and documentation you feel more supported to start your journey on it. If you have some chance to be part of the community somehow or contribute to you can understand deeply the two it's even more interesting because then you you can just make the best of it.

I think that that would be my advice look for tools that has great support and documentation. Excellent Adam. How about you?

So so I in my in my opinion, it's it's all about consistency. Standardization and using the right set of tools for the right job. You know honesty that's that's how you're gonna scale.

That's how you're gonna solve the several hundred different product group. chronic group problem that you that you may have and and so it's about building that ecosystem that you're developers can thrive in and be productive and But having that scoped productive set of tools, which are the right tools. In delivering them and having or in your engineers use them in a consistent way.

That's that's absolutely key. I I hear it's great advice. Oh, yeah, I bet you.

um final words, I would say use tools that are easy to use and QA and testers are not are not. Are not bought they shouldn't be bottlenecks and they shouldn't be solely responsible for the quality of what you're releasing. It's it's the entire team owns product quality.

I agree with you the entire team not just the test team. the entire team including security On this product quality, excellent. Excellent Last Words Andreas.

How about yourself? Yeah, just from slightly different perspective. I think like Adam was saying when you're considering open source Automation and open source, testing tools.

You're considering scaling up. You're likely have hit a bottleneck somewhere where adding more manpower is simply just not efficient anymore. And we have to look for the help of digital tools to really get us there and to do that.

We're really also want to consider how we're gonna manage that process is a process that can get quite complex very fast and we're already trying to scale up or business. So we need to consider how we're gonna scale up that automation how we're going to streamline it how we're gonna offer it to other teams. And if it's successful, how do we keep that organized and growing steadily as by its nature it will always be growing.

So when adopting open source Frameworks, I do think it's very important that you keep in mind. You're going to manage that framework and how you're going to scale it and extended to the rest of your organization. Actually good stuff.

Mitchell is always going to give you the last word. Thank you. I get kicked off their back on.

Well the parts I heard were just fantastic. I love this team in this this panel, you know one things I think about is is the same thing I think about when we talk about writing software as we would talk about writing tests. And the they're two people again count in my best developer category and one characteristic.

They both tell me is the best developer are the lazy is developers. They like to write the least amount of code. Because they're reused stuff right?

And so I think the same applies in a test world, right? That's you can get yourself in that corner back yourself in a corner where now maintaining all these tests. This is a Herculean task and I think that's a lot of where some of the tools like what I'm telling you was talking about, you know using a lighter weight approach for a scripting language that makes it easier to not use but maintain And so when you think about testing holistically that's another important aspect.

I would suggest considering in addition to the great advice. Everybody else had. excellent Well panel.

Thank you so much for a great great. Great discussion today. We really did have a panel of experts on here.

We're going to wrap up this event this edition of devops. I'm done Roundtable. We'll be back on and not next week the week after with another great episode.

But until then there's Alan shamal for Tech strong anything such I sent this for sponsoring. com. I'm sorry, you weren't able to participate live with our audience.

But we hope you get as much out of it. Thank you everyone. Have a great day.

Bye.