My name is Ilya, and I’m a QA Engineer. To be exact, I’m the only QA on my team. You know what that means. I handle regression, new features, talking to devs, and explaining “why this broke again.” But this isn’t a story about starting automation from scratch. This is a story about inheriting it. The “Gift” I Got Tired of Fixing When I joined the team, I was given a “gift”: a big, heavy, and complex automation project. “Great,“ I thought, “at least something is already here. I’ll just clean it up.” Oh, how wrong I was. I spent the first few months not testing, but just trying to get this project to run. I updated libraries, rewrote entire modules, and fought with the environment. And you know the worst part? Even after all that work, it was still unstable. The main pr…
My name is Ilya, and I’m a QA Engineer. To be exact, I’m the only QA on my team. You know what that means. I handle regression, new features, talking to devs, and explaining “why this broke again.” But this isn’t a story about starting automation from scratch. This is a story about inheriting it. The “Gift” I Got Tired of Fixing When I joined the team, I was given a “gift”: a big, heavy, and complex automation project. “Great,“ I thought, “at least something is already here. I’ll just clean it up.” Oh, how wrong I was. I spent the first few months not testing, but just trying to get this project to run. I updated libraries, rewrote entire modules, and fought with the environment. And you know the worst part? Even after all that work, it was still unstable. The main problem was flaky tests. Every “red” build in our CI turned into a detective story: is this a real bug, or did a selector just break because the page changed by one pixel? Spoiler: 9 times out of 10, it wasn’t a real bug. It was just a brittle test. I got tired of fixing. My job is to break the product, not to fix the tests. “What if...?“ (The Idea) One day, looking at another “red” build, I realized: as the only QA, I can’t afford to spend my time maintaining this brittle system. I sat there thinking. We live in an age where AI can write code and explain complex topics. Why can’t I just ask it: “Hey AI. Go to mysite.com/login. Click the ‘Login’ button. Type ‘test@test.com’ in the ‘Email’ field. Check that you see ‘Welcome’ on the page.“ Why am I hunting for selectors by hand if an AI could “see” the page like a human and adapt to changes? Of course, it’s not that simple. A “general” AI (like in a chatbot) knows nothing about the DOM, what “click” means, or my specific website. But what if I could take those powerful AI APIs and build a “bridge”? Create a service that translates my plain English into actions a browser can understand? So, I decided to build it myself And that’s how Debuggo.app was born. For the last 3 months, I’ve been building this tool alone, in my spare time after my day job. Let me be honest: I’m not building my own neural network. I’m a solo developer, not a giant corporation. My job is to be an integrator. I take powerful, “general” AI APIs and build smart logic around them. I’m teaching them to understand the context of web testing. I’m teaching them how to find buttons even if the id changed, and how to type text into fields even if the layout is tricky. My goal is to build a tool that lets me (and you) write automated tests as fast as we write test cases in a notepad. Why am I writing this? (I need your help) I’m building Debuggo because it’s the tool I desperately need in my daily job. I’m building it for myself and for people like me—QAs (or devs) who never have enough time to maintain monster frameworks. But I can’t build it in a vacuum. As the only QA, I only know my problems. I need to see how it works on your websites. I’m opening up the beta. If you know the pain of “flaky” tests. If you’re also tired of maintaining an old automation project. If you’re willing to try something new (and maybe a little rough around the edges)—I would love to get your feedback. Check out https://debuggo.app and sign up for the beta. Let’s try to automate this automation. Together.