Traffic-Driven Testing for Faster Execution with Nate Lee

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, wouldn't it be great to be able to shine a spotlight on your Kubernetes applications and illuminate what's going on in your apps to see what you could troubleshoot with high fidelity, debug with less headaches and quickly uncover blind spots and unusual behavior, Especially with all kinds of traffic in a cloud native world. If so this episode's view because we have Joining us Lee, who's going to talk all about kubernetes, traffic testing, mocking and a whole bunch more. You don't want to miss it. Check it out.

This episode of the Test Guild Automation Podcast is sponsored by the Test Guild. Test Guild offers amazing partnership plans that cater to your brand awareness and lead generation and thought leadership goals. Get your products and services in front of your ideal target audience. Our satisfied clients rave about the results they've seen from partnering with us, from boosted event attendance to impressive roi. Visit our website and let's talk about how Test Guild can take your brand to the next level. Head on over to test guild.info and let's talk.

Hey Lee, welcome to the Guild.

Hey Joe, nice to be here. Appreciate it.

Absolutely. Before we get into it, could you just tell us a little bit more about yourself? I know you have over 10 years experience in DevOps, but I know you have an interesting background. You're one of the founders of a really cool tool. So just let us know a little bit more about yourself.

Yeah, Nate Lee, I've got tons of experience in the DevOps and observability space. Originally started out as kind of like a sales engineer and then had gone been part of a startup that had founded kind of the service virtualization space. So service virtualization service mocking. I mean it's all kind of the same thing. One's a little bit more hyped up version of the other, but the idea is you can simulate these backend endpoints right? So did sales engineering there, eventually moved into product management and helped kind of pioneer that space with a lot of Fortune 500 companies. Joined forces with a few of my Georgia Tech colleagues Ken Ahrens and Matt Laure who come from companies like New Relic and observe heavy DevOps monitoring experience there too and develop speed scale. So with a lot of the monitoring observability tools I Mean, they're great kind of canaries in the coal mine, if you will. But how do we figure things out before the canary keels over is kind of what the problem statement was. Right. Instead of reacting to these issues as the alerts come up, could we preemptively tell you that there is going to be an issue and fix it before? And so increasing focus on resiliency and scalability nowadays, especially with these companies in the news talking about outages all the time. That's why we developed speed scale and it was a way for us to use traffic to preemptively catch issues that could affect production before they happen.

Awesome. Now I do trends every year and one of the trends is moving from deterministic testing to non deterministic testing. Because and we're moving from bare metal to now in the cloud, we're using all these services. You're in production, you're in the wild, you have no idea what the heck's going on. And that's why I think I see an increase in tools like the need for speed scale. Is that the use case? Is that why it seems to be like a bump in why the relevancy for a tooling like does rather than old school monitoring like we had back in the day?

Yeah, that's definitely part of it.

Actually.

I was on a customer call yesterday, as a matter of fact, and I think to put deterministic and non deterministic testing in layman's terms, I think it's. They said I could run a few tests a million times or I could run a million tests a few times. And he said the latter is going to give me more coverage. Right. It's going to cover more use cases. Whereas you know, right now I think a lot of the tools ecosystem is equipped to allow you to run a few tests over and over again. Part of the reason for that is tests take a lot of work to build. Right. And maintain from release to release. The reason why we turn to traffic, I mean that's one of the reasons. Deterministic and non deterministic testing and transitioning from one to the other. But it's actually to address what we thought were the three primary reasons you are delayed when you're testing. So testing delays that typically involve. Well, first of all, I need to write the test. And what are you doing when you write the test? You're trying to simulate how users interact with your systems. Right. You're trying to imitate traffic that hits your applications. So that's the first delay test. Second one is well, I've been with lots of companies where they build up a gigantic automation framework in whatever tool, then they find out, well, we don't have the right environments to run this in. So if I don't have the environments to run it in, well then how am I going to run early and often? Right. And so, you know, if you can auto generate these environments based off the traffic that you see, you can move faster, you can test early and often. And the third reason is, well, once I do have the environments, the next kind of long pole in the tent becomes data. I don't have the right data. I don't have like, you know, I need to test with Platinum Medallion members. I only have, you know, non medallion members in my test database. Right. How do I get more Platinum Medallion members? Or you know, I've got to actually set up XYZ users before I can even test the delete operation. If they don't exist in the database, I'm just going to get user not found. But that's not really what I'm trying to do. I'm trying to test the deletion operation kind of thing. So it's a combination of those factors. Definitely. And we're seeing kind of the market trend shift that way as well.

Nice. And no, I definitely agree. I did an article once again on the four destroyers of automation and you mentioned two of them. Bad data in bad environments seems to be what everyone's struggling with. So how's your approach different then? Most people when they think of testing, they think of functional testing using a functional tool, maybe like playwright or selenium and then. But I think you take a different approach. You keep mentioning traffic. So what does that mean, traffic? And how is your approach different than maybe traditionally tools that you would use for functional testing?

Yeah, in fact we actually, I mean we're using the word testing, but we don't think of our solution as testing at all. We actually think of it as kind of the anti test. So with most of these testing solutions, the base test is kind of the core element of the framework. Like you've got a selenium or cypress or playwright test, or you've got a postman or a jmeter test. Right. That test is a base element and then you actually copy paste that test and you create more of them for the way we look at the world. Traffic is your base element. So you're taking spans of traffic, we call them snapshots. So you're taking snapshots of traffic and actually going through that traffic and seeing do I like this traffic. Is this representative of day to day interactions that we're seeing right there immediately A it's more realistic, right? Because testing usually is a guess of how I'm going to be encountering my customers. Like so, for example, I don't know if you know, I'm testing the order of basketballs, but really the thing that sells the most is footballs at my retail store. Well, I could be testing the wrong user flow or the wrong sku. Right. And so there's something to be said for testing realistically or replaying traffic realistically. Right. And then secondly, once you do have an idea of what you want to exercise in your application, you have to go build it, you have to write code to write more code. So usually there's a scripting language that's associated with these solutions, but if you can just actually look through lengths of traffic and say, hey, this is a good user flow, I want to use this traffic flow. You can actually take that session and then multiply it and then direct that traffic at your environments. The next kind of differentiator is, well, and the question that pops up at that point is, well, if I'm replaying traffic, if I don't have the right test data setup or the right SKU available, then none of this is going to succeed anyway. And so we've already preempted that by what we do is when we're capturing traffic, we also capture the interactions that are going to the backend systems. And so the way we do this is by using a Kubernetes sidecar so we can work with other containerized environments. But sidecars are very well understood kind of Kubernetes pattern. And so by capturing this traffic, the developer has now got a way to self service, kind of go into the solution and understand, okay, I want to exercise this API. What do I need back end wise environment wise to exercise this API. And then secondly, how do I get it Conventionally you may be doing this in your organization by saying, well, I need to talk to the lead engineer, I need to talk to the architect, I need to talk to the DBA to get this instance going. And then you got to go set it up in a cluster somewhere and or maybe you've already got the cluster, but the problem is everybody and their brother is already in that cluster. So they're using data, they're running their own performance tests which may conflict with yours. You get the idea. So these are just a few ways we're different. By looking at traffic, we can kind of Auto generate the traffic that's hitting your app, then we can auto generate the test environment as well. The idea is we can kind of give you orders of magnitude faster execution.

I mean, that's a lot of people don't realize a lot of the breakup in testing, good testing has to do with assumptions. Like, you make assumptions from beginning all the way to production, and then you're like, oh boy, we were completely wrong. So it sounds like you have some way to listen to traffic that's going on in production and what people are actually doing. And then you take that and then you're able to generate tests that realistically are mimic exactly what's happened in production. Am I understanding that correctly?

Yeah, absolutely.

Nice. So are you able then to create environments based on this traffic then? Because a lot of times you have dependencies on all these other services in production that you may not want to use in your staging or QA environments because it costs money or you don't want to open up a firewall to get to it from these environments. So does it automatically then do the mocking for you? How does that work?

Yeah, that's exactly what we do. You can think of it as auto generated service mocks. So it's kind of on both sides of the equation. So if there's a certain workload in the middle, like your Kubernetes workload, you're trying to test or exercise those backends, there may be one or two, there may be nine or 10. Right. There could be a huge multitude of those. And if you're using a solution like Wiremock or maybe you've got a ninja engineer somewhere who's building them out of JavaScript or Python. Regardless of the way from talking to customers, I mean, they can take anywhere from two days to a week to build each one.

Right.

Manually. But by using a Kubernetes listener, you can actually pick up the traffic. We do it using sidecars again. And so we're actually coordinating the traffic that comes into the system you're trying to test as well as the backend calls you're making. So they're actually synchronized. And this is another huge piece is maintaining the state of these backends in conjunction with the invocations. And it could be APIs, it could be, you know, rest JSON messages, it could be databases as well. So open standard databases like Dynamo or Postgres or things like that. These sorts of databases are often the kind of the delay right. When setting up these environments. So being able to have a repeatable environment that you can spin up over and over again in a new namespace. There's a couple benefits. One, they're short lived, right? It's not like staging environment. I read this article the other day, it's dear staging, I'm breaking up with you. It's not working out. I think it's on DevOps.com or something like that. But it makes sense, right? Everybody's using it and they're kind of stomping on each other's data and things are always broken in staging. So it's like, well, what's the point of staging anymore? So having these short lived environments that actually they, for all intents and purposes they look like real full fledged end to end environments. However, they're actually miniaturized. One of our customers called bubble environments. So they just exist just around that API. And so the idea is you can do these isolation tests, you can run these isolation traffic replays that give you faster validation and aren't as complex to set up. And so I think engineers have a lot to worry about nowadays, right? And sdets have a lot to worry about. And so as cloud gets even more complex, it's kind of tough to figure out, well, what all do I need in this environment and how do I keep it running and do I have drift from production? Right? You want to test like you do in production, like it looks like in production. And if you've got drift, well, you know, hey, it didn't break when we were testing it. But production is different, right? I think how do we minimize that?

So this happened to us all the time, work for a healthcare company and no one knew how to create the full system. You'd have all these people that had their little specialty and you pray to God that in your staging and QA they all had all the pieces that mimicked a production, right? Never got it right. Never got it right. So this sounds like, could this also illuminate, like create a diagram like, hey, did you know in production you're using this service and you have no coverage here? Can it do those types of things for you as well?

Yeah, it can, I think with, you know the latest term is platform engineering, right? It was agile, then it's DevOps and it was platform engineering, right. I don't know who's catching the buck this time, but you know, there's this idea of reducing cognitive load for the developers and testers and there's just so many microservices that it's tough to reason about for humans to. And so that's one of the big features that it's kind of a byproduct of listening to traffic is we can kind of paint a world and show you what the interconnected systems are. And so when we're illustrating these connectivity points, it has actually been quite eye opening for our customers. Like, oh wait, we don't call this system or hey, we only send this call once. No, actually according to the traffic that we just recorded, you make five calls. And here's the conversation. Oh, you know what? This has been in our code for the last six years and we never do. Another interesting thing is monitoring tools like Prometheus health checks or something like that. Oh gosh, it's hitting this API six times a second. And you know what, the observability tools don't show you that, but you're basically inundating your APIs with your own monitoring traffic and you could tune that down and still get the benefits. There's also been cases where we've seen like, oh wait, this illustration is incorrect because this shows our staging environment connected to a prod database. That can't be right. And so we've been like, well this isn't documentation. We're actually generating this from real traffic we're observing. Hold on a second, let me go fix that real quick and come back. So it's been quite eye opening, turning lights on for folks even. There's been another case where engineers are supposed to be checking like a CDN before making a real call. Right? And that's a performance gain.

Right.

And by having our listener on and staging, engineering managers were able to see that happening and like, oh, let's fix that before we go to production.

Now you bring up a good point. I actually hear from people now and then as a they work for enterprise and they don't realize how many monitoring tools are on their production that are adding overhead because they don't know. One team may use new relic, another team, I'm just naming names, may use another monitoring tool and all of a sudden like why is it slow? Like that's a great use case to go. You know what, using four different monitoring solutions for this, they're adding overhead.

Yeah, don't want to DDoS your own stuff, right.

So I guess that gets me to another question fundamentally of what is, what type of testing are we doing? Most people think functional testing, but this looks like also you have a transaction end to end transaction. Say it's taking, I don't know, 10 seconds. And in that 10 seconds it seems like with this tool you can say it's taking 10 seconds, but nine of it is taking place in your this API or in this database. So if you fix that, you automatically fix the whole end to end time for your end user. Is that another use case that you see?

Yeah, we actually don't do kind of more the distributed tracing side of things. I mean, I think, you know, full fledged monitoring tool. We don't claim to be a full fledged monitoring tool, by the way. Could probably show you the delays there. But let's say you did observe that in production and then you wanted to verify that. We have on multiple occasions had teams be like, the database is the delay, and then be like, no, your API calls are the delay. And then they point fingers. Well, if you install our sidecar on the API, we can automatically understand how you're interacting with the database. We can mock the database and zero out the latency. Then any latency you're seeing is all a factor of the API. And so you can prove without a shadow of a doubt. So there's definitely a faster kind of root cause analysis and troubleshooting that happens with speed scale because you can actually shorten your mean time to resolution. The whole reason is you with the ability to mock or generate traffic at will, you can essentially isolate any component that is typically a tightly coupled microservices architecture. Right. So it's like the ability on any plane, you can walk up to the plane, grab the wing and stick it in a wind tunnel is kind of the analogy, and then you can stick it back on. So that capability, I think, is becoming more and more critical in understanding the resiliency and the performance of your cloud architecture. So to get back to your question, we focus primarily on API testing, and so we don't play at all in the Selenium Cypress UI Playwright testing space. Our philosophy is it's kind of the iceberg, right? And the UI is kind of the part you see above the waterline. And then most of your application actually exists below the waterline. And it's APIs. So they're great for programmatic repeated testing. However, if you know one of the microservices blows up, it can cause cascading failures if there's contract changes. Everybody works remotely nowadays. I change a contract and I don't talk to the other team on the rest of the country that could easily proliferate into a problem. So having kind of a centralized dashboard with listeners that you can kind of self service go in there, I want to test this API. I want to test that API. I want to Build an environment for it. I want to simulate the transactions going into this becomes a huge force multiplier, I think, for engineering teams as well as just everybody being on the same page. You know, hey, I want to, I want to look at this API. What is it doing? We're not looking at documentation that's 10 years old kind of thing. And I think a lot of people are focusing on AI and we are too actually to help generate the test. But there's a wealth of information in the traffic that's going through. And yes, I think, I don't think we've covered this yet, but primary concern when it comes to listening to or observing production traffic is security.

It's my next question. I was going to say a lot of people like, I'm not using this tool. I work for healthcare insurance timeout. You're doing what to what, in production?

Yeah, no, absolutely, yeah. So with those teams, we proceed carefully. I mean, we are SOC2 type 2 compliant and we actually have redaction engines that are built into the tool for pii redaction, hashing, obfuscation. And so that's natively built in. Of course, you know, we are happy to do kind of like a technical proof and proceed, you know, crawl, walk, run with, you know, non sensitive data first to prove out the technology. But yeah, it's definitely something we want to proceed carefully with. But we're in a variety of Fortune 100 enterprises already that we've gone through the security scans. And a big part of the simulation though is also after you have just a small span of traffic, you can actually replace the data. So if you capture a two minute span of traffic and it's five users, you can take the message schemas and the general message format and the mocks and augment certain data fields to make two minutes of data look like 10,000, if that makes sense. So you could take that traffic, you can run it at 1x speed as more of kind of a functional regression format. You can literally change up the format of the traffic, replay, multiply it to look like thousands of users, you can take out the delays. And so now it's kind of turned into a load and performance test or a soak test. The same with the mocks, right? You can spin up multiple mocks. So if there's third parties or other internal like authentication APIs or inventory check APIs, you can make them perform a lot faster and understand how the API that you're responsible for, what your API can do at full chat. If assuming the backends were performing optimally. And so I kind of call this the scientific method. You know, you learn this in grade school. So, you know, you water the lima beans with coffee and coke and water see which one grows the best. But then let's say you engineer a new super super bean, right? Well then you want to do the same experiment again and validate that it's better, right? But oftentimes when you go back, you make changes and you go back to test it in staging, the whole staging environment's changed. And so you don't really know if you did an improvement or not. And so having the ability to replay the same traffic with the same backend responses again is actually, I think there's something to be said for that. It's harder to do than people think.

All right. I started my career as a performance engineer. Once again, we do all kinds of performance tests to try to mimic what happened in production. And this is before containers and everything. And it was never got it right. So this is awesome. It sounds like you can actually mimic how many transactions per hour you expect. And you do experiments. You can say, okay, it's a holiday season, Black Friday, we expect a 40% bump. Can it handle it? So it's like chaos engineering. It's almost like resilience testing. You handle all kinds of testing using one test. You could do like a functional test. You could spin it up to do a load test. You could do it for a chaos test. What happens if this service goes away? Am I understanding all these different scenarios for that one?

No, thanks for bringing that up. The chaos is another capability is that once we have the traffic patterns, we can Start to inject 404s. We can inject non responsiveness, we can inject high latency. Like hey, every once in a while we want you to take 30 seconds to respond and see what happens. Do you hold the thread open or, you know, connection open? Do you close it gracefully? You know, does your application just crash and burn? Right. So that's kind of like, I call it extra credit. So you could get through your normal testing cycles and then go for extra credit with the chaos testing with the backends. Because a lot of times like these third party providers don't really tell you. Kind of like especially the sandboxes. A, they're pay to play, right? Sometimes like if you're integrating with a visa or an Amex, you get two sandboxes for free. And they only go up to 10 TPS, by the way. If you need more, you have to pay for it. So you really only have, you're limited by these third party connection, but if you can simulate them at will, you can run them locally on your machine like on minikube or Docker Compose. That's a huge kind of developer efficiency boost if you can simulate. Because all the, all these traffic generators and mocks we build are containerized so they can run anywhere, as many times as you like. And then the other cool thing that you hit on Joe is like there's companies that are doing these experiments as well as trying to figure out if like Graviton processors are faster than intel processors, these cloud providers coming out with new architectures and we've actually done that with our customers. It's like hey, apples to apples comparison. We replay the same exact traffic against an intel cloud instance versus a Graviton and we figured out in one instance like one was 40% faster than the other and they were like, oh we can move, we can re architect and move over to this new one.

So oh my gosh, a lot of times people go down a rabbit hole as we're going to rewrite everything because I have the latest and greatest technology and once again architecture I used to have to test different configurations, see which one would perform better. So before you build out the whole thing, it sounds like you can actually use this like almost as a exploratory session in before you even write like a line of code. Really just do like a little staging setup of what you think and see how it behaves.

Yeah, I mean you could run that if you're running optimization, like code optimizations, you can just run the traffic locally on your laptop so we can replay the traffic locally. If you're you know, re architecting and you just want to turn the workload into a Graviton workload and test that first, you can do that. There's also other things that I think maybe is harder to test with conventional solutions like horizontal pod auto scaling or there's the circuit breaker pattern for microservices architecture. Is that going to work? Are we going to fail over properly those types of things? I could wait for a high load event like the super bowl or I could preempt that and actually run a high traffic event myself and make sure that we're scaling properly. People think that you know, self healing and auto scaling is kind of the silver bullet, but people don't realize like, you know, these horizontal pod auto scaling features take a couple minutes to spin up. And what happens during those two minutes? Are you dropping orders?

Yeah, that's interesting. Once again, every time I talk to them on kubernetes with performance or resiliency always comes to configurations could be different based on your needs for your application. So you can almost use this for configuration testing as well then?

Absolutely, yeah. There's a variety of. I mean really, when we set about building speed scale, it was kind of the continuous testing dream. That was our dream. So I read somewhere like, you know, continuous testing is the ability to understand the state of your quality at will. So, you know, continuous testing the ability to understand the state of your quality at will. So at any given time, do you know how good your code quality is? And a lot of people don't. They have to. I mean, Agile helps, two week sprints helps, but because of the environment and data constraints, it's hard to run tests repeatedly reliably. And so the idea is if you've got these spans of traffic whenever you're doing a code commit or you got a build candidate, you can run 10 minutes of traffic compressed into 10 seconds against your latest build and understand the SRE golden signals which Google establishes as throughput, latency, headroom, an error rate. And so if you get a cursory idea of that and you can run it every time. And by the way, oh, things have changed. Or you know what, the way people are hitting our application has changed. It's a new holiday season. Well, you can just go out and rerecord, rerecord traffic and add that onto your application. You don't have to re script your whole regression library or have, you know, another army of engineers. You know, your existing engineers can focus on the backend features, spend less time building scripts and work on building features.

Yeah, so another issue this reminds me of is developers complaining of waiting around for tests to finish before their code checks in. So this sounds like you're not saying get rid of end to end testing like you said, this is API testing, but at least allows your developers to have a sanity check before it's committed to the next round of the pipeline, it sounds like. So it's a great time saver.

Yeah, absolutely. It's a time saver. Sres win too, I think because sres are like, well, am I going to burn on my error budget? Am I going to be sticking to my, you know, slis and slos? The tester said they tested it, so I just have to go on that. Well, if you run, you know, 10 minutes of traffic against your app, you can actually say, hey, your max TPS here used to be 80 TPS, but for some reason, the code change that you just did dropped it to 60 tps or hey, your latency went from 20 milliseconds up to 70 milliseconds with this last code change. Something changed. So even if it's just making better educated decisions about releases, that can be quite educational, I think, and prevent these outages.

Absolutely. So most of the people listening to this will probably mostly have a tester background, so they'll be familiar with tools like loadrunner, JMeter, postman type deal. I think if you gave all the reasons how this is different, but I just don't know if we made the connection, how much different they are. Like, like, would you compare, how would you compare this to say a load runner or a postman? Does it replace it? Does it work together with it? Is it completely different? Like, how would you explain it to someone that's a tester, basically?

So I think for like API development tools like Postman or Stoplight or Hopscotch, things like that, I think it's very complimentary. In fact, we can ingest postman collections and we can actually take traffic recordings. We can export to postman collections as well. So a lot of times when you're building these collections, it can be quite a headache. Oh, what are the headers? Like, how do I get this message? Right, so it actually sends back a response. It's a little bit of a guessing game, trial and error. So if you can record traffic and then export to Postman collections can be a huge accelerator for these engineers. So it's complementary to those. Compared to load testing tools like JMeter or Locust or K6, we have. The majority of our customers are using tools like that. And basically there's so many microservices now, they're in the hundreds that they just can't build for every single microservice.

Right.

I don't know if you. Have you ever heard the pets versus cattle analogy?

Yes.

Yeah. So like, you know, the cloud shift, like, hey, the servers now are cattle, right? Not pets. You don't like, you know, curate them one by one and care for them. Like, you just have huge, you know, horde of servers now big tests are going through the same shift, right? You don't curate each one of these tests until I update it. And hey, there's a version change. I update it with new request response first. Now just go out and grab more traffic, see if it's got the stuff that you need and then run the traffic. So with the Loadrunner or JMeter or K6 scripts, like, basically we can run a lot more load tests by capturing traffic and then stressing your application. We take that and multiply it. We actually can grab our traffic. And we've had some requests like customers that say, hey, we're going to try out speed scale, but we've got a big K6 practice already. So we actually built a K6 exporter so we can capture traffic and then just dump out a whole slew of K6 scripts. So even if it's for just that value, add so many K6 scripts in fact that you know, they couldn't all be uploaded to K6 Cloud at once. I just don't think they were expecting that volume. So we can be an accelerator in that regard and you can just use us for our mocks. But yeah, it's kind of a different mindset, if you will. It's like, you know, like I said, the anti don't test replay traffic.

Is there any better way to get the source of truth production what your users are experiencing? It seems like the most logical thing, but counterintuitive to the way we've probably been developing software for at least as long as I've been been around.

Well, you know, I think the mindset's changing. I've talked to several business executives and technology leaders who have said like, you know, really testing is just all a dress rehearsal for production. Right? Production's a real deal and we're just preparing for production. So if I can shift production left or I can simulate production conditions, that's kind of the whole point really. And I don't think people realize a solution like this exists. There actually are open source alternatives. There's Go Replay and vcr I think curl and hey are kind of like the one by one transaction versions of it. You can curl a transaction you saw on Prod, then that's great. And so it's kind of like that. But we've combined like a traffic replay solution with a mocking solution like wiremock or service virtualization. And so having both of those two kind of value props in one solution is really what the acceleration comes from is the velocity to move quickly.

So another question that came in mind, like I said, I haven't tried this yet. Do you need to record traffic using speed scale? How does it work? How does that process work?

It's definitely the fastest way and specifically recording in Kubernetes is the fastest. That's kind of Kubernetes is a lot of the hooks to ingest traffic. It's very conducive to it. But you don't have to record. In fact, we think the ways of sending us data are going to be multiplied. It's going to be commoditized. Like we keep a close eye on ebpf open source. We actually can ingest files. We also have a browser recorder so like you can install us on a browser. We can capture basically a har file that looks at all the HTTP transactions. So we don't do browser like dom, event like mouse clicks, recording, like you know, conventional UI testing tools. But we do have a way to capture UI interactions and so that's what we capture. And really we feel like, you know, our IP is around how we interpret that data, parameterize that data and then make it replayable.

And that's the secret sauce. I think that's the most important piece. So love it. Awesome.

Definitely.

Or K neet before we go, is there one piece of actual advice you can give to someone to help them with their production? Kubernetes, automated testing efforts and what's the best way to find contact you all learn more about speed scale.

I think oftentimes when people try to improve the performance and resiliency, they feel like they have to master the discipline. Like I have to be a performance testing expert before I set out. Like I need to learn and consume all the information, get certified really. I would focus on the most critical API that you have, if it's the checkout API or maybe it's your inventory lookup API, the one that's kind of like the slowest and mock up an environment for it. You don't have to use any mocking solutions, just like just figure out how you can simulate or you know, have, have the repeatable like a terraformed or you know, YAML for that environment and spin it up repeatedly. And I think if you do that then you can repeatedly run tests, right? And it doesn't have to be. I'm not advocating like any sort of commercial off the shelf or open source solution, but just focus on the repeatability because stable and predictable environments can get you a lot further in testing than writing a whole slew of test scripts. And yeah, you can find us@speedscale.com and we've got tons of blogs that are devoted to kind of how does it differ from this or how does it differ from that. It's really kind of a paradigm shift using traffic instead of testing. It's like I said, we're kind of the anti test but we provide all the same benefits. So people are like, well how do I update the tests? And how do I maintain the tests and stuff like that? You just grab new traffic. I mean, we can patch snapshots with request response pairs and post main collections if you've got new functionality, but it's just a complete mind warp. So yeah, happy to talk about it. Obviously I'm quite passionate about the subject.

Thanks again for your automation awesomeness. The links to MD value we covered in this episode. Head on over to testguild.com a482 and if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguilds.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skill skills or solve a problem for the guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.