Building and Leading a Test Team

Why it matters

Testing is only as good as the people who do it. A team without API skills tests only through the screen; a team where one person understands the refund rules stops when that person is on leave. Such gaps rarely appear in a test report; they appear as defects nobody was equipped to look for.

The topic matters before you lead anyone: senior testers interview candidates, onboard colleagues and mentor juniors. And as the lesson on stakeholder communication showed, bad news is worth most early: a skills gap raised in planning is a staffing decision; raised in release week, it is an excuse.

The skills a team needs, and the skills matrix

The lesson on tester skills covered what one tester needs. A team needs coverage: every skill the product and its risks demand, at the right depth, and never held by only one person. Take the list from the test strategy, the product risks and the roadmap: a banking app needs payment-domain knowledge and security awareness, a government portal needs accessibility testing, and an Arabic-first product needs right-to-left (RTL) and localisation testing.

A skills matrix makes coverage visible: skills on one axis, people on the other, and in each cell a level on a short written scale. For each skill, also write what the team needs, for example "two people at level 2 or above". Testers rate themselves first; the lead then calibrates the ratings one-to-one, using evidence such as work the person has done alone.

• 0 — no experience with the skill.
• 1 — learning: does the task with guidance.
• 2 — independent: does the task alone, to the team’s standard.
• 3 — expert: reviews other people’s work and can teach the skill.
• A gap is any skill where fewer people reach level 2 than the team needs. For a skill used every week, set the need to at least two: a skill only one person holds is a single point of failure, which some teams call a bus factor of one.

Try it: Risk-Based Test Generator

Worked example: reading a skills matrix

A payments team has four testers: Huda, the test lead; Omar and Sara, who know the product well; and Arjun, who joined three months ago from an API team. Next quarter the company launches a mobile app and a partner API, and the test strategy asks for a load test before launch. Huda and the team list the skills the product and these plans need, agree the need for each and fill in the matrix.

• Test design, payments and localisation meet the need. Arjun at 0 in payments is onboarding, not a gap: he pairs with Omar on refund stories.
• API testing and automation each rest on Arjun alone. Omar will train for mobile and Huda leads the team, so Sara pairs with Arjun on partner-API stories, aiming for level 2 by the end of the quarter — shown when she designs a story’s API tests alone and he reviews them. For automation, Arjun coaches Huda and Sara, both at level 1, on the automated API test suite in sprint time agreed with the product owner.
• Mobile testing: nobody is at level 2 and the launch is close, so training alone is too slow. Decision: hire one tester with mobile experience and train Omar alongside.
• Performance testing is needed once, before launch. Decision: bring in a specialist and pair Arjun with them, so the team can rerun the test later. Not every gap must become a permanent skill.
• Huda keeps the matrix and the training plan as Markdown tables in the team wiki and reviews them with the team every quarter.

Skill                        Huda  Omar  Sara  Arjun  At 2+  Need
Test design / exploratory      3     2     2     1       3    2
Payments domain                3     2     1     0       2    2
Arabic / RTL localisation      2     3     3     0       3    2
API testing                    1     1     0     3       1    2   gap: one person
Test automation (code)         1     0     1     2       1    2   gap: one person
Mobile app testing             1     1     1     0       0    2   gap: nobody
Performance testing            1     0     0     1       0    1   gap: nobody

Levels: 0 none, 1 learning, 2 independent, 3 expert (reviews and teaches)
Gap: fewer people at level 2 or above than the team needs

Try it: Markdown Formatter Try it: Markdown to PDF

Hiring, onboarding and helping testers grow

Hire for the gap the matrix shows, not for a generic job advert. In a structured interview every candidate gets the same questions and the same short practical task, scored against criteria agreed in advance, so that candidates can be compared fairly. A task such as listing test ideas and open questions for a one-paragraph requirement shows more than questions about definitions. Never ask for unpaid work on your real product, and include a developer on the panel.

Onboarding decides how soon a new tester contributes. Arrange access to environments, tools and test data before day one, assign a buddy, walk through the product, the test strategy and the main risks, then hand over real tasks with growing independence: part of the regression suite, a paired exploratory session, then the testing of a small story. Many teams set goals for the first 30, 60 and 90 days.

• Training plan: one line per gap with the person, the target level, the method (pairing, an internal session, a course, a practice project), the date and the evidence that the level was reached. Reserve the time in sprint planning, or it does not happen.
• Motivation: people stay engaged when they see their work matter, own an area, have a say in how they test and have time to learn.
• Recognition: praise the behaviour you want, specifically and publicly — "Sara’s question in refinement removed a refund defect before coding". Never reward defect counts: that rewards duplicate and trivial reports and sets testers against developers.
• Career paths: offer a specialist path that deepens a skill such as automation, performance, security or accessibility up to senior and principal roles, and a leadership path to test lead and test manager. Titles vary between companies; growing should not require becoming a manager.

Team composition, independence and outside testers

The lesson on testing mindset and psychology introduced the degrees of independence in the ISTQB Foundation syllabus v4.0, from the author testing their own work to testers from outside the organisation. A lead turns them into a team design. A common one: developers test their own components, testers embedded in each delivery team test the stories and the system, and an outside party covers what needs very high independence or a rare skill, such as a security assessment. Independence brings different perspectives and challenges the assumptions made during specification and implementation; its drawbacks are isolation from the developers, testers being seen as a bottleneck or blamed for release delays, and developers who feel less responsible for quality. Choose the degree per test level and per risk.

Testers outside your team — in another time zone, at a provider or in a crowd — need more explicit structure. The guide on in-house versus outsourced QA compares the staffing models; whichever you use, the lead makes it work:

• Distributed testers: agree overlap hours for questions and triage, write a short daily handover (tested, blocked, next), and keep decisions in the tracker, not in private chats.
• Outsourced testers: put scope, deliverables and outcome measures in writing, keep test assets in systems your company owns, and have a team member review their reports every cycle.
• Crowd testers: many independent testers on their own devices for a short cycle, good for device and language coverage. They lack product context, so give them a precise scope and charters, expect duplicate and invalid reports, and triage them in the team. If they are paid per accepted defect, define in advance what counts.
• In every model: synthetic or masked test data and scoped access that is revoked at the end. Outside testers must never see real customers’ personal data.

The test manager in a whole-team agile setting

In the whole-team approach everyone is responsible for quality, and the 2020 Scrum Guide describes Scrum Teams as self-managing: they decide internally who does what, when and how. So a test manager does not hand out daily test tasks inside a team. The ISTQB Foundation syllabus notes that in agile development the team may handle some test management tasks, while tasks that span several teams or the whole organisation may be done by test managers outside the team. That cross-team work is the job:

• Strategy and standards: a shared test strategy, common severity definitions and a common approach to automation and test environments, which each team adapts.
• People: hiring, the skills matrix across teams, coaching and career conversations for testers who sit in different teams.
• Community: a regular meeting where testers from different teams share techniques, tools and problems; some organisations call it a guild or a chapter.
• Cross-team quality: integration and end-to-end risks that no single team owns, release-level reporting, and escalating systemic problems such as an unstable shared environment.
• Coaching the whole team: helping developers strengthen their unit tests and product owners write testable acceptance criteria, so that quality does not depend on testers alone.

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The 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)Addison-Wesley (Pearson) · 2009The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".