.webp)
Ole Lensmar: Hello and welcome to another episode of the Cloud Native Testing podcast. I'm your host Ole Lensmar, CTO at Testkube, and I'm thrilled to be joined by one of the newest people joining Testkube itself, Lakshmi. Welcome.
Lakshmi: Thank you, Ole. It's super exciting to be a part of Testkube. I used to be the senior-most person in my previous company, and joining Testkube feels like joining a place where I'm mentored by veterans in this space. I'm super excited to be a part of something bigger.
Ole Lensmar: Great. I'd love to hear a little bit about your background and how you got into this space. You teased something just as we were preparing for this that I want to get back to, but first, why not give us a short background of where you are and your thoughts on the cloud-native testing space?
Lakshmi: For sure. I did my master's in electrical engineering, which was very different from what software is today. I worked a lot on the hardware architecture side from a memory perspective, and I naturally got attracted to performance engineering. That involves working very closely with how your memory works and how your application restores memory after a load test is done. That's how I got pulled into the testing space.
Back in 2015, people were adopting the cloud and moving away from physical servers. I was working with Comcast at the time, and as we moved into the cloud world, people started thinking, “Now we have auto-scaling enabled. Do we actually need performance testing? The server can pretty much handle all the load.” We went through a couple of releases without performance testing and ended up with a cloud bill that was insurmountable—pretty much beyond what we expected.
That’s when they realized we still needed to catch memory leaks and identify bottlenecks. We went deeper into performance engineering, realizing that as technology evolves, testing is going to be a core component rather than being eliminated. I feel the exact same way about the AI evolution. As people deploy applications at unimaginable speeds, testing should be faster and complement the development cycle rather than being left behind.
Ole Lensmar: It feels like testing is always easily left behind. Like you said, with performance testing when the cloud was new. Now, I'm sure there are people who think, “Well, if AI will just generate perfect code, we're not going to need any tests.” I don't think anyone senior in the QA world believes that; at least I'm skeptical. But you said something really interesting earlier. You said that testers make the perfect "vibe coders." I'd love to hear you elaborate on that statement.
Lakshmi: When the ability for AI to write code was introduced, it changed things. I don't come from a traditional coding background. I was more into the testing space where finding bugs—or pointing fingers—was more fun than writing that piece of code and getting pointed at!
When AI came in, I started building stuff on my own using prompting because I knew exactly what I wanted to build. The biggest barrier used to be the language between me and the computer, but with AI, that barrier was removed. Jensen Huang rightly said back in 2020 that English is going to be the new programming language. A lot of people laughed at it, but now we know it’s technically true. As a matter of fact, I don't even use my keyboard a lot at work right now. I have my mic and use a software called Whisper Flow to talk to my computer. It's like living in the future.
The first app I built was a translator. My daughter was born in North America and only speaks English, while my parents back in India don't speak English. I wanted a natural translator between them. Coming from an electrical engineering background, I used a Raspberry Pi and combined the programs. I didn't even open my IDE while building this! There were so many bugs, but I got it to work. My daughter could speak into it, it converted to Tamil for my parents, and their responses converted back to English.
Seeing a tangible output without programming skills made me realize English truly is a programming language. However, there were gaps, and that's where I had to wear my testing hat. I had to go through several iterations to test out positive, negative, and edge cases. I wrote a blog post about why testers make good vibe coders: we always try to think about where things could break. Testing isn't just creating; it's making sure what you've created works for all possible cases.
Ole Lensmar: That's an amazing story, and I'd love to see that thing in action. Were you thinking of doing any automated testing for what you built, or was the technology not there yet?
Lakshmi: The technology wasn't there at the point. Instead of building everything from scratch, I went to Hugging Face and used a pre-deployed model to convert one language to another. I did spend some tokens on API keys—I've spent about $400 to $500 per month on AI over the last three years—but I consider that an investment. Things are going to evolve; you either travel along with it or you'll be left behind. I had the model deployed locally, and things worked seamlessly. It solved a real-world problem for me without needing to buy third-party software.
Ole Lensmar: I want to get back to corner cases. My experience using AI to create tests is that it's actually pretty good at thinking of all the variations and things that could go wrong—especially for developers who might not always consider those paths. Do you find that AI is good at helping create more comprehensive test suites?
Lakshmi: For sure. At my previous Y Combinator-backed startup, we realized we aren't trying to replace testers; we're giving them a superpower. If developers are using AI to push code faster, testers should use AI to complement that speed.
You aren't reinventing the wheel; you're building a vehicle on top of the wheel you've already invented.
Ole Lensmar: That's super interesting. If you ask AI to analyze a commit and generate scaffolds for untested changes, a human still has to post-process them to ensure they test the right thing. If you ask AI to generate tests based solely on the code, it's going to generate tests for what the code does, not necessarily what it's supposed to do. If there are bugs in the code, AI might just enshrine those bugs. It's super important to bring in context from your test management tools or pull requests so AI understands the actual requirements.
Lakshmi: Totally, context is the key. Developers are already automating things just because they have the ability to do so now. Testers—who actually know what to test—should use AI's brain combined with that context.
At Testkube, the key aspect is that the core concept of testing remains the same. We aren't trying to force a new methodology. You might use a deterministic locator-based tool, or you might use a non-deterministic tool that lets an AI agent loose on your application to navigate a checkout flow. There is no right or wrong in testing; the output is always binary (pass or fail). It's all about combining creativity, domain knowledge, and the right tools.
Ole Lensmar: I'm intrigued by the non-deterministic testing approach. If you tell an AI to simply "validate the checkout process," it seems like it could take a while and be expensive from a token perspective. But maybe it evens out when compared to the manual effort of creating deterministic tests?
Lakshmi: Exactly, and it depends on the use case. In e-commerce, if your checkout flow breaks, you're losing direct revenue. Companies are totally okay with spending six figures on a non-deterministic testing tool because it compliments their deterministic tests. The AI agent might navigate to the checkout flow from a random product page instead of the main page, finding paths you didn't script.
You can also give the AI agent a specific persona. For example, you can tell the agent, "You are a 35-year-old mother looking to buy a mattress for your kids." By default, the agent assumes this persona and looks for bunk beds in a furniture store. The tester uses the AI's "brain" to test complex, real-world behaviors.
Ole Lensmar: That's fascinating. Using outlier personas can help you track down usage scenarios you weren't mindful of and improve the overall experience.
Moving downstream, a lot of talk has been about creating and executing tests. But what about analyzing the results? When you have a flaky test, is it actually flaky? If you give AI context via MCP servers—your source code, APM tools, logs, and infrastructure—it can get a holistic picture and identify the root cause. Do you see adoption for that?
Lakshmi: That is exactly the bigger problem right now. Creating tests is easy, but what value do I get out of the results? If 10 tests fail, my goal as a tester is to find out why. Did my test fail, did the application fail, or did a downstream service connection fail?
With Testkube, you can spin up failure analysis agents. We give the customer the ability to modify the agent with custom prompts to analyze logs exactly how they would do it manually.
Ole Lensmar: Definitely. Testkube comes with built-in agents and templates, but we can't anticipate every tool or infrastructure setup a customer has. We want to make the simple things easy and the advanced things possible, so customization is key. Since we have many enterprise customers, we also support bringing your own LLM and running in air-gapped environments. You don't always need a frontier model; you can get very far with an older or local model for log analysis, which helps manage token costs.
Lakshmi: To close the loop: once analysis is strong, the next default path is true self-healing. If a login button locator changes and breaks the test, the agent could go into your test repository, understand the failure, update the test script, and rerun it to verify the fix. When testers report a bug after that loop, developers will know it's a genuine application fault, which makes the tester much more reliable.
Ole Lensmar: I'm always a little cautious about self-healing—I still want a human in the loop. The AI should ideally fix the error, run the test, and then open a pull request saying, "Here is what I did to fix the test." Then a human can verify it. But as models become more deterministic, that definitely feels like the obvious path forward.
Awesome. Thank you so much for joining, Lakshmi. It's been fantastic to talk to you, and it's going to be amazing to work with you. Thanks to everyone listening, and looking forward to the next episode.
Lakshmi: Awesome. Thank you all.