How I Use AI to Test My App Like a Real User with DevAssure Transcript, AI Summary & Key Points

00:06 Imagine this. You write an end-to-end test, it passes, everyone's happy. Then someone moves a button or renames a label, and the test goes red. Nothing is actually broken. The test is just brittle, and you end up spending more time unbreaking your tests than you spend writing them. If you've done this for a living, you know exactly the feeling I'm talking about.

00:32 Now, since recently, I've been using a tool called Dev Assure that takes a very different swing at the problem. And I like it. I like it so I want to show you exactly how it fits into the way I work. So, let me start with what it actually is. Dev Assure is an AI testing agent. The whole bet behind it is that you shouldn't be sitting there writing and babysitting test scripts at all.

00:58 You describe what your application is supposed to do in plain English, and an AI agent figures out how to test it. It opens the app, it clicks through it the way a real person would, and it decides whether what you described actually happened. There are no selectors to handcraft, no page objects to maintain. They call it scriptless, and um that word turns out to be the whole point.

01:24 The promise that rides along with it is roughly zero flakiness and roughly zero maintenance. And for anyone who's lived that brittle test grind, that is a that is a very loud promise. Now, Dev Assure does a lot more than I personally lean on, and it's worth seeing the surface before I narrow it down. It plugs straight into the editors I might actually be working in, like VS Code, Cursor, and WinSurf.

01:51 I don't use those. You might. It hooks into CI systems like GitHub Actions, GitLab, and CircleCI. It ships as an agent skill you can drop into cloud, so a coding agent can drive it directly. Now, that's the part I care about. It connects out to the tools teams some people already live in like Jira, Figma, and TestRail. And and beyond straightforward web journeys, it covers visual checks, accessibility, and even Flutter web apps.

02:21 It's a broad product. Now, I don't use all of that. The way I use DevTools is narrower and honestly, maybe a little against the grain of how they pitch it. So, let me show you how my actual setup works, looks like, and then you can decide where it fits for you. I let the whole crew of agents build features for me with one agent whose only job is to prove a feature actually does what it's supposed to do exercise from the outside the way a real person would use it rather than checking the shape of the code underneath.

02:56 DevTools lives right next to that world. I don't drop it into the inner loop where all my agents are writing and rerunning tests every few seconds because that work needs tests that are fixed in my repo and completely deterministic. DevTools leans the other way. Its headline feature is self-healing. When the app shifts underneath a test, when a button moves or a label gets reworded, the test adapts itself in real time instead of breaking.

03:23 That's That order there is a wonderful property for a maintenance-free acceptance suite and exactly the wrong one for a red face of TDD that has to stay red until the code is fixed. So, I run it beside my inner loop, right? As a separate AI-driven acceptance net. It's a thing that clicks through my app like an impatient user and tells me in plain English, in plain language, whether the product still does what the docs say it does.

03:51 Now, here's the part I truly like. A Develocity project is just a folder of YAML, plain text you write by hand in plain English and commit to your repo right next to your code. This is the whole tree for my setup. Now, the file at the top, up.yaml, is where I tell the agent what it's actually looking at and set the rules it has to play by. A description gives it context on what the app is and what it does, and a short list of hard rules keeps it really clicking agent scope to what the tests are meant to do.

04:26 And here's the heart of it, the tests themselves. Each file under test is one feature, and each scenario is just a numbered list of plain English steps with a priority from P0 down to P2 and some tasks. I would write them as the acceptance spec derived from what the product is documented to do, not from poking around in the UI source code. So, the YAML ends up reading like the product's own user manual.

04:53 Now, what I really, really, really like about writing tests writing them this way is that I can be honest about the seams. Now, what you are about to see or what you're seeing is from around when I started using Develocity, and it's why I kept using it. I don't run the suite myself. I hand it to an agent in plain English. And there we go. That's That's the whole instruction.

05:18 So, it takes it and and it goes. It works and works and works. And here Actually, here's one honest knock on the tool. It's It's slow. A bit on the slow side. This run took the better part of 15 minutes, but an agent is running it, not not me. So, slow is not such a big deal, right? Slow barely costs me anything. It just annoys the agents. Okay, so, when it's done, it reports back.

05:45 14 scenarios in this case, and a session score, and it opens the report like I asked. And the report is what I truly care about. Every scenario is scored, and it's not a wall of green in this case. All have passed at 100, and a bunch of others came back at 25, right? Some failed, which was to be expected. This is This was my first run, this recording.

06:09 So, on the first run, it went straight at features I never functionally tested really, and found problems. I opened red, three failures, and all because query endpoint has no fixture. And that's the That one is on me. It's It's my mock. But the agent traced it to the exact route, and told me plainly what broke. It would If this was a second run, third run, when I already established all the tests, it would catch real bugs the same way.

06:40 And if I want to see what it really did, I can replay the whole run. Every action, console error, and network call. The 501 right over there, each with a snapshot of my app at that very moment. So, do I like it? Yeah, I do. The scriptless, plain English authoring generally makes the tests read like a specification, which means that they double down as documentation.

07:05 It doesn't quietly rot the way comments do. The agent is good at the messy, human parts of clicking through a real app. And it doesn't replace other tests I run underneath it, right? It complements them. It is catching the one thing that they're often missing, whether the product actually works end to end, and in a way that someone really would be using it.

07:33 It's like a black box acceptance net that thinks like a user and writes its tests in plain English. Test Watcher has earned its place in how I work. And that's that's sentence I don't get to say about most testing tools. Thank you for watching. See you in the next one. Cheers.