QA is one of the most navigable career paths in tech. There are well-worn ladders, multiple legitimate specialisations, and a robust market for senior practitioners. The pay can be excellent at the top, the work can be intellectually deep, and the role respects different working styles. The catch: you have to choose your direction deliberately, because nobody is going to choose it for you.
A typical career arc
A common (not the only) progression:
Years 0-2: Manual QA Engineer / QA Analyst. Learn the product. Master test design — partitioning, boundary analysis, decision tables, exploratory testing. Get comfortable with bug triage and the bug lifecycle. Start reading code, even if you don't write it yet.
Years 2-4: Mid-level QA / fork in the road. This is where you make the first real specialty choice:
- Specialist manual / exploratory tester. Lean into deep test design, exploratory mastery, and product judgement. Salary growth here is real but slower than automation paths in many markets.
- Automation engineer / SDET. Learn to write code. Pick up Cypress, Playwright, or whatever your team uses. Take ownership of the automated suite.
- Performance specialist. Master JMeter, k6, or Gatling. Understand load profiles, percentile metrics, and capacity planning.
- Security tester. Learn web application security — OWASP Top 10, Burp Suite, penetration testing methodology.
- Accessibility specialist. Become the team's expert on WCAG, screen reader testing, and inclusive design.
You don't have to commit forever — many engineers move between these specialties over a career — but you do have to commit for a stretch long enough to develop real depth.
Years 4-7: Senior IC or first-line lead. Two paths fork again:
- Senior IC. Stay hands-on, get deeper in your specialty, mentor juniors, lead quality initiatives across teams. The most senior ICs (Staff QA, Principal QA) are rare and well-compensated.
- QA Lead / Test Manager. Move toward people management. You'll spend more time coordinating, less time hands-on. The skills are different — coaching, planning, hiring, communicating with leadership.
Neither path is "better." They're different jobs with different rewards, and many people switch between them more than once.
Years 7+: Principal IC, Manager, or Head of QA. At this stage, your visible work is strategy. You shape hiring, tooling, process. You influence how the whole engineering org thinks about quality.
Skills that compound at every level
Some skills make you better at your current role and prepare you for the next:
- Clear writing. Bug reports, test plans, post-mortems, RFCs. Engineers who write well get promoted; those who don't, don't.
- Risk thinking. Knowing where to spend testing time, given finite hours.
- System design literacy. Understanding how distributed systems fail, even if you don't design them yourself.
- Empathy for users. This rarely shows up in performance reviews, but it shapes the bugs you find and the ones you let slide.
- Code reading. You don't need to write code to be senior, but you do need to read it.
- Public communication. Talking at meetups, contributing to community projects, writing blog posts. None of this is required, but it dramatically widens your future options.
Compensation reality
A few honest facts:
- SDETs typically earn more than manual-only testers at any given level, because they overlap with general engineering pay scales.
- Performance and security specialists can earn well above the average QA pay.
- Manual / exploratory testing pay depends heavily on the company. Specialised exploratory testers at mature product companies do very well; generic manual testers at outsourcing shops earn much less.
- Career switchers moving from QA into general SWE or SRE can see large pay jumps, but the work is genuinely different and not for everyone.
If pay is a primary motivator, lean toward automation and infrastructure-adjacent specialties. If craft is the motivator, the pay tradeoff is real but the work is often more interesting.
Building the public side of your career
Junior QA engineers often feel invisible compared to developers. A few simple practices push back against that:
- Keep a portfolio. Even a private one — bugs you're proud of finding, exploratory sessions that produced insights, automation contributions.
- Write about what you learn. A blog, a Notion page, threads on social — any of it works. Your future self and your future employer will both thank you.
- Speak at meetups. Local QA meetups, conference lightning talks, internal lunch-and-learns. The bar is much lower than it seems.
- Contribute to open source. Even small fixes to your favourite testing tool (Cypress, Playwright, k6) count.
- Build a network of QA peers. Slack groups, discords, twitter circles — quality engineers who talk to each other learn faster than those who don't.
The most important advice
Pick something specific to be excellent at. "Generalist QA engineer" is a hard career to differentiate. "QA engineer who specialises in exploratory testing for fintech products" is much sharper, and the role market for sharp specialists is consistently better than for generalists.
The specialty you choose matters less than the depth you reach. Five years of focused depth in any of these areas — manual exploratory, automation, performance, security, accessibility — produces a senior practitioner who is in demand. Five years of "a little bit of everything" produces someone who has to start over each time they switch specialties.
What you should walk away with
QA careers are real careers. The ladders are clear, the specialisations are legitimate, and the senior end of the market is healthy. Pick a direction, invest in depth, and keep your perspective broad enough to switch when needed. You've now finished the foundations — the rest is practice. Welcome to the field.