QA Roles & Responsibilities.

When roles are vague, quality work either gets duplicated or dropped. Two people re-test the same flow while nobody owns the regression suite; everyone assumes someone else is doing the sign-off. Clear roles replace those assumptions with accountability — for each part of quality, someone specific is on the hook.

Clear roles aren't about building walls. They're about knowing who leads each activity so collaboration has a centre of gravity. "Everyone owns quality" is true as a culture, but without named responsibilities it quietly becomes "no one owns quality".

The QA engineer is the core testing role: designing and executing test cases, exploring the product for defects, raising clear bug reports, and setting severity from the tester's seat. They own the day-to-day verification that features behave as specified.

It's a hands-on role focused on a feature or area. The QA engineer knows their part of the product deeply, runs the functional and exploratory testing, and is usually the first to find — and the best to describe — what's broken.

A senior QA engineer does everything a QA engineer does, plus the judgement work: shaping test strategy for their area, designing coverage for complex or high-risk features, and mentoring less experienced testers. They're trusted to decide how deep to test, not just to execute someone else's plan.

They often act as the quality conscience in refinement and design discussions, spotting testability problems and edge cases early. The step up from QA to senior QA is less about more testing and more about better testing decisions.

An SDET (Software Development Engineer in Test) is a tester who builds. They write and maintain automation frameworks, create reliable automated tests, wire testing into CI/CD, and build the tools and harnesses that make testing faster and more repeatable.

The SDET sits at the join of QA and engineering. Where a QA engineer asks "does this work?", the SDET also asks "how do we prove this works automatically, every build?" Strong automation coverage and a trustworthy pipeline are largely their responsibility.

The QA lead owns how a team tests: the test strategy, the standards, the quality gates, and the QA sign-off on a release. They plan and coordinate testing across the team, run triage, and are the person accountable for the team's quality bar being met.

It's a role that balances hands-on and leadership. A good QA lead removes blockers, shields the team from chaos, and makes the call when there's a trade-off between coverage and time — then stands behind that call at sign-off.

A test manager operates above a single team, owning QA across multiple teams or a whole product: process, headcount, tooling strategy, budgets, and reporting to senior stakeholders. They set the standards that individual QA leads apply.

Not every organisation has this role — in smaller teams a QA lead or engineering manager covers it. Where it exists, the test manager is accountable for the overall quality function rather than the testing of any one release.

Quality isn't QA's job alone, and the product owner has real responsibilities in it. They write clear, testable acceptance criteria, set defect priority based on business value, and make the business sign-off call on whether to ship — including accepting known risks.

When the product owner disengages from quality, QA is left guessing what "correct" means and what matters most. Their involvement is what keeps testing aligned to business value rather than to QA's best guess of it.

Developers own a large share of quality: writing unit and integration tests, testing their own work before handoff, fixing defects, and helping diagnose root cause. Quality that's "thrown over the wall" to QA at the end is slower and worse than quality built in as code is written.

The healthiest teams treat developers and QA as partners, not a relay race. Developers catching their own bugs early frees QA to focus on the integration, exploratory, and risk-based testing where human judgement adds the most.

Defined roles and shared ownership aren't in tension — you need both. Everyone contributes to quality, but for each activity one role leads and is accountable, so collaboration doesn't dissolve into diffusion of responsibility.

A simple way to make this concrete is a RACI map: for each activity, mark who is Responsible (does the work), Accountable (owns the outcome — exactly one per row), Consulted (gives input), and Informed (kept in the loop). The example below shows how the roles above divide the core QA activities.