The phrase QA engineer covers a remarkable amount of ground. It can mean the person who clicks through a checkout flow on a Friday afternoon and signs off on the release. It can also mean the person who, three weeks before that release, noticed that the order-service was emitting a subtly wrong event whenever the warehouse switched cutoff times — and quietly fixed the contract before anyone shipped against it. Both people show up under the same job title. Both write tests. They are not, in any meaningful sense, doing the same job.
Senior QA engineers treat testing the way good developers treat code: as a craft with internal standards, taste, and a long apprenticeship. That framing is more useful than treating QA as a queue of tickets to close.
What separates them, in practice
The honest answer is judgment, and judgment is hard to write a job description for. But there are patterns that help make it concrete.
The first is contract-mindedness. A great QA engineer does not write end-to-end tests as a substitute for thinking about service contracts. They notice when a producer changes the shape of an event and the consumer hasn't been told. They reach for consumer-driven contract testing — Pact, Spring Cloud Contract, the equivalent in whatever stack — before they reach for a longer Selenium suite. They know that an end-to-end test is a beautiful, expensive way to find out something that a contract test would have caught in milliseconds.
The second is observability for tests themselves. The mediocre QA writes a test, watches it pass, and moves on. The good QA writes a test, instruments it with enough metadata that when it fails six weeks later at 2 a.m., the on-call engineer can tell within thirty seconds whether it was a flake, an environment issue, or a real regression. They tag tests by feature area. They emit timing information. They treat the test suite as a system that the team has to operate, not a backlog of green checkmarks.
Flake is not a quirk of the test suite. Flake is information. The good QA reads it.
The third is engineering judgment in flake triage. Every team has a tolerance for flake — a level of test instability they've quietly accepted. Below that level, flakes get retried. Above it, the team panics and rewrites everything. The skilled QA lives in the middle. They sort flakes into causes: timing, ordering, shared state, network, real-but-rare. They know when to fix the test, when to fix the system under test, and when to escalate a quietly broken thing that nobody else has noticed yet.
A practical interview prompt
Instead of relying only on a whiteboard test plan, give a candidate a realistic failure scenario — here's a flaky integration test, here are the last fifty runs, here's what the system does — and ask them to talk through it. A strong answer can begin with the information they would inspect before choosing a fix.
Listen for whether the candidate considers the test code itself as a possible suspect or assumes the bug is in the system. Notice whether they reach for re-runs or form a hypothesis. Ask whether a recent deployment might explain the new behavior. The goal is to surface their reasoning, not reward a memorized checklist.
Why QA headcount is an incomplete measure
A team can add QA headcount without improving its testing practice. If ownership, system knowledge, and technical judgment are missing, the test suite can still become brittle and the flake backlog can still grow. Those risks deserve attention alongside the number of open roles or completed test cases.
The useful question is not only, Do we have enough coverage? It is also, Does the team have the judgment to decide what to test, at which layer, and how to operate the resulting suite?
The slightly uncomfortable conclusion
QA is a senior discipline. Treating it as a junior one is a choice that shapes test architecture, release confidence, and how quality work is valued across the engineering team.