Skip to content
Menu

Career ladder template

QA engineer career ladder template

Four levels from Junior QA to Lead QA Engineer, across six competencies from test design to quality practices.

Free plan · No credit card required

This career ladder is for QA engineers in software companies of roughly 20 to 200 people, where testers sit inside product teams, there may be only a handful of them in the whole company, and the same person often does exploratory testing in the morning and writes automated checks in the afternoon. It describes four levels, from someone learning to test one feature well to the person who decides how the whole company approaches quality. Its top level, Lead QA Engineer, is an individual-contributor level, not a management role.

Each level is defined by what a person does and how far their work reaches, not by years of experience or the number of bugs they file. Read a row of the competency matrix from left to right to see how one expectation grows; read a level's section to see everything expected at that level. Use it to explain what the next step means, to run self-assessments and check-ins, and to keep promotion decisions comparable across teams.

Treat it as a draft. If your QA engineers do not write automation, or if developers own most of the testing, change the wording before you publish the ladder — an expectation nobody can meet in your setup only creates frustration.

The levels at a glance

  1. Junior QA Engineer

    Tests well-defined features from existing test cases and learns the product and its users.

    Scope
    Individual stories or bug fixes in one area of the product, with test plans reviewed by someone more experienced.
  2. QA Engineer

    Owns the testing of features in one team, from reading the requirements to signing off the release.

    Scope
    The features of one product team, including their manual and automated tests.
  3. Senior QA Engineer

    Shapes how one or two teams build quality in and owns the test strategy for larger projects.

    Scope
    One or two teams' test strategy, automation suites and release decisions, plus projects that cross team boundaries.
  4. Lead QA Engineer

    Sets the company's approach to quality and makes every team better at shipping with fewer escaped defects.

    Scope
    Quality across the whole product: shared test infrastructure, release standards and how QA is staffed and practised.

Competency matrix

Each row is a competency and each column a level. Read a row from left to right to see how the expectation grows.

What each competency means

Test design and analysis
Working out what could go wrong and choosing the tests that will find it.
Test automation
Building automated checks that are fast, stable and trusted by the team.
Defect investigation and reporting
Finding, reproducing and explaining problems so they get fixed quickly.
Release and risk judgement
Deciding whether something is ready to ship and saying so clearly.
Quality practices
Building quality into the way the team works rather than testing it in at the end.
Mentoring and knowledge sharing
Helping others test better and keeping product knowledge from living in one head.
QA Engineer: expectations by competency and level
CompetencyJunior QA EngineerQA EngineerSenior QA EngineerLead QA Engineer
Test design and analysisRuns existing test cases carefully, writes new cases for small stories that cover the main path and the obvious edge cases, and asks about requirements that are unclear before testing starts.Writes a test plan for each feature in the team, covering edge cases, permissions, data states and integrations, and reviews requirements before development starts to spot gaps.Designs the test strategy for projects that span several features or teams, decides what to cover at unit, API and end-to-end level, and focuses effort on the parts most likely to break.Defines how the company decides what to test and how deeply, based on risk and usage data, and makes sure every team applies it consistently.
Test automationAdds automated tests to an existing framework by following established patterns, runs the suite locally, and reports failures they cannot explain instead of re-running them until they pass.Automates the regression tests for the team's features, keeps them stable and readable, and fixes or removes flaky tests rather than ignoring them.Designs the structure of an automation suite, wires it into the delivery pipeline with sensible run times, and reviews the tests that developers and other QA engineers write.Chooses the company's test tooling and shared infrastructure, balances the layers of the test pyramid across products, and keeps the whole suite fast enough that teams actually wait for it.
Defect investigation and reportingFiles bug reports with clear steps, expected and actual results, and the environment, so a developer can reproduce the problem without asking follow-up questions.Narrows bugs down using logs, network traces and the database, judges their severity by impact on users, and confirms fixes, including the cases around them.Investigates intermittent and production-only issues across services, spots patterns in recurring defects, and turns them into proposals that remove a whole class of bugs.Owns how the company tracks and prioritises defects, reports trends in escaped bugs to engineering leadership, and makes sure the biggest sources of defects get funded fixes.
Release and risk judgementCompletes the checks assigned before a release, reports what was and was not tested, and raises concerns to a more experienced QA engineer.Gives a clear go or no-go recommendation for the team's releases, explaining the known risks and what remains untested, and takes part in post-release checks.Decides the release approach for risky changes — feature flags, staged rollouts, extra monitoring — together with developers, and leads testing during incidents and hotfixes.Sets the release standards every team works to, defines when a release can be blocked, and is the person leadership asks whether the product is ready for a major launch.
Quality practicesFollows the team's definition of done and testing workflow, and points out steps that are skipped or confusing.Joins refinement and design discussions to add acceptance criteria and testability concerns early, and pairs with developers on what to cover in their own tests.Improves the testing workflow of one or two teams — test environments, test data, review checklists — and measures whether the change reduced escaped defects.Shapes quality practices across engineering, decides where QA engineers are placed and what developers own, and makes quality a shared responsibility rather than one team's job.
Mentoring and knowledge sharingDocuments what they learn about the product as they test, and shares useful findings and tools with the team.Keeps the team's test documentation current, onboards new teammates to the product area, and explains testing techniques to developers who ask.Mentors junior QA engineers deliberately, runs sessions on testing approaches for developers, and takes part in hiring interviews for QA roles.Grows the QA group's skills and career paths, defines how QA engineers are hired and onboarded, and develops the next senior and lead QA engineers.

Scroll the table sideways to see every level.

Download as CSV Opens in Excel, Google Sheets or Numbers.

Junior QA Engineer: what is expected

Tests well-defined features from existing test cases and learns the product and its users. Individual stories or bug fixes in one area of the product, with test plans reviewed by someone more experienced.

Test design and analysis
Runs existing test cases carefully, writes new cases for small stories that cover the main path and the obvious edge cases, and asks about requirements that are unclear before testing starts.
Test automation
Adds automated tests to an existing framework by following established patterns, runs the suite locally, and reports failures they cannot explain instead of re-running them until they pass.
Defect investigation and reporting
Files bug reports with clear steps, expected and actual results, and the environment, so a developer can reproduce the problem without asking follow-up questions.
Release and risk judgement
Completes the checks assigned before a release, reports what was and was not tested, and raises concerns to a more experienced QA engineer.
Quality practices
Follows the team's definition of done and testing workflow, and points out steps that are skipped or confusing.
Mentoring and knowledge sharing
Documents what they learn about the product as they test, and shares useful findings and tools with the team.

QA Engineer: what is expected

Owns the testing of features in one team, from reading the requirements to signing off the release. The features of one product team, including their manual and automated tests.

Test design and analysis
Writes a test plan for each feature in the team, covering edge cases, permissions, data states and integrations, and reviews requirements before development starts to spot gaps.
Test automation
Automates the regression tests for the team's features, keeps them stable and readable, and fixes or removes flaky tests rather than ignoring them.
Defect investigation and reporting
Narrows bugs down using logs, network traces and the database, judges their severity by impact on users, and confirms fixes, including the cases around them.
Release and risk judgement
Gives a clear go or no-go recommendation for the team's releases, explaining the known risks and what remains untested, and takes part in post-release checks.
Quality practices
Joins refinement and design discussions to add acceptance criteria and testability concerns early, and pairs with developers on what to cover in their own tests.
Mentoring and knowledge sharing
Keeps the team's test documentation current, onboards new teammates to the product area, and explains testing techniques to developers who ask.

Senior QA Engineer: what is expected

Shapes how one or two teams build quality in and owns the test strategy for larger projects. One or two teams' test strategy, automation suites and release decisions, plus projects that cross team boundaries.

Test design and analysis
Designs the test strategy for projects that span several features or teams, decides what to cover at unit, API and end-to-end level, and focuses effort on the parts most likely to break.
Test automation
Designs the structure of an automation suite, wires it into the delivery pipeline with sensible run times, and reviews the tests that developers and other QA engineers write.
Defect investigation and reporting
Investigates intermittent and production-only issues across services, spots patterns in recurring defects, and turns them into proposals that remove a whole class of bugs.
Release and risk judgement
Decides the release approach for risky changes — feature flags, staged rollouts, extra monitoring — together with developers, and leads testing during incidents and hotfixes.
Quality practices
Improves the testing workflow of one or two teams — test environments, test data, review checklists — and measures whether the change reduced escaped defects.
Mentoring and knowledge sharing
Mentors junior QA engineers deliberately, runs sessions on testing approaches for developers, and takes part in hiring interviews for QA roles.

Lead QA Engineer: what is expected

Sets the company's approach to quality and makes every team better at shipping with fewer escaped defects. Quality across the whole product: shared test infrastructure, release standards and how QA is staffed and practised.

Test design and analysis
Defines how the company decides what to test and how deeply, based on risk and usage data, and makes sure every team applies it consistently.
Test automation
Chooses the company's test tooling and shared infrastructure, balances the layers of the test pyramid across products, and keeps the whole suite fast enough that teams actually wait for it.
Defect investigation and reporting
Owns how the company tracks and prioritises defects, reports trends in escaped bugs to engineering leadership, and makes sure the biggest sources of defects get funded fixes.
Release and risk judgement
Sets the release standards every team works to, defines when a release can be blocked, and is the person leadership asks whether the product is ready for a major launch.
Quality practices
Shapes quality practices across engineering, decides where QA engineers are placed and what developers own, and makes quality a shared responsibility rather than one team's job.
Mentoring and knowledge sharing
Grows the QA group's skills and career paths, defines how QA engineers are hired and onboarded, and develops the next senior and lead QA engineers.

How to adapt this ladder

  1. Write down your mix of manual and automated testing

    If your QA engineers focus on exploratory testing, shorten the Test automation row and expand Test design and analysis. If they mostly build automation, raise the expectations for code quality. Either way, make the choice explicit so nobody is assessed against a job they were not hired for.

  2. Keep the Lead level for when it is a real job

    With two or three QA engineers, the company usually needs junior, mid and senior levels only. Add Lead when someone is genuinely setting quality standards for every team, not as a reward for being the longest-serving tester. In this ladder Lead is an individual-contributor level; if your QA lead also manages testers, add the people expectations from the engineering manager ladder.

  3. Line up the levels with your engineering ladder

    Map each QA level to the software engineer level with comparable scope and pay. When a Senior QA Engineer sits next to a Senior Engineer, moving between the two tracks becomes a sideways step rather than a demotion or a jump.

  4. Collect evidence, not bug counts

    For check-ins and promotion cases, gather examples such as a test plan that caught a costly defect, a flaky suite that was made reliable, or a release decision that held up. Counting bugs filed rewards noise and punishes testers on stable teams.

FAQ

Questions about this ladder

How many levels does a QA engineer career ladder need?

Three or four is usually enough for a company of 20 to 200 people, because QA groups are small. This template uses four: Junior QA Engineer, QA Engineer, Senior QA Engineer and Lead QA Engineer. Add a fifth only when the scope of the work really grows beyond setting quality standards for the whole product.

Should manual testers and QA automation engineers share one career ladder?

In most smaller companies, yes. The core of the job — understanding risk, designing tests and judging releases — is the same; only the tools differ. Keep one ladder and agree, per person or per team, how much of the Test automation row applies.

Can a QA engineer switch to the software engineering track?

Yes, and it works best as a planned move. Compare the person against the software engineer ladder, agree a few growth actions such as owning small features or bug fixes, and move them when they consistently meet that level. Their testing experience usually makes them stronger engineers, not weaker ones.

How do you measure a QA engineer's performance without counting bugs?

Look at outcomes and behaviour: defects that escaped to production in their area, the reliability and speed of the automated suite, how early they raise risks, and how release decisions held up. Discuss concrete examples against the ladder in regular check-ins rather than relying on dashboards alone.

How many QA engineers does a team of developers need?

There is no fixed ratio. Many companies of this size run with one QA engineer for every four to eight developers, but the right number depends on how much developers test their own work and how costly a defect is for your users. Watch escaped defects and release delays, and hire when either keeps rising.

Build this career ladder in LadderKit — free

Set up its levels and skills for your team, assess people against them in check-ins, and keep promotion decisions consistent.

Free plan · No credit card required

  • Engineering

    Software Engineer

    Five levels from Junior to Principal, across six competencies from shipping code to growing the team.

    • 5 levels
    • 6 competencies
  • Engineering

    DevOps Engineer

    Four levels from Junior to Staff DevOps Engineer, across six competencies from infrastructure to developer enablement.

    • 4 levels
    • 6 competencies
  • Engineering

    Engineering Manager

    Four levels from Engineering Manager to VP of Engineering, across six management competencies.

    • 4 levels
    • 6 competencies

Browse all templates