When the Cloud Isn’t an Option: Securing Your API Testing Strategy with Thomas Hurley

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast, and my goal is to help you create DevOps toolchain awesomeness. Hey, welcome back to the show. Today we'll be talking with Thomas all about when the cloud isn't an option, how to secure your API testing strategy, which I think is wicked important. So you don't want to miss this episode. Joining us once again is Thomas, who's been at SmartBear for seven years. He has over six years of those focused on API testing and development. He is the product lead for the Ready API product family and SOAP ui, which you know, I love and works closely with organizations around the world that are embedding API testing into their software development process and DevOps process. You want to miss this episode? Check it out. Hey, before we get into it, quick question. How confident are you that your API tests are really secure? If you're still relying on manual checks or scattered tools, you're leaving gaps wide open. Ready API from SmartBear makes it easy to not only create powerful API tests, but also keep them secure and compliant all in one place. With built in security scans, you catch vulnerabilities early before they become someone else's entry point. Less patching, more peace of mind. Stop stitching together solutions and start shipping confidently. Check out Smart Bias Ready API using the special link down below. Hey Thomas, welcome to the guild.

Thank you very much. So nice to be here. Thanks for the time.

Awesome, awesome. I guess what got you into API testing?

Yeah, I mean I come from a engineering background anyway and I've started working with SmartBear, you know, a number of years ago, actually started selling SwaggerHub or API design tool and it just got me talking to, you know, organizations, Personas, just working with APIs, designing APIs and actually, you know, of course the question always comes up about quality, right? Embedding quality in workflows, ensuring that those APIs are working, you know, functionally and of course from performance perspective. And then I switched over into product and started working, ended up working with Ready API and of course, you know, overseeing Ready API and the open source component SOAP UI as well. So working with organizations around the world, just understanding what, you know, API quality looks like, what they're trying to do. And that's where I am now.

You know, that's why I love speaking with vendors, because you speak with A lot of different enterprises that have a lot of different issues and a lot of different verticals. So that's what I love hearing. I guess before we dive into the main topic of the podcast is, is there one thing you hear over and over again from these companies that maybe they get wrong with API testing, or maybe there's a myth about API testing. You're like, oh, my gosh, I've been doing this for six years, and why is this still happening?

Yeah, I think. I mean, the one thing which is consistent that comes up at organizations is really around the importance of collaboration for quality. It's just, you know, every. It's a team like. Like everything in life, right? It's a team venture, it's a team activity. It's important that everyone understands what quality is, how we deliver on quality. And, you know, so often in the past kind of QA got pigeonholed in at the end of the development process, you know, and really, I mean, what's fantastic over the last few years particularly is your quality is part of the conversation around the design of APIs. And we see in the design process, QA being involved, they're being built with quality in mind as well. But, you know, it's still those organizations that struggle with embedding the collaborative processes into their operations, into their workflows. And, you know, and that's something that we often are helping organizations to understand what good looks like, understand how to get there, and just understand it's a process. Right. You know, it takes time to. To get to that sort of. There's never perfect, but there's always progress. Right?

100% for sure. I know when I talk to anyone around any type of technology, AI or API testing, we always have these discussions. Should it be on prem, should it be in the cloud? Is anything I need to worry about? So just curious to know, since you speak with a lot of these different organizations, what are maybe some common reasons teams stick with on prem for API testing? Are there any security issues, technical issues, regulatory issues?

Yeah, I mean, all of the above comes into play as well, you know, and we see, I think, I mean, for sure, we see so many organizations come to us, and on premise is actually a requirement for them. And there's a lot of reasons why that when you begin to kind of unpack that as well. Some of it, of course, is regulatory. It's really around the importance of just data control, data ownership, just the security of data. And, you know, sometimes we can see in testing environments, they maybe aren't as robust, secure Productionized, right. As your production environment's going to be. And so you, there may be concerns about that getting exposed to the cloud. I think, you know, from our perspective, I mean, smarter is really about there's no like wrong choice, right? I mean it's about what's right for you, it's about what's right for your organization. It's about, you know, what the drivers are for you. So often I think this sort of perspective with people think that on premise means regulatory. Sometimes, yes. Not always though. There's lots of organizations you work with that aren't in regulated environments or having to work through regulations, but just the security is critical. So, you know, I think it's not about anything to do with cloud being bad. It's just about control over data and just ensuring that your data is secure as well. I think, you know, and I'll talk a little bit around, you know, sometimes it's, it's having you want to control your environment and you want to control your data. You know, I guess for customers sometimes it's, it's in the cloud. You don't always have visibility or control over what's changing in the vendor environment. Right. And, and sometimes that can be a concern. And that comes up frequently in conversations with like client infosec teams where they just say, you know, cloud has just, you know, updates and changes being rolled out constantly. We don't always have control over those. And what that means to data is something that, you know, keeps infosec guys up at night and worrying as well.

I would think as a vendor I'd be like, you run an on prem because I don't want to be responsible for any sensitive data, especially if there's like you said, regulatory things involved or you're doing something with healthcare, all these regulations, even though it doesn't necessarily mean you need to be on prem for those type of environments. Is there anything else people need to worry about if they're running in general data sensitive data in the cloud? Is this a real issue? Is it not an issue?

It can be. I mean, I think it's not. I mean, obviously you've got different kinds of data, right, that you're looking after as well. You've got client data, you've got your corporate data, you may have, you know, security like access tokens. There's a lot of things you need to kind of be very aware about. You know, how are they secured, how are they encrypted, what's exposed, you know, and it may not just be about the actual environment. That you're testing in. It could be about the configuration of your tests. It can be some aspects around just how you've configured your tests or your environments that there may be leakage or exposure over time. I sometimes it comes up in conversation that, you know, you build a test and you, you have that deployed into an environment and you're running that regression test over time, you know, but you know, everything changes over time, right? So you can't always be assured that over time something hasn't changed that causes leakage that maybe you're not tracking, maybe you're not seeing as well, you know, and the last thing you want is that call at 4am in the morning going, hey, we've spotted a data leak, right? That's right.

Right.

We've got to respond to that.

Well, that's a good point. I mean, I know in modern software development a lot of people do this micro API type of architecture and a lot of times it's not even that. It's like they consume third party APIs. And not everyone on your team may know that that API is actually not on prem, it's a third party, I assume. Is that something we need to worry about? Is that something you've seen is like, not only is it, does the API need to be on prem, but maybe teams aren't aware that the API they're consuming is actually in house as opposed to like a third party.

Yeah, that can very much be the case as well. And of course, you know, then you're relying on access to that API. It depends on what kind of data you're sending to that API, what the nature and level of the transactions that are happening and the data that's been shared. The question goes, how secure are those APIs? I mean, I suppose, and then this becomes, if I'm testing on premise, the question is, okay, well, what are the environments that I'm testing against? And of course the question goes, okay, well you know, do I have to expose my on premise environment to those external components as I run my test and you absolutely don't as well. And so virtualization comes into play here and that's where it's crucially important for organizations to kind of figure out. And there's different reasons, right, why I'm using virtualization. Right. And you know, frequently I'll see examples where, like I've worked at banks in Scandinavia just to use one example where virtualization be used because, you know, teams in different parts of the organization want one standardized environment to be able to test against the challenge for them could be that external services are not built for testing. Right. They're built for production. Examples could be Experian for credit information from users. Right. There isn't a testing sandbox that I can work against. What if I have to test interactions with Experian? It's not built for testing. There can be costs associated with that, even aside from the security aspect of is it a secure endpoint? But there can be cost against that. So what virtualization does, you know, it allows me to just stand up a record traffic from an endpoint, stand it up in my environment. I can then either record data or I can create synthetic data. I can use my own data. Right?

Right.

But I have control because I have a copy of that external API stood up in my environment. And I can use that, however, wherever, whenever I want as well. And because it's in my environment, I have control. I know what's happening with it. I can configure it the way I want. And that can be important as well.

How many companies or testers do you think are aware of virtualization as an option?

It's a really interesting topic and I get involved with a lot of organizations around virtualization because I find the challenge can be, you know, it's, I've used the analogy a few times. You know, I could walk into a room and ask someone around, you know, a glass of water and go, okay, well the glass of water has value depending on whether you're, you know, thirsty or whether you're, you're on fire or whether you're dirty. Right. But the water and virtualization kind of has that aspect to it. Right. Because I'm using a virtualization because I have dependencies or delays in my development cycle. I've got external services that I'm concerned with or for some reason aren't suitable for testing or I want to be able to virtualize an API and a data set. Right. So I want to virtualize a database, for instance. And actually we see a lot of organizations, you know, coming back to the reasons why on premise and security are important. Maybe I don't want to use my client data, maybe I don't want to use my corporate data, but I want to create a data set that simulates my environment, assimilates my industry, that helps me meet my corporate or regulatory standards, depending on what those are. Right. And I can virtualize the environment, the API, the data set and stand that up. And particularly in the, you know, cost sensitive environment we're all working in these days, you know, I can containerize those environments. So, hey, I've got a test against something. I can spin that up in a container. I can virtualize it based on a recorded endpoint. I can create a virtual service out of an API definition. I can create, virtualize that data set, stand all of that up, you know, and you know, whether I'm just doing a unit test and I want to see is a feature working, whether I'm doing an integration test and I want to see things hooked together. We mentioned microservices a little bit earlier. Hey, I've got different microservices. How do they integrate and work together? I can simulate that again in a secure environment. I own it, I control it, I configure it the way I want. And I know and you know, I can test the edge cases and that comes up frequently with organizations or virtualization is really helpful to them is I want to test the edge cases for be it security or performance or functionality. And virtualization allows me to configure all types of different environments, all kinds of different scenarios as well. And that can be really valuable.

Yeah, so it almost sounds like a lot of people do happy path testing. You can also sounds like you can use this to do negative testing. Almost. Yeah.

I mean, I think we always encourage, as we speak to organizations, you know, and we talk about testing, test coverage, you know, because so often we speak to organizations and their first layer is like functional testing it. Does it do. Yeah, right. Does it do what it says on the tin? Right. Does it do what it's meant to do? But you know what, we often talk at organizations and performance testing and virtualization come into play here because often they become mystified, right? They sort of at times can gain almost this myth of complexity. And so often when we sit with organizations, like I met with an organization a few weeks ago, we were talking about performance testing and they were saying they outsource everything, right? Because it's just, it's really complex, it's really, really difficult. And one of the value propositions of Ready API is that I can take a functional test and very easily convert it to a load test, save time. And we just talked through that. And we talked through that. This is actually a regulated environment. So they were in healthcare, so Hippo was a compliance regulation. They were, they were concerned with as well. We're able to say, hey, you can run this on premise, right? So you can take your functional test, you can create your data set, you can create a load test if you've got components that you don't have available to you yet, then you can virtualize those and stand them up then and build out a full kind of test suite and then you can create a regression test suite that you can then just update and run as and when you need as well. But importantly, you can configure the solution to meet the needs of your regulated, your compliance requirements as well, which becomes really important.

All right, so I'm sure you get this question. Maybe I'm wrong is anytime you do anything with virtualization or mocking people like, oh, or even like not a real device, like an emulator, oh, it's not real. I'm not really testing the application. Do you ever get that type of pushback and is that not thinking correctly or not really understanding what you're doing? When you say virtualization, maybe people really don't understand the concept of what's happening.

Yeah, absolutely. I mean, I guess, you know, you got to break down virtualization into the types of virtualization because there's lots out there right there. There's hardware virtualization, there's software virtualization.

Yep.

I guess in the context here we're talking about API service virtualization as well. And you know, if we think about, well, what are we virtualizing? I mean, fundamentally an API is a, you know, maybe a definition with a series of operations with request and response pairs and scenarios that are being defined. And really what do you want to virtualize? You want to virtualize the happy path. Okay, so based on a request being coming in, am I sending the right response based on different scenarios, I want to do the unhappy path. Right. Am I making sure all my error responding is working correctly as well? You know, my edge cases I'd mentioned as well, I want to hook up my API test cases then to my ui. Right. So I've got a more end to end approach as well. So I can virtualize how my environment works and I can, you know, if you do it well, you're able to come pretty close to a production environment as well. I mean, the reality is it's not a production environment, of course, but you're coming as close as you can be towards mapping out the request and response models. And with virtualization you can do things like set behavioral conditions, latency delays, proxy issues, you can virtualize all of those. And so again, you can take those, simulate those edge cases, simulate those things that are, you know, you don't want to be testing in your production environment because you haven't tested it in your IQA environment.

It almost sounds like chaos engineering as well. Do you See then a lot of developers or software reliability engineers using virtualization then to help them with their type of testing.

I think what we often see is it's a misunderstood area, I think sometimes because often when I'm testing something, I may be testing it as a unit, I may be testing it as a feature.

Right.

I think as we start to see organizations do more, you know, I've got microservices, I want to be able to test how this microservices interact. So I can do contract testing or I can do just a consumer or provider side and just test that the expectations are met on both sides of that contract. Test often happens is organizations can't quite agree on what they want from virtualization and how it serves the different groups or use cases that are interacted. And sometimes it's back to the collaboration of the Personas in, in software development. Sort of understanding the features are building, understanding how they work as an application, building out the test cases, starting to think about what this, you know, our unit testing policy, our integration testing policy, how we're going to use microservices and contract testing. It's a layered, progressive discussion and plan to build, you know, a robust QA approach and profile as well. And I think sometimes virtualization kind of falls between the cracks for organizations in the sense that because the collaboration can't quite agree on exactly what it is we're missing. I mean, for years I've been speaking to QAs and QA managers and the one consistent thing that I hear is just that, you know, hey, a feature gets thrown over the wall and things land on our desk and we've got to test this immediately. And sometimes the QA leaders particularly, you know, don't have time to work with the architects to figure out where virtualization comes in. When they do, it's phenomenal. The acceleration that occurs, the velocity improvements, the ability to expand the test cases that organizations can utilize. It really is a powerful tool. But I think it's understanding what are we testing, what are the components we're missing, where do the delays and dependencies occur, what is it we can virtualize and then understanding how those components can be simulated and stood up can be powerful.

Absolutely. It sounds almost can help with shift left testing as well. I know I used to work at a company where we had a product, but it consumed two or three other products within the team that different Sprint teams were developing. So the team would go, oh, we're relying on this. They're not done yet with the feature. So we're held up, we can't complete our sprint. It sounds like you could actually virtualize maybe that part until the team then was ready to deliver their piece. Am I understanding that correctly?

You can. I mean, if I kind of connect a few dots here in terms of embedding quality, you know, like, yeah, you know, a workflow example that we, you know, if we talk about design first and shift left, the whole idea that I can build a definition, right? And I've got an API that I'm working on, I've got. Everybody's agreed on the design, you know, what I can do with the design is to embed quality standards. So they may be security checks, they may be standardization checks that I'm building into my design process so that before the design gets approved and pushed to qa, I already got a number of qualities and standardization checks occurring in the definition. What I'm then able to do is take the API definition and I can virtualize it. And you know, in some, in a tool like Ready API, for instance, I can take a definition and stand up a virtualized service in a minute, two minutes, right? It literally is that quick. Deploy it onto a virtual server environment, share it out to the organization, and then I can use that, whether it's for internal testing, whether it's for sharing with my colleagues, my integration partners. Again, depending on what it is I want to do. But the whole idea that I do not have to wait for something to be coded, I can virtualize the definition, get testing against it earlier, and then it kind of goes back to, yeah, what am I testing? Is it, you know, unit cases? Is it integration testing? Is it contract testing? You know, what phase of quality testing am I at and how do I want it to work? But I've seen organizations say, you know, bringing in tools like virtualization have, you know, testing get starts in hours rather than days, you know, and we're all under pressure to get software out faster, better, more secure, more quality, ensuring that our consumers are, you know, not failed when they first touch an application or an API as well. Virtualization has an important part to that as well.

That's a great point. I think what a lot of people struggle with is they have like open source tools they're using and they have to try to connect. Okay, now I need virtualize some sort of virtualization source that works with this other tool and this other tooling. And I could be wrong. It sounds like Ready API is. It's like, you don't have to worry about it, has built in virtualization. You can use it for performance testing maybe a little bit like I guess people are very familiar with SoapUI, they may not be as familiar with ready API a little bit more maybe about the benefits of using like a full feature solution like Ready API.

Yeah, absolutely. I mean, you know, again, a quick history. Sure. Because it's been around actually 20 years old in October, which is really interesting.

That's awesome.

And smartware will be doing some work on that, so keep your eyes out for, for what's happening there. But basically, you know, as so often happens at open source products, there were additional users starting, starting to need, you know, collaborating more, they needed to automate more, they needed more rapport porting capability, you know, and there was an opportunity then for SoapUI to become pro, which became Ready API. The fundamental principle of Soap UI and Ready API it is, you know, I build a test, I want to be able to reuse. So I got a functional test, I can reuse that functional test use case to create a load test demystifies performance. I could do it very quickly template based. But ready APIs, you know, it's a no code, low code writes, point and click and build your test very quickly. I can extend it through the capability, the product through scripting. But then you know, hey, I want to be able to go from a unit test up to, you know, building out a more comprehensive test case test suite which may have different scenarios. May I want to overlay load testing onto performance testing. I may want to add some virtualized services into that. Ready API supports all of that. The idea being it's one platform meeting all of your needs from a quality perspective. And then of course we're seeing all of our QA colleagues are dealing with different protocols. We're dealing with soap, we're dealing with rest, GraphQL, GRPC, async, Kafka, the list goes on all of these then Ready API support. So you know, it's if you're looking to improve test coverage, if you're looking to do multi protocol testing, one key area we're seeing organizations come in regularly now, and this is really relevant in the security context as well, is with AI, tons of code been generated, right. So AI is just churning out code like a good old thing. And the challenge can be that code doesn't always go through strong governance. I we are often seeing the code comes out but often the developers don't always fully understand what that code does and they don't always understand the risks and the security concerns or exposures from a code and the way it's been developed and so the ability to generate run tests regularly and where Ready API has a strong value proposition is automation. Because we say to organizations and particularly as you look into scale and improve, you know, it's test coverage using virtualization use DevOps automation is really key. And I one of the value propositions with the Ready API suite is that I can very easily spin up a test, I can very easily automate that test. I can hook it up to my GitHub actions, into Azure and to Jenkins and I can automate those tests and run them as many times as I need. My license gives me great flexibility to do that in Ready API. And I think what I've seen organizations do, you know where because you know, the conversation sometimes might start with secure testing, hey, I need to do stuff on prem I am working in a regulatory environment or our data is really sensitive, we cannot afford to have it exposed to the cloud or we're not entirely sure how our data is secured in the cloud. It may be that, you know, it's not transparent enough in terms of what security encryption methods are used. It's not entirely clear what changes occur. You know, we hear things about breaches and so forth and we see organizations kind of coming into us and saying, hey, we want to test at scale, we want to improve test automation, we want to be able to secure our data. We need to automate hugely doing that. On prem the value proposition sometimes is it's just scale. I can automate at scale without rate limits. Because so often your cloud services and some SaaS providers, you go through the tiers and you've got to go through the different pricing offers. What one of the things Ready is very good at is, yeah, I can automate at scale. And that's why so many organizations love it, because you can do that.

So it sounds like easily you could plug it into your CI CD pipelines and maybe when a test is uploaded, kick off maybe a suite of tests that just verify before they check into the master branch or something like that.

Absolutely. I mean it's a value proposition of smartware. We're very open in terms of our integrations, right. I mean we understand we live in an ecosystem with lots of other tools, right? Different git providers, different CICD providers. You know, you're using tools like Slack, you're using tools like Jira, you design your APIs in different tools. I mean, we don't lock you into Spyker Hub or API Hub design as we, we've brought out. Right. You may sit your API definition could Sit in lots of different places. We don't lock you down your open integrations as well, but exactly as you say then Joe, it's, you know, we use different CI CD engines, we use different CI CD processes. Sometimes different teams and different companies use different processes. Again, it's all good. It's very easy to spin up a test, make the test available to automation, run it as you want and then away you go.

You know, you checked a lot about performance testing. It's very difficult. But this seems like you get a functional test, you can easily make it into a performance test. I assume you get the same conversations with the security testing, like does this have any built in templates for like here are coming owasp, like SQL injection errors or something that like here's a quick test to create for that or like how does it help? Any type of helping, walking someone through those type of tests?

Yeah, absolutely. I mean again, you know, fundamentally ready API you do functional testing, security testing, performance testing as well. What we do with your license is you get security testing is actually added to functional testing as a just an add on, right? It's just included, it's bundled with it. And so what we encourage customers to do is it provides you. There's, I think it's about 14 different security tests you get. So you're doing fuzzy boundary scans, XML injections or SQL risks. And what you're able to do is build a functional test very quickly at a layer of a security test. And what organizations like to do is they can run the security tests with the functional test. Right? Of course you're going to have a dedicated security monitoring and testing tool. You know, whether it's dependabot or wiz, whatever your using in organization. What ready allows you to do is to test for some very common security risks in APIs. Embed that with your functional testing. It just adds a layer of test coverage to your test suite. And again, you know, testing frequently, testing often adding those different types of tests. It all just gives you a greater sense of confidence that your API is functioning. You're checking all of the different use cases, you build out your aggression tests and your, your test suites over time for all of those different test cases. You know, and like I say earlier, it's not about perfect, it's about progress. Right. So it's about just constantly improving as well. But I think, you know, organizations differ. There are different stages of maturity, there are different things, different challenges you're overcoming as well. But you know, I think what we see with so many organizations, they Come in looking for advice. We're happy to start, help them, start with them. I think some of the misconceptions sometimes and you know, is that the whole organization needs to move in the same direction at the same speed, you know, not necessarily the case and depending on business units, business, different teams, you know, help us understand what you're trying to achieve and we're more than happy to, to sit down and provide, you know, some ideas and advice and then ideally solutions.

I may be wrong. It almost helps like it can almost help with culture as well because the tool allows you to do performance testing, security testing, and almost facilitates a whole team approach rather than, oh, that's for the formats team later on, this is for the security team later on. Maybe it gets really stuck that, you know, maybe I should think about performance testing as I'm developing it. Maybe I should think about security as I'm developing it. So I don't know, is that something you hear us see or is that just something.

No, it's a really good catch. So I find really interesting. Sami. I look after the development ready API, all of the add on products and so PI and so forth. And as we go through any kind of ideation, any design on new features, enhancements or changes to the product, we absolutely make sure our QA colleagues are part of the initial discussions. Because the one thing I find, you know, it's in a QA's mindset to find the edge cases, to find the things that as a product owner or product manager, even as a developer, you may not always think. And I that's why I love having the QA team and part of our ideation and design work because they will think about the things that we don't think about and they think about them at the beginning. And so we're designing and developing for the edge cases from the get go rather than getting to at the far end of the development process with the test cases going, oh, you didn't think about this right? And I just find that it adds speed, it adds just robustness to the application and from a culture perspective, it just adds collaboration, teamwork. Everybody has value. And I think most importantly for me, it embeds quality in the mindset of the development process and that becomes really crucial and that becomes a mindset literally that everybody aspires to, adheres to and signs up to and gets very quickly.

Absolutely. So nowadays I have to ask everyone, AI machine learning, how does or does it at all AI or machine learning play any role in on prem API testing strategy that You've seen?

Absolutely. I mean, every company is, you know, working with AI or thinking about working with AI. The vast majority are already there. So I think irrespective of whether you're in the cloud or whether you're on prem, you know, AI is going to be a just. It's a fact of life for everybody at this moment in time. I think, as well, I think, as always with AI, you know, the challenge that a lot of organizations are probably wrestling with really, is that it's very easy with AI because it's so easy to produce something with AI, then I do, and therefore production is at scale. Sometimes that happens out of control, and sometimes as a case, it's so easy to create that the design work isn't always optimized at the very beginning. So maybe I'm churning stuff out without really fully thinking about, do I really need it, do I really. Could I consolidate some things together as well? But when I'm designing something and then I'm converting that into code, and AI is doing all that generation, you know, if the design is poor and then the code is poor, or not even poor, just, you know, in any way, not to the quality standard that you aspire to as a professional organization, that has consequences in QA as well. And we see the amount of organizations we're working with or in regulatory, you know, working in on prem and secure environments, AI is still a fact of life for them as well. And AI now with agentic AI, you know, so many different options for on PREM support and AI, of course, as well. So it's. But AI quality and AI can go together, right? It's just like everything is being intentional. It's designing with quality in mind. And again, we find, you know, even as we work with AI and we're working on different aspects of AI with Ready API, which we're looking forward to bringing some interesting features to the market later this year as well. We're sitting here working with the QA team, understanding, you know, well, how does. What are the use cases? What are the edge cases? Why am I using it? What am I trying to do? But with a quality mindset, you know, our QA colleagues, again, keep us true and honest.

Does Ready API do synthetic data? I think you mentioned synthetic data, but I don't know. I don't know if that was a separate product or does Ready API do that as well? Because that's one of the top four things that kill any testing effort. It's usually the environment, bad test data, bad locators. So, right you have test data covered, right?

Yeah, completely. So. So I think there's a few things we have in ready which are important organizations and data is always interesting, as you say, because maybe we don't want to use our own data or maybe we have our own data. We're trying to figure out how we inject that into test, you know, efficiently and at scale. So Ready API then allows you to. So we have database integrations. So whether you want to use Excel, CSV connect to your SQL database, whether you want to use synthetic data. Because we have data generators in Ready API, we're actually looking at some options now for data generation through AI. We'll be looking into as we get out at the end of this year and early next as well. Lots of options for data. And I think the question is, you know, what data are you looking to generate and use? What are the security concerns you have around it and your regulatory requirements? And we see, we work with companies across all industries and a lot of the companies that we're working with are, you know, they're using Ready API because not just is it easy to work with and it meets their needs, but the management of data, the configuration of data and reporting to again compliance needs, all of these things can be easily addressed as well. And something which, you know. Yeah, I think as we were saying earlier, come and talk to us if it's anything you're struggling with.

No, so it's a huge issue I'm not trying to solve Ready API, but I'm just curious. I know a lot of times this is back in the day, way before this, I have a vendor tool and they're like, oh, to unlock that, that protocol, you need this other license to unlock this. So if someone gets Ready API, does it include all this or are this like, are there different flavors of ready API? Yeah, sure.

So we license ready by module. So you get a functional test module. I mean it's an application deploys into users environment. So you've got a license that either you've got a power user needs a fixed license for their personal use. I maybe want a floating license across a pool of users. But we license based on you get functional and security testing under one license, but then that user can do whatever they want, right? As many tests as you want to create, as many times you want to execute that test, whether you want to automate that test. These are all options. You then can take a performance testing license and you can layer your performance testing and then, hey, I find I've got some endpoints that I need to record and stand up in a virtualized environment. You can take a virtualization license as well, or you can buy all the licenses together in one bundle. License as well. It's very much. It's modular. It's about what you need. You know, come and talk to us if you're trying to figure out, you know, either improving test coverage or how to get started with specific areas of testing as well. But the data generator, the protocol support, they're part of the licenses. So you don't. There's no additional cost for using those capabilities. They're part of the core license and. Absolutely. Yeah. I mean, again, you know, I think the organization's requirements can be quite granular. I think it's often, it's really. And this is why we love a conversation with a customer. What are you struggling with? What is it you need help with? Because, you know, we start with that and then we build out in terms of the broader value.

Absolutely. All right, Thomas, before we go, is there one piece of actual advice you can give to someone to help them with their API DevOps efforts and what's the best way to find contact you?

Yeah. So I think, I mean, firstly, come and talk to us all, say, right, no matter what the challenge, you know, or whatever you're trying to achieve, because whether you're trying to raise, you know, a hundred things by 1% or one thing by a hundred percent, a conversation with us, because we're talking to lots of organizations around the world in lots of industries regulated, be it cloud or on prem. It doesn't matter what your environment you need to work to or you're in a hybrid motion. You. It helps to talk to organizations like SmartBear because we are talking to everybody else. And so we do have a good sense of what industries are doing, how problems should get solved. We certainly provide lens and perspective on things you can improve, I think as well. And then, you know, we've got the teams readily more than happy to speak to any organization that's in need of assistance as well. And then obviously all of our tools take them, take trials, have a play. And we're always here to help. But I think, you know, go to smartbear.com check out our tools. I'm on LinkedIn under Thomas Hurley. Feel free to ping me. More than happy to engage and speak. And then we can connect you to whomever needs assistance.

Absolutely. And you can learn more about ready API using the special link down below. And for links of everything of value we covered in this DevOps Toolchain show, head on over to testguild.com p193 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 at Test Guild and where you become part of our elite circle driving innovation in 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. Oh the TESCEL Automation Testing Podcast With Hoots and Liars the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land, Guiding testers, showing us secrets to behold.