Somewhere in the world right now, a young person is opening edbot.ai and starting a lesson. Maybe they’re building English skills to qualify for a better job. Maybe they’re working through a course late at night after work. They’re not thinking about software quality. They just need the experience to work and to actually help them get where they’re going. That’s what I think about now when I test.
But it took me a year and three different ways of working to get there. Through manual testing, then automation testing, then AI-assisted workflows, the tools kept changing. The biggest shift wasn’t in what I used. It was in how I defined quality.
Automation test running against Edbot
Quality Is More Than Finding Bugs
Here’s something that took me a while to accept: a feature can pass every test and still be a problem.
I’ve been in situations where buttons worked, pages loaded, no errors showed up and yet something felt off. Did this flow make sense to a learner? Would someone know what to do next? These aren’t things that show up in a test case, but they matter.
At Solve Education!, this hit differently because we’re building for learners, not just users. A confusing step in the learning journey isn’t just a UX problem, it can mean someone gives up before they get to a skill or livelihood outcome. That raised the stakes for me.
One case that stuck with me involved a Speech-to-Text feature in our English Speaking course. Every functional test passed, the recording worked, the system processed the input, and the logic behaved exactly as designed. But weeks later, a report came in through our customer care feature. Users were frustrated, something felt strict enough that even reasonable attempts were being marked incorrect. The feature wasn’t broken. The spec was met. But the experience didn’t serve the learner. And no test case had caught it. For someone using Ed to build English speaking skills as a step toward better job opportunities, that frustration isn’t just a UX issue, it’s a barrier to the outcome they came for.
So I started asking different questions during testing: Does this feature support what it was meant to do? Does it fit the learner’s flow? These aren’t always easy to answer, but they’re the right ones to ask. At Solve Education!, quality assurance isn’t just about keeping the platform stable. It’s about protecting the learner’s momentum, because momentum for someone working toward a livelihood is the whole point.
Ed’s speaking course – one of the areas where a “passing” test still left open questions.
What AI Changed And What It Didn’t
When I started using AI in my workflow, I thought it would simplify things. In some ways, it did. When a Product Engineer shares a PRD, I can now use AI to help break down requirements, draft test scenarios, and catch edge cases I might have missed. Things that used to take hours can happen in minutes.
But here’s the thing: AI generates outputs. It doesn’t understand the context.
A test case might look complete on paper but miss a business scenario that wasn’t in the requirements. An automation script might pass every run while quietly skipping a requirement two stakeholders interpreted differently. AI doesn’t catch what people do.
So AI made me faster, but it also made me more aware of where human judgment still matters. You still need to understand the intent behind a feature, not just the spec. For us, that intent always comes back to the same place: a learner who showed up to build a skill. Every test scenario I write, AI-assisted or not, is ultimately a question about whether we’re keeping that promise.
How AI changed the way I create test scenarios.
What I’d Tell My Earlier Self
Looking back at my first year in QA, the tools changed a lot, manual testing, automation testing, then AI. But the goal stayed the same: help build something that actually works for the people using it. At Solve Education!, that means building for a learner who may only get one real shot at improving their livelihood. That context makes the work feel different.
The number of bugs I found, or tests I passed, was never the real measure. The real question was always: does this feature do what it’s supposed to do, for the people it’s supposed to serve?
AI will keep changing how software gets built and tested. It’ll make teams faster and more efficient. But the part where you ask the right questions, understand the context, and check whether something truly delivers value, that’s still on us. At Solve Education!, that responsibility feels even more concrete. We’re working to close the gap between education and livelihood in an economy that’s changing faster than most learning systems can keep up with. Every feature we ship is a small part of that. And quality assurance, done right, is how we make sure those features actually move people forward, not just pass a test.
That’s what QA means to me now.