The QA career ladder: levels explained

The useful way to think about levels is not years of experience or job titles. It's what you're trusted to decide without supervision. A junior is trusted to execute a defined task correctly. A mid-level engineer is trusted to own a feature area end to end. A senior is trusted to make decisions that affect other people's work. A lead is trusted to decide what the team works on and why. Everything else — salary bands, title inflation, whether your company calls you QA II or Senior QA — follows from that, imperfectly.

What follows maps four levels: what each is judged on, what a promotion into it actually requires, the specific place most people stall, and what proof looks like to someone who has never met you. It is written for the transition from manual QA into engineering, so the skills are the ones that move you along that path rather than a generic competency framework.

Level 1 — Junior: programming, logic and testing fundamentals

Judged on: can you complete a defined task correctly and ask for help at the right time.

The mistake almost everyone makes here is skipping straight to a test automation tool. Selenium or Playwright in week one, before you can confidently write a function, handle a list, or read a stack trace. It feels like progress because tests run. It collapses the first time something breaks in a way the tutorial didn't cover, because you have no model of what the code is doing.

What actually belongs at this level:

• One language, properly. Python is the gentlest entry and is used widely in QA. TypeScript is the better bet if you know you're heading to Playwright and want to share a language with front-end developers.
• Data structures you'll genuinely use: lists, dictionaries, sets — and knowing when a set is the right answer.
• Control flow, functions, error handling. Reading a traceback and knowing which line matters.
• Git beyond git push: branches, resolving a conflict, writing a commit message someone can read.
• The testing core you may already have, made explicit: equivalence partitioning, boundary values, severity versus priority, what a good bug report contains — the manual QA question bank is that material, phrased the way interviews phrase it.
• SQL. Underrated. Checking what actually landed in the database, rather than what the UI claims, changes the quality of your bug reports immediately.

Where people stall: tutorial dependency. You can follow along with any video but freeze on a blank editor. The exit is uncomfortable and non-optional: solve problems without a reference solution available. Not hard algorithmic puzzles — small, real problems, repeatedly, until writing code stops feeling like translation. That is what the Code Lab is for.

Proof of progress: you can be handed a problem you've never seen, in plain English, and produce a working solution in an hour without copying an answer.

Level 2 — Mid: UI and API automation you actually understand

Judged on: can you own a feature area end to end without someone checking your work.

This is where you become an automation engineer in practice, whatever the title says. The distinguishing quality is not how many tests you've written — it's whether you understand the layers underneath them.

UI automation. Playwright is the sensible default for new work; Selenium still dominates large enterprise codebases, so knowing both makes you portable. What matters more than the tool:

• Locator strategy. Why a data-testid beats an XPath built from DOM structure, and what to do when the app gives you neither — the Locator Lab drills exactly this against a live page.
• Waiting. Why explicit conditions work and fixed sleeps don't, and being able to explain the difference without hand-waving.
• The page object pattern, and its limits. Knowing when it becomes a liability is a mid-to-senior signal.
• Making a test independent. If your suite only passes in a specific order, you don't have a suite, you have a script.

API automation. Often skipped, and skipping it is the single clearest tell of a shallow automation engineer. HTTP methods and status codes, auth flows including token refresh, request chaining, schema validation, and using API calls to set up state so your UI test doesn't spend ninety seconds logging in and navigating.

Where people stall: the plateau of writing more of the same test. Someone at month eighteen with two hundred specs to their name and no idea how their own framework's config loads. The way through is to deliberately go one layer down: read the framework code, change the reporter, break the CI job on purpose and fix it.

Proof of progress: a repo someone can clone and run. Real target application, UI and API coverage, environment config, a README that explains a design decision and its trade-off. Worth more than any certificate, because it is checkable and yours. When you're ready to be asked about it, that's the automation question bank.

Level 3 — Senior: architecture, CI/CD and AI-assisted testing

Judged on: can you make decisions that other engineers build on, and defend them.

The step from mid to senior is the biggest one on the ladder and the least well explained. It isn't more tools. It's a change in the unit of work: you stop producing tests and start producing the conditions under which other people produce good tests.

Framework architecture. Designing a structure a team of six can work in for two years. Where config lives and how environments differ. How authentication is handled once instead of everywhere. Test data that's parallel-safe, because the moment you shard your run, shared fixtures start colliding. Sensible failure artefacts — a trace, a screenshot, a video — so nobody has to reproduce locally to understand a CI failure.

CI/CD. Not "I know Jenkins exists." Which stages run on a pull request versus nightly. How to parallelise and what it costs. Quarantining known-flaky tests so they stop blocking merges without quietly deleting coverage. Making the pipeline fast enough that developers don't route around it — which is the real failure mode.

Flake, as a discipline. A suite nobody trusts is worse than no suite, because it consumes attention and delivers no signal. Seniors track flake rate, treat flaky tests as bugs with owners, and can explain the root causes: timing, shared state, network, animation, ordering.

AI-augmented QA. The current version is practical: generating first-draft cases you then prune, triaging failures faster, summarising logs, exploring an unfamiliar codebase. The skill is reviewing, not prompting — you need enough domain knowledge to spot what the output missed, which is exactly what a manual testing background gives you.

Where people stall: never getting the chance to design anything, because their employer already has a framework and no appetite for change. The workaround is to build one outside work. It doesn't need users. It needs to be real enough that you've hit the actual problems.

Proof of progress: you can whiteboard a test framework for an unfamiliar product, explain three design choices and what you traded away for each, and answer "why not the other approach?" without falling back on "that's how we did it." The SDET question bank is fifty variations of exactly that conversation.

Level 4 — Lead: strategy, influence and getting the offer

Judged on: can you decide what the team should work on, and get other people to agree.

The lead level is mostly not technical, which surprises people who spent three years getting technical. The technical depth is a prerequisite, not the job.

Quality strategy. Deciding where testing effort goes across a product with limited people. Choosing what stays manual on purpose. Defining what "done" means so it doesn't get renegotiated every sprint. Arguing for QA investment in terms an engineering manager cares about: change failure rate, time to detect, cost of a rollback.

Influence without authority. Getting developers to write their own unit tests. Getting a product manager to accept a delay. Getting a team to care about flake. None of this works by being right — which is the lesson most people learn painfully.

Growing others. Reviewing test code as teaching. Setting a bar and holding it. Making a junior faster rather than doing their work.

Interviewing and negotiating. This belongs on the ladder because it's a learnable skill most engineers never practise. Knowing the shape of an SDET loop — a coding round, a framework design discussion, a scenario round, behavioural questions — and having prepared, specific stories rather than improvised generalities. Most technically capable people underperform their ability in interviews, and it's the cheapest gap on this list to close.

Where people stall: staying the best individual contributor and treating strategy as overhead. It's a legitimate choice, and the principal-engineer track exists for people who make it. But it's a choice, not a default, and worth making deliberately.

How the levels actually run

Not sequentially, in practice. Level 1 has to be solid before Level 2 is anything other than copying. But senior work overlaps with mid work, and lead skills are worth starting early — particularly interview preparation, which most people leave until they're already applying and anxious.

The thing that separates people who climb from people who don't is not talent and not free time. It's sequence and feedback. Content is free and infinite; there are ten thousand hours of QA tutorials available right now for nothing. What's scarce is knowing what to learn next, and having a way to tell whether you actually learned the last thing. If you're studying in stolen hours after work, the cost of picking wrong is your entire month.

That's the argument for following one ordered path to the end rather than assembling your own from whatever the algorithm shows you. Not because any single path is uniquely correct, but because finishing one is worth more than starting five.