Quality People: Minh Huy Dao on Testing the Tools Testers Use

A conversation with Minh Huy Dao, Senior Quality Engineer at Katalon, on what changes when the people using your product are testers too.

The first five entries in Quality People came from people who mostly look at testing tools from the outside: Huy Tieu on harness engineering, Gastón Marichal on adoption, Fariz on fundamentals, Maryna Didkovska on governance, and Rahul Parwal on filtering noise. This entry turns the camera around. Minh Huy Dao tests a product whose users are testers, which means his customers spot the same things he does, and often sooner.

His route there was not planned. He studied at PTIT, the Posts and Telecommunications Institute of Technology in Vietnam, where software testing is not part of the standard curriculum. From there he moved through a senior QA role at a telehealth company, consultancy work across client codebases, and on to Katalon, where he now works as a Senior Quality Engineer on a product team.

Getting Into Testing, Almost by Accident

Asked how he ended up in quality engineering, Minh Huy is candid that it was not a grand plan. "I think it was a mix of luck and timing. I first heard about software testing through an older student at PTIT, but at the beginning I was not particularly interested because I did not really understand what a tester did."

The nudge came from a friend who had started earlier. "Someone in my group encouraged me to try an interview. I passed, and at that time the telecommunications job market was not looking very promising, so I decided to give testing a real chance. I started almost by accident, but I stayed because the work gradually became more interesting than I expected. It gave me a way to combine technical thinking, curiosity, and problem-solving, and I have been in quality engineering ever since."

That combination still shapes his day-to-day work at Katalon. He looks at the product from several angles at once: understanding requirements, designing and executing test cases, investigating issues, and working with developers and product teammates to stop problems before they reach users. He also spends time building tools and frameworks that make testing more efficient and repeatable for the rest of the team.

"For me, quality is not only about finding defects," he says. "It is about helping the team deliver with more confidence."

It is a definition worth holding onto through the rest of this conversation, because almost every lesson he describes comes back to the same idea: the tester's job is to give the team a clearer picture of risk, not simply a longer list of bugs.

The Blind Spots You Don't Know You Have

His first senior QA role was at a telehealth company, where a defect can mean a missed consultation or a delayed prescription. He pushes back gently on the idea that this made the work more important than any other domain.

"I do not think one domain is inherently more important than another. Quality matters in every product because every product affects someone's work or experience. In healthcare, the consequences can be more visible, but the responsibility to understand what we are building is the same everywhere."

What made that project hard was not the stakes but the history. The product had been acquired, which meant it arrived with existing behavior, past decisions, and context nobody on the new team had fully lived through.

"There was existing history, context, and behavior to learn, which made it harder to know every decision behind the system. The main lesson I took from it is that testers need to truly understand their product before they can design the right test flows or make sound decisions about test coverage and quality."

It is a useful reframe for any team inheriting a legacy system or a codebase from an acquisition. Coverage gaps are rarely random. They cluster in the areas nobody on the current team fully understands, which is exactly where a structured test strategy and honest risk mapping earn their keep.

What Consultancy Gives, and What It Takes

Before Katalon, Minh Huy spent time on the consultancy side, moving between client codebases on shorter engagements. He describes the upside plainly.

"Consultancy taught me to adapt quickly: understand a new codebase, domain, and team in a short time, then identify the biggest quality risks. It also showed me that there is no single testing approach that works for every product."

That second point is easy to underrate. A tester who has only ever worked on one product can mistake that product's habits for universal best practice. Rotating across clients forces you to see which practices travel and which ones only worked because of a particular team, stack, or release cadence.

The cost, in his view, is depth. "Short engagements make it harder to fully understand a product's history, users, and the long-term impact of your work."

Read alongside his telehealth lesson, the two experiences form a pair. The acquired product taught him that shallow understanding creates blind spots. Consultancy taught him how to build understanding fast, while also showing him the limit of doing it fast. Put together, they explain why he ended up somewhere he could go deep on one product while still seeing how many different teams work.

Why He Chose a Company That Builds Testing Tools

The move to Katalon was not something that just happened to him. "It was a deliberate decision. Several things led me there, but the simplest reason was that I felt I could contribute more to a product when I was also one of its users."

The other draw was exposure. Because Katalon's customers span many industries, the work gives him a wider view of testing than a single product team usually can. "Katalon offered an opportunity to work with customers across many different industries. That exposure helps me learn much more about testing methods, frameworks, and the different challenges teams face in practice. I saw it as a chance to broaden my perspective beyond a single product domain while still doing work that is closely connected to my own daily experience as a tester."

"So when the opportunity to join Katalon came along," he adds, "I did not hesitate to make the move."

Asked whether his definition of good quality changed once his users became other testers, his answer is short and firm: it did not. "For me, the definition of good quality does not fundamentally change from one product to another. As testers, we always want to maintain the highest possible quality, supported by clear quality metrics and a real understanding of what users need."

That consistency is worth noting. The context changed, from patients to professionals, but the standard he holds himself to stayed the same: measurable quality, grounded in what the people using the product actually need.

Testing a Tool When Your Users Are Testers Too

There is a particular strangeness to testing software that other people use to test software. Minh Huy finds it more interesting than strange.

"I am both a tester and a user of the product. I understand the daily work, frustrations, and expectations that testers bring to a tool like this, which helps me test more practically and contribute ideas beyond simply finding bugs. I also learn a lot from customers and the different ways they approach their work."

That dual role shows up most clearly in the things he catches. "There have been many times when I have looked at a feature and thought, 'A tester would not use it this way,' or 'A tester will immediately look for this edge case.' That mindset changes my role: I am not only there to make sure the product has no bugs. I am also a user who should speak up when the workflow does not feel right."

There is also a pressure that comes with the territory. "Our customers are testers too. They are colleagues with different perspectives and often a very sharp eye for quality. That creates a kind of hidden pressure, but it is also what pushes us to make the product better."

For anyone testing developer tools, internal platforms, or anything used by technical people, the lesson carries over. When your users know how software breaks, a workflow that is merely functional is not good enough. The tester's job expands from verifying behavior to representing how an expert would expect the product to behave.

Pushing for a Connected Flow, Not More Features

Because he uses the product all day, Minh Huy is in a position to push for changes born from his own frustration. He is quick to share the credit. "It is hard to point to just one example, because many of the improvements come from shared frustrations and ideas across the Quality Engineering team, not only from me."

The example he points to is the overall Katalon True Platform flow. "We saw that testers often had to move between separate tools or isolated features to complete their work. So we pushed toward a more connected, end-to-end experience: a systematic flow that supports testers from the beginning of their work through execution and reporting, rather than leaving them with disconnected functions."

True Skills, the open-source skills library that connects AI coding agents to True Platform, is his second example. "We recognized that the way testers use agents in their everyday work could be connected more directly with the True Platform. Bringing those experiences together makes the product feel more practical and useful, instead of treating AI as a separate feature." (For the technical background on how True Skills is packaged for different agents, see Katalon's write-up on the Agent Plugins standard.)

Both examples share a theme. The frustration he describes is rarely a missing feature. It is the friction between features: the context switch, the export, the separate login, the AI tool that lives off to one side. Testers who use their own product every day are well placed to feel that friction first, which is exactly why their feedback is worth routing into product decisions rather than filing away as bug reports.

Code, Low-Code, and AI: Complementary, Not a Trade-Off

Minh Huy came up writing WebdriverIO and JavaScript. Today he works with low-code and AI-assisted testing. He does not accept the framing that one replaces the other.

"I do not see this as a trade-off. I see it as complementary. As testers, our responsibility is to protect quality while keeping pace with product development. Low-code tools and AI can help a lot with that by reducing repetitive work and helping us move faster."

His coding background, he says, is exactly what lets him use those tools well. "It helps me understand the limits of low-code tools and AI. When needed, I can troubleshoot beyond the tool's boundaries, write custom solutions, or contribute feedback that helps the product team improve the tool itself."

Asked what a tester should still learn to write by hand, he declines to draw a fixed line, and explains why. "To be honest, it is hard to draw a fixed line around what testers must always write by hand, especially as AI evolves. But I believe the best approach is hybrid: testers should understand the fundamentals of code and how automation works, then use tools and AI to accelerate the work."

The payoff, in his view, is time for the parts of testing that no tool does for you. "That saves time for the higher-value parts of testing: understanding risk, exploring the product, and making better quality decisions."

It echoes a point Fariz made earlier in the series: fundamentals are what let you judge the tool, rather than the other way round. For testers mapping out what to learn next, Katalon's guide to the test automation engineer career path covers the skills that sit underneath both approaches.

Why Zero Bugs Isn't the Release Bar

Asked what he believed about testing early on that he has since changed his mind about, Minh Huy points to the relationship between bugs and release speed.

"Early in my career, I focused heavily on pass rates and the number of bugs found. Before a release, everything had to meet the expected numbers. Otherwise, the team would go back and fix everything before moving forward."

Over time, he saw what that cost. "I learned that this approach can be expensive and slow, and sometimes it does not match what users or the business actually need. Quality is not about eliminating every possible bug before release. It is about finding the right balance between the number of issues, their severity, their real impact, and the value of releasing."

That is why he treats priority as a separate call from severity when reporting a bug. "Severity tells us how serious the issue is, while priority helps the team decide when it should be addressed in the context of users, the product, and the business."

The distinction sounds basic, but it is where many release debates go wrong. A team that only tracks severity tends to either block releases on issues nobody will hit, or wave through issues that matter to a key user group. Separating the two, as covered in Katalon's guide to defect management, turns a bug count into a release decision the whole team can reason about.

What He'd Tell His Younger Self

Asked what he would say to himself fresh out of PTIT, with no testing background, Minh Huy keeps it simple. "Keep learning, and keep trying things beyond what feels familiar."

He is honest about the periods when he did not. "I sometimes regret the periods when I stopped actively building my knowledge. Every profession requires continuous learning, but in IT and software it matters even more because everything changes so quickly. Taking a long pause can feel like moving backwards."

The second piece of advice is about fear. "I would also tell my younger self to try the things I am curious about, rather than letting fear or assumptions set the limits."

It is a fitting note from someone whose career started with an interview he almost did not take. The through-line across his answers is consistent: understand the product deeply enough that blind spots have nowhere to hide, speak up as a user when something feels wrong, and judge quality by its real impact rather than by a count.

In His Own Words

If you are working through the same questions on your own team, the rest of the Quality People series is a good place to compare notes. You can follow Minh Huy's work on LinkedIn.