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

[00:00:00] Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for 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.

[00:00:00] Joe Colantonio 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 7 years. He has over 6 years of those folks on API testing and development. He is the product lead for the Ready API product family and SOAP UI, which I love and works closely with organizations around the world that are embedding API testing into their software development process and DevOps process. You don't want to miss this episode, check it out.

[00:00:53] 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 SmartBear's Ready API using the special link down below.

[00:01:30] Joe Colantonio Hey Thomas, welcome to The Guild.

[00:01:33] Thomas Hurley Thank you very much. So nice to be here. Thanks for the time.

[00:01:36] Joe Colantonio Awesome, awesome. I guess what got you into API testing?

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

[00:02:27] Joe Colantonio That's why I love speaking with vendors, because you speak to 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 like, oh, my gosh, I've been doing this for 6 years. And why is this still happening?

[00:02:50] Thomas Hurley 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 every, it's a team, like everything in life. It's a Team Venture, it is a team activity. It is important that everyone understands what quality is, how we deliver on quality. And so often in the past, kind of QA got pigeonholed in at the end of the development process. And really, 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, that they're being built with quality in mind as well. But it still is organizations that struggle with embedding the collaborative processes into their operations, into their workflows. 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. It takes time to get to that sort of, it's never perfect, but there's always progress, right.

[00:03:58] Joe Colantonio 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 in the cloud? Is there anything to worry about? 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?

[00:04:22] Thomas Hurley Yeah, I mean, all of the above comes into play as well, 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 of data. And sometimes we can see in testing environments, they maybe aren't as robust, secure, productionized as your production environments going to be. And there may be concerns about that getting exposed to the cloud. I think, from our perspective, I mean, SmartBear is really about there's no like wrong choice. I mean it's about what's right for you. It's about was right for your organization. It's, about what the drivers are for you. So often, I think the sort of perspective with people think that on-premise means regulatory. Sometimes, yes, not always though. There's lots of organizations who work with that aren't in regulated environments or having to work through regulations, but just the security is critical. 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. And I'll talk a little bit around, sometimes it's having, you want to control your environment and you want control your data. I guess for customers, sometimes it's in the cloud. You don't always have visibility or control over what's changing in the vendor environment. And sometimes that can be a concern. And that comes up frequently in conversations with client infosec teams where they just say, cloud has just updates and changes being rolled out constantly. We don't almost have control over those. And what that means to data is something that keeps InfoSec guys up at night and worrying as well.

[00:06:19] Joe Colantonio 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 health care, all these regulations, even though it doesn't necessarily mean you need to be on-prime 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?

[00:06:41] Thomas Hurley 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 clients data, you've got your corporate data, you may have security, like access tokens. There's a lot of things you need to kind of be very aware about how are they secured? How are they encrypted? What's exposed? 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 how you've configured your tests or your environments that there may be leakage or exposure over time. Sometimes it comes up in conversation that you build a test and you have that deployed into an environment and you're running that regression test over time, but everything changes over time right? 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. And the last thing you want is that call at 4 a.m. in the morning going, Hey, we've spotted a data leak, right? We've got to respond to that.

[00:07:48] Joe Colantonio 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's something you've seen is like not only is 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.

[00:08:16] Thomas Hurley Yeah, that can very much be the case as well. And of course, 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 tested against? And of course, the question goes. Okay, well. 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 why I'm using virtualization. And frequently I'll see examples where like I've worked at banks in Scandinavia just to use one example where virtualization be used because teams and 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, they're built for production. Examples could be Experian for credit information from users, there isn't a testing sandbox that I can work against. What if I have to test interactions with Experian? It's not built testing. There can be costs associated with that, even aside from the security aspect of it. Is it a secure endpoint? But it can be cost against that. What virtualization does, 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. But I have control because I have a copy of that external API set up 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.

[00:10:15] Joe Colantonio How many companies or testers do you think are aware of virtualization as an option?

[00:10:21] Thomas Hurley It's a really interesting topic and I get involved with a lot of organizations around virtualization because I find the challenge can be, I've used the analogy a few times, I could walk into a room and ask someone around a glass of water and go, okay, well, the glass of water has value depending on whether you're thirsty or whether you are on fire or whether you're dirty. But the water and virtualization kind of has that aspect to it because I'm using 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 are suitable for testing, or I want to be able to virtualize an API and a data set. I want to virtualize the database, for instance. And actually, we see a lot of organizations coming back to the reasons why on-premise and security are important. Maybe I don't want to use my client's data, maybe I don't want to use my corporate data, but I want to create a dataset that simulates my environment, that simulates 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 dataset, and stand that up. And particularly in the cost-sensitive environment we're all working in these days, I can those environments. Hey, I've got to test again 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. And whether I'm just doing a unit test and I want to see as a feature working, whether I am doing an integration test and I wanna 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, and I can configure it the way I want. I can test the edge cases and that comes up frequently with organizations where virtualization is really helpful to them. I want to test the edges cases for security or performance or functionality, and virtualization allows me to configure all types of different environments, all kinds different scenarios as well, and that can be really valuable.

[00:12:48] Joe Colantonio Yes, 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.

[00:12:54] Thomas Hurley Yeah. I mean, I think we always encourage as we speak to organizations, and we talk about testing, test coverage, because so often we speak organizations and their first layer is like functional testing. It doesn't do what it says on the tin, right? Doesn't do what it's meant to do?. But what we often talk to organizations and performance testing and virtualization come into play here, because often they become mystified. 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 because it's really complex. It's 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. Were in healthcare, so HIPAA was a compliance regulation they were concerned with. As well we would say, hey, you can run this on-premise. So you can take your functional test, you can create your data set, you 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 test suite. And then, you can create your 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.

[00:14:27] Joe Colantonio All right. I'm sure you get this question. Maybe I'm wrong. Anytime you do anything with virtualization and mocking people like, oh, or even not a real device like an emulator, it's not, 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?

[00:14:49] Thomas Hurley Yeah, absolutely. I mean, I guess you're going to break down virtualization into the types of virtualization because there's lots out there, right? There's hardware virtualization, there's software virtualization. I guess in the context here, we're talking about API service virtualization as well. And if we think about, well, what are we virtualizing? I mean fundamentally an API is 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 visualize the happy path, Okay? Based on a request being coming in, am I sending the right response based on different scenarios? I want to do the unhappy path. Am I making sure all my error responding is working correctly as well? My edge cases I'd mentioned as well. I want a hook up my API test cases then to my UI. I've got a more end-to-end approach as well, So I can virtualize how my environment works and 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 or 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 could take those, simulate those edge cases, simulate those things that are, you don't want to be testing in your production environment because you haven't tested it in your QA environment.

[00:16:32] Joe Colantonio 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?

[00:16:41] Thomas Hurley 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 testing it is a feature. I think as we start to see organizations do more, I've got microservices. I want to be able to test how this microservices interacts so I can do contract testing or I can just do a consumer and provider side and just test that the expectations or measured 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 software development, sort of understanding where the features are building, understanding how they work as an application, building out the test cases, starting to think about what's 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 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, 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, 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.

[00:18:58] Joe Colantonio Absolutely. It sounds almost like it could 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. The team go, oh, we're relying on this. They're not done yet with the feature. 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. I understand that correctly.

[00:19:20] Thomas Hurley You can, I mean, if I kind of connect a few dots here in terms of embedding quality, like a workflow example that we talk about design first and shift left, the whole idea that I can build a definition. And I've got an API that I'm working on. I've get everybody's agreed on the design. 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 am building into my design process. So that before the design gets approved and pushed to QA, I've 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 in a tool like Ready API, for instance, I can take a definition and stand up a virtualized service in a minute, two minutes. It literally is that quick. Deploy it onto a virtual server environment, share it out to the organization, and that I can use that whether it's for internal testing, whether it was 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 unit cases? Is it integration tests? And is it contract testing? What phase of quality testing am I at? And how do I want it to work? But I've seen organizations say, bringing in tools like virtualization, have testing get starts in hours rather than days. And we're all under pressure to get software out faster, better, more secure, more quality, ensuring that our consumers are not failed when they first touch an application or an API as well. Virtualization has an important part to that as well.

[00:21:13] Joe Colantonio 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 SOAP UI. 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.

[00:21:44] Thomas Hurley Yeah, absolutely. I mean that, again, a quick history tour because SOAP UI has been around actually 20 years old in October, which is really interesting.

[00:21:52] Joe Colantonio That's awesome.

[00:21:52] Thomas Hurley And SmartBear were doing some work on that, so keep your eyes out for what's happening there. But basically, as so often happens at open source products, there were additional users starting to need collaborating more, they needed to automate more, they needed more reporting capability, and there was an opportunity then for SoapUI to become Pro, which became Ready API. The fundamental principle of Soap UI and Ready API is I build a test, I want to be able to reuse, 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, it's a no code, low code, point and click and build your test very quickly. I can extend it through the capability of the product through scripting. But then, hey, I want to be able to go from a unit test up to 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 where REST, GraphQL, gRPC, Async, Kafka, the list goes on. All of these then Ready API support. If you're looking to improve test coverage, if you look into the 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. 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. 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 the ability to generate, run a test regularly and where Ready API has a strong value proposition is automation because we say to organizations, in particular, as you look into scale and improve, it's test coverage, using virtualization, use DevOps, automation is really key. And one of the value propositions with the ready API suite is that I can very easily spin up a test. I can easily automate that test. I can hook it up to my GitHub actions, into Azure, into 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 where, the conversations 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 secured in the cloud. It may be that it's not transparent enough in terms of what security encryption methods are used. It's not entirely clear what changes occur, 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 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. Cause so often the cloud services and some SaaS providers, you go through the tiers and you've got to go through the different pricing offers. One of the things ready is very good at is, yeah, I can automate its scale. And that's why so many organizations love it, because you can do that.

[00:25:53] Joe Colantonio 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.

[00:26:04] Thomas Hurley Absolutely. I mean, it's a valid proposition of SmartBear. We're very open in terms of our integrations. I mean we understand we live in an ecosystem with lots of other tools, different Git providers, different CI/CD providers, you're using tools like Slack, you using tools, like Jira, you design your APIs in different tools. I mean, we don't lock you into Swagger Hub or API Hub design, as we've brought out. You may sit your API definition could sit in lots of different places. We don't knock you down your open integrations as well. But exactly as you say it then, Joe, 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.

[00:26:52] Joe Colantonio You talked 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 types of tests?

[00:27:15] Thomas Hurley Yeah, absolutely. Again, 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 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, I think it's about 14 different security tests you get. You're doing fuzzy boundary scans, XML injections, 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 test with the functional test. Of course, you're gonna have a dedicated security monitoring and testing tool, whether it's Dependabot or Whizz, whatever you're using in your 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, 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 regression tests and your test suites over time for all of those different test cases. And like I said earlier, it's not about perfect. It's about progress. It's about just constantly improving as well. But I think organizations differ, there are different stages of maturity. There are different things, different challenges you're overcoming as well, but I think what we see with so many organizations, they come in looking for advice. We're happy to help them, start with them. I think some of the misconceptions sometimes is that the whole organization needs to move in the same direction at the same speed. You're not necessarily the case and depending on business units visit different teams, help us understand what you're trying to achieve, and we're more than happy to sit down and provide some ideas and advice and then idea these solutions.

[00:29:18] Joe Colantonio I may be wrong. It almost helps like it can almost help our 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 where the performance team later on, this is for the security team later on. Maybe it gets real static, maybe I should think about performance testing as I'm developing it. Maybe I should think about security as I am developing it, so I don't know, is that something you hear or see or is that just something?

[00:29:43] Thomas Hurley No, it's a really good catch. I find really interesting. So I mean, I look after the development Ready API, all of the add-on products and SOAP UI 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, is QA's mindset to find the edge cases, to find the things that, as a product owner or product manager, or even as a developer, you may not always think, 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 the far end of the development process with the test cases going, oh, you didn't think this. And I just find that it adds speed. It adds just robustness to the application. And from a cultural 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 become a mindset literally that everybody aspires to, adheres to, and signs up to and gets very quickly.

[00:31:04] Joe Colantonio 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?

[00:31:15] Thomas Hurley Absolutely. I mean, every company is working with AI or thinking about working with AI, the vast majority are already there. I think, irrespective of whether you're in the cloud, or whether you are on prem, 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. 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 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? Could I consolidate some things together as well? When I'm designing something and then I'm converting that into code and AI is doing all that generation, if the design is poor and then the code is poor, or not even poor, just 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. Working in on-prem and secure environments, AI is still a factor of life for them as well. And AI now with agentic AI, so many different options for on-prem support in AI of course, as well, 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, 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 at working with the QA team, understanding, 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, our QA colleagues again, keep us true and honest.

[00:33:20] Joe Colantonio Does Ready API do synthetic data? I think you mentioned synthetic data, but I didn't know if that was a separate product or is Ready API doing that as well? Because that's one of the top 4 things that kill any testing effort. It's usually the environment, bad test data, bad locators. So you have test data covered.

[00:33:36] Thomas Hurley Yeah, completely. 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, but we're trying to figure out how we inject that into tests efficiently and that scale. 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 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 that 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, 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 using Ready API because not just is it easy to work with, it meets their needs but the management of data, the configurating of data and reporting to, again, compliance needs. All of these things can be easily addressed as well. And something which, yeah, I think as we were saying earlier, come and talk to us if it's anything you're struggling with.

[00:34:46] Joe Colantonio No, 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 protocol, you need this other license to unlock. If someone gets Ready API doesn't include all this or this like, are there different flavors of Ready API?

[00:35:04] Thomas Hurley Yeah, sure. We license ready by module. So you get a functional test module. I mean, it's an application deploys into users environment. 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 the 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. As many tests as you want to create, as many times you want 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 your virtualization license as well, or you can buy all the licenses together in one bundle of license as well. It's very much, it's modular. It's about what you need. Come and talk to us if you're trying to figure out either improving test coverage or how to get started with specific areas of testing. But the data generator, the protocol support, they're part of the licenses. There's no additional cost for using those capabilities. They're part if the core license and absolutely, I mean, again, 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? Cause we start with that and then we build out in terms of the broader value.

[00:36:31] Joe Colantonio All right, Thomas, before we go, is there one piece of actionable advice you can give to someone to help them with their API DevOps efforts and what's the best way to find or contact you?

[00:36:40] Thomas Hurley Yeah, so I think, I mean, firstly, come and talk to us. They will say, right, that no matter what the challenge or whatever you're trying to achieve, because whether you're just trying to raise 100 things by 1% or one thing by 100%, 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, 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, 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'll 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.

[00:37:44] Joe Colantonio Absolutely. And you can learn more about Ready API using the special link down below.

[00:37:48] And for links of everything in value we've 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 in creating end-to-end full-stack DevOps ToolChain awesomeness. As always, test everything and keep the good. Cheers.

[00:38:11] 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 TestGuild.com where you become part of our elite circle driving innovation, software testing, and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit TestGuild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

[00:38:54] Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.