"QA" is an umbrella, not a job title. Step into any modern engineering org and you will find a spectrum of testing roles, each focused on a different slice of the quality problem. Knowing what these roles do — and where they overlap — helps you figure out where you want to land and how teams collaborate around quality.
The roles you will meet
- – Test execution
- – Exploratory testing
- – Bug reporting
- – Test scripts
- – CI/CD integration
- – Framework maintenance
- – Test strategy
- – Team coordination
- – Metrics & reporting
- Tool development –
- Infrastructure –
- Performance testing –
Manual QA Engineer / QA Analyst. The classic entry point. Manual QA engineers design and run test cases, explore the product, file bug reports, and verify fixes. They are the team's user-empathy specialists — they know the product end-to-end and can tell you in seconds whether a change "feels" right. Strong manual testers are not "people who could not learn to code" — they are people who chose to specialise in the kind of judgement automation cannot replicate.
Automation Engineer / SDET (Software Development Engineer in Test). SDETs write code that tests code. They build and maintain frameworks like Cypress, Playwright, and Selenium, wire tests into CI pipelines, debug flaky tests, and own the test infrastructure. The SDET role bridges QA and engineering — many SDETs come from a manual QA background, others from a developer background.
Performance Engineer. A specialist who focuses on how the system behaves under load. They use tools like JMeter, k6, and Gatling to simulate thousands of concurrent users, find bottlenecks, and define service level objectives. Performance work blends testing with site reliability and capacity planning.
Security Tester / Penetration Tester. Someone who tries to break the application from the outside. They use tools like OWASP ZAP and Burp Suite to find injection flaws, authentication gaps, and misconfigurations. Security testing is increasingly a shared responsibility, but specialists still own the deep, adversarial work.
Accessibility Specialist. Tests for compliance with standards like WCAG, audits for screen reader support, and advocates for users with disabilities. Accessibility specialists often partner closely with designers and content writers.
QA Lead / Test Manager. Coordinates testing across teams, owns the test strategy and test plan, reports quality metrics to leadership, and grows the QA organisation. Less hands-on testing, more orchestration.
Director of QA / VP Quality. A leadership role that owns quality strategy across the organisation, defines hiring and tooling decisions, and represents quality to the executive team.
How the roles interact
In a small startup, one or two people might wear all of these hats — a single QA engineer who writes manual test cases on Tuesday, automates them on Wednesday, and runs a load test on Friday. In a large enterprise, each role is usually a distinct discipline with its own ladder.
Most importantly: everyone on the team is responsible for quality, not just the people with QA in their title. Developers write unit and integration tests. Product managers write acceptance criteria. Designers prototype with edge cases in mind. The QA function exists to amplify and coordinate these efforts, not to be the sole gatekeeper.
Skills that travel across every role
Regardless of where you land on the spectrum, four skills will carry you everywhere:
- Curiosity — the instinct to ask "what happens if I do this weird thing?" and "why is that the way it is?".
- Communication — being able to explain a problem clearly to a developer, a product manager, and a customer-support agent in three different ways.
- Risk thinking — knowing what to test deeply and what to test lightly, given limited time.
- Empathy for the user — remembering that someone real is going to live with the bug if you miss it.
The next lesson zooms into the most common career fork in QA: choosing between (or blending) manual and automation testing.