Testing Roles and Responsibilities
Testing is a set of activities — test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion — and each one needs someone responsible for it. The ISTQB Foundation syllabus v4.0 describes two principal roles: the test management role, responsible overall for the test process, the test team and the leadership of the test activities, and the testing role, responsible overall for the engineering, technical side of testing.
As the lesson on how software is built showed, a role is a set of responsibilities, not a job title. On a small team one QA engineer may write the test plan on Monday (test management role) and design and run tests for the rest of the sprint (testing role).
Why it matters
When responsibilities are unclear, work falls into the gaps: nobody agrees when testing is finished, nobody owns the test environment, and a risky change ships because everyone assumed someone else had tested it. The opposite belief is just as harmful: if the tester alone is responsible for quality, testing becomes a late final gate and every escaped bug is blamed on one person.
The roles also explain job adverts. Titles differ between companies, but the activities behind them do not, so knowing the activities tells you what a post really involves and how to grow from the testing role towards test leadership.
The two roles in ISTQB v4.0
The test management role is mainly focused on test planning, test monitoring and control, and test completion. It decides what testing should achieve, what is in scope, how much effort it gets, how progress is tracked and when testing can stop, and it oversees the other activities through monitoring and control. In agile teams the team itself may handle some of these tasks; work that spans several teams may sit with a test manager outside the team.
The testing role is mainly focused on test analysis, test design, test implementation and test execution: the hands-on work of turning the test basis into tests, running them and reporting what they find.
How the tasks are split depends on the project and product context, the skills of the people and the organisation. The test management role may be performed by a team leader, a test manager or a development manager, and one person can hold both roles at the same time.
| Test activity | Test management roletest manager, test lead, team lead | Testing roletester, QA engineer, SDET | Developers | Product owner and business |
|---|---|---|---|---|
| Test planning | Leadsscope, approach, exit criteria | Contributesestimates, risks, data and environment needs | Contributesestimates, technical risks | Contributespriorities, agrees the approach |
| Test monitoring and control | Leadsprogress against the plan, control decisions | Contributesprogress, blockers, open defects | no main task here | Contributesagrees scope changes |
| Test analysis | Oversees | Leadstest conditions from the test basis | no main task here | Contributesclarifies the test basis |
| Test design | Oversees | Leadstest cases and test data | Contributesreview the test cases | Contributesacceptance tests with testers |
| Test implementation | Oversees | Leadsprocedures, suites, environment readiness | Contributestest environment set-up | no main task here |
| Test execution | Oversees | Leadsrun tests, report defects, retest | Contributescomponent tests | Contributesacceptance testing |
| Test completion | Leadscompletion report, lessons learned | Contributesarchive testware, update the regression suite | no main task here | no main task here |
A typical split, not a rule: ISTQB says the tasks depend on the context, and one person can hold both roles.
Tester responsibilities across the lifecycle
A tester’s work starts before there is software to run and ends after the last test. Across a release, a tester typically leads the hands-on activities of the testing role and contributes to the others:
- Backlog refinement: review user stories and acceptance criteria for gaps, ambiguity and testability, before code is written.
- Planning: contribute estimates, risks, and test data and environment needs, even when someone else owns the plan.
- Analysis and design: derive test conditions from the test basis and design test cases that trace back to requirements.
- Implementation: prepare test data, procedures and suites, and check that the test environment is ready.
- Execution: run tests, report defects, and perform confirmation and regression testing after fixes.
- Monitoring and completion: report progress and blockers honestly, archive testware, update the regression suite and record lessons learned.
Job titles and how they map to the roles
Employers set job titles, not ISTQB, so one title can mean different work in two companies. Read a job description by asking which activities it covers. Common patterns:
- QA engineer, QA analyst or software tester: mainly the testing role, often with some API testing or automation.
- SDET (software development engineer in test) or test automation engineer: the testing role with an engineering focus — automated tests, frameworks and tooling, built in the codebase and the continuous integration (CI) pipeline alongside developers.
- Test lead or QA lead: usually both roles for one team or project — plans and coordinates the testing, assigns work, reports status and still tests hands-on.
- Test manager or QA manager: the test management role across several teams or projects — strategy, staffing, coaching, budget, and reporting quality and risk to management.
Whole-team responsibility for quality
ISTQB describes the whole-team approach, a practice that comes from Extreme Programming: any team member with the necessary knowledge and skills can do any task, and everyone is responsible for quality. Testers help business representatives create suitable acceptance tests and agree the test strategy and automation approach with developers. The 2020 Scrum Guide defines three accountabilities in a Scrum Team — the Product Owner, the Scrum Master and the Developers — and no separate tester: testers in a Scrum Team count as Developers.
Shared responsibility is not the absence of responsibility. Developers usually perform component (unit) testing, acceptance testing is ideally done by the intended users, the product owner owns acceptance criteria and priorities, and the tester brings test design, a risk view and evidence. The approach does not fit every context: safety-critical systems, for example, may need a high level of test independence. The lesson on quality culture goes deeper.
Worked example: one feature, every activity owned
A team builds online appointment booking for a clinic. It has a product owner, three developers, one QA engineer and an engineering manager who leads the team. Nobody is called test manager, yet every activity has an owner:
- Planning: the QA engineer drafts a one-page test approach with the main risks (two patients booking one slot, an SMS that is never sent) and the exit criteria — the test management role. The engineering manager agrees it with the product owner.
- Analysis and design: the QA engineer asks what happens when a doctor cancels a day that has bookings, and the product owner’s answer becomes an acceptance criterion. A developer reviews the QA engineer’s test cases.
- Implementation and execution: developers run component tests for the slot-locking logic in CI. The QA engineer sets up doctors and schedules in the test environment, runs system tests, reports a double-booking defect and retests the fix.
- Monitoring and control: the open defect is reported at the daily meeting, and the engineering manager and the product owner move a lower-priority story to the next sprint.
- Completion: the product owner accepts the feature against its criteria, and the QA engineer adds the double-booking test to the regression suite.
Common mistakes
- Treating a job title as a role: assuming a QA engineer never plans or a test manager never tests. Read the duties, not the title.
- Believing the tester alone owns quality, so code reaches testing untested and the tester is blamed for every escaped defect.
- Reading whole-team responsibility as nobody’s responsibility: everyone tests a little, but no one owns the plan, the exit criteria or the regression suite.
- Skipping the test management tasks because the team has no test manager: no agreed scope, no exit criteria, no completion report.
- Joining only at test execution instead of reviewing requirements and contributing to planning from the start.
- Thinking an SDET only writes code: automated tests are only as good as the test analysis and test design behind them.
The QA perspective
On a new team, find out who holds the test management role, even if nobody has the title. Ask who decides scope, who agrees the exit criteria, who owns the test environment and test data, and who decides whether a release ships with known defects. If the answer is "nobody" or "the tester alone", raise it before the first release, not after it.
Write an owner for each activity in the test plan or the team’s working agreement. When you report, keep facts and decisions apart: you provide the information about quality and risk, and the release decision belongs to the people accountable for the product, such as the product owner.
Practice exercise
Assign the test activities in a small team
A team starts a two-sprint release that adds Arabic PDF invoices to an accounting web app. It has a product owner, a team lead who also develops, two developers and one QA engineer, and no test manager. In the last release nobody decided when testing was finished, and the test environment had no Arabic fonts until the last day.
For each test activity, name who leads it and who contributes. Then give each of the two old problems an owner.
- List the seven test activities in the ISTQB order.
- For each activity, write who leads and who contributes.
- Mark each activity as test management role or testing role.
- Link each old problem to its activity and name an owner.
Show the model answer
The seven activities in ISTQB order: test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion.
Test planning, monitoring and control, and completion (test management role): the QA engineer leads them by drafting the test approach, the exit criteria and the completion summary; the team lead and the product owner agree them and take control decisions such as moving a story; developers add estimates and risks such as right-to-left layout in the PDF.
Test analysis, design, implementation and execution (testing role): the QA engineer leads; the product owner clarifies the invoice rules and checks sample invoices against the acceptance criteria; a developer reviews the test cases; developers run component tests in CI.
Old problem 1: exit criteria decide when testing is finished, and they belong to test planning; owner: the QA engineer, who drafts them so that the team lead and the product owner agree them before the first sprint starts. Old problem 2: environment readiness belongs to test implementation, so a named developer installs the Arabic fonts in the first sprint and the QA engineer checks readiness before execution. Other assignments are fine as long as every activity has one named owner.
Frequently asked questions
Is a QA engineer the same as a tester?
In many job adverts, yes: the work is mainly the testing role, as the lesson on QA, QC and testing explained. Some companies use the title for wider work, such as improving the process or owning the quality gates before a release. Read the responsibilities.
What is the difference between a test lead and a test manager?
Titles vary, but a test lead usually coordinates the testing for one team or project and still tests hands-on, while a test manager holds the test management role across several teams or projects and also handles people, budget and strategy. In ISTQB terms both hold the test management role, at different scales.
Does the whole-team approach mean we do not need testers?
No. It means everyone shares responsibility for quality, not that testing skills stop being needed. Testers bring test design, risk analysis and an independent view, and pass testing knowledge on to the rest of the team. ISTQB also notes that some contexts, such as safety-critical systems, need a high level of test independence.
Can one person hold both roles?
Yes. The ISTQB syllabus says explicitly that one person can take on the testing role and the test management role at the same time. It is common when a team has a single tester.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- The 2020 Scrum GuideThe definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
Practise with Mutqan tools
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Generate Given/When/Then acceptance criteria and a definition-of-done checklist from a user story.
Score features by likelihood and impact, then generate a prioritised risk-based test plan.
Go deeper
- Software Testing Life Cycle (STLC)STLC phases mapped to the ISTQB test process
- SDLC and STLC ExplainedWhere QA takes part in each SDLC phase
- How to Write a Test PlanHow to write a test plan: what it contains, entry, exit, suspension and resumption criteria, a copy-ready template, an agile one-page plan and an example.
- In-House QA Team vs Outsourced QAThe four staffing models
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.