Building a QA Team

From First Hire to Mature Organization

Building a QA team is not just about hiring testers. It is about designing an organization structure that fits your company's needs, hiring people whose skills complement each other, and evolving the team's maturity over time. Whether you are building from scratch or inheriting an existing team, the decisions you make about structure and composition will determine how effective your quality efforts are for years to come.

QA Team Models

There are three dominant models for organizing QA engineers within a company. Each has trade-offs, and the right choice depends on your organization's size, culture, and product architecture.

Centralized QA Team

All QA engineers report to a QA manager and are assigned to projects as needed.

VP of Engineering
    └── QA Manager
            ├── QA Engineer A → assigned to Team Alpha
            ├── QA Engineer B → assigned to Team Beta
            ├── QA Engineer C → assigned to Team Gamma
            └── QA Engineer D → floater / specialist

Advantage	Disadvantage
Consistent standards across the organization	QA engineers may feel disconnected from their dev teams
Easier to share knowledge and best practices	Assignment changes can disrupt team dynamics
Clear career path within QA hierarchy	Can create "us vs them" dynamic with developers
Efficient resource allocation across projects	QA priorities may conflict with dev team priorities
Stronger QA identity and community	Slower feedback loop if QA is not co-located with devs

Best for: Large enterprises with many product teams, organizations that need strict quality standards, companies with dedicated QA leadership.

Embedded QA (Distributed Model)

QA engineers report directly to the engineering manager of their product team. There is no centralized QA organization.

VP of Engineering
    ├── Team Alpha Lead
    │       ├── Developer 1
    │       ├── Developer 2
    │       └── QA Engineer A
    ├── Team Beta Lead
    │       ├── Developer 3
    │       ├── Developer 4
    │       └── QA Engineer B
    └── Team Gamma Lead
            ├── Developer 5
            └── QA Engineer C

Advantage	Disadvantage
QA is deeply integrated with the dev team	Inconsistent practices across teams
Faster feedback loops and tighter collaboration	QA engineers can feel isolated from QA peers
QA understands the product domain deeply	Career growth may be limited without QA leadership
No resource allocation conflicts	Knowledge sharing across teams is harder
QA participates in all team decisions	Risk of QA being treated as a junior developer

Best for: Agile startups, companies with autonomous product teams, organizations with strong engineering culture.

Hybrid Model

A small centralized QA team sets standards, builds tooling, and provides expertise, while most QA engineers are embedded in product teams.

VP of Engineering
    ├── QA Platform Team (centralized)
    │       ├── QA Architect → frameworks, tooling
    │       ├── Performance Specialist
    │       └── QA Coach → standards, mentoring
    ├── Team Alpha (embedded QA)
    │       ├── Developers
    │       └── QA Engineer A (dotted line to QA Architect)
    └── Team Beta (embedded QA)
            ├── Developers
            └── QA Engineer B (dotted line to QA Architect)

Advantage	Disadvantage
Best of both worlds: local integration + central standards	More complex organizational structure
QA platform team builds shared infrastructure	Dotted-line reporting can create confusion
Embedded QA engineers have peer community	Requires strong coordination between central and embedded
Consistent tooling with team-specific flexibility	Central team can become a bottleneck for decisions

Best for: Mid-to-large companies, organizations transitioning from centralized to agile, companies that want consistency without rigidity.

QA-to-Developer Ratios

There is no universal "right" ratio. The ratio depends on your product's risk profile, your automation maturity, and how much testing developers do themselves.

Context	Typical Ratio (QA:Dev)	Why
Early-stage startup	0:5 to 1:8	Developers test their own code; QA investment comes later
Growth-stage startup	1:5 to 1:4	First dedicated QA hires focus on automation and critical paths
Mid-size company	1:4 to 1:3	Balanced investment in manual and automated testing
Enterprise	1:3 to 1:2	Regulatory, compliance, and risk requirements demand more QA
Agency / consultancy	1:6 to 1:4	Varies by client; QA often shared across projects
Safety-critical (medical, aerospace)	1:1 or higher	Regulatory mandates extensive verification and validation

Factors That Reduce the Need for Dedicated QA

Strong developer testing culture (high unit test coverage, TDD adoption)
Mature CI/CD pipeline with automated quality gates
Feature flags and canary deployments that limit blast radius
Simple product with low user diversity
Strong observability and monitoring (issues caught in production quickly)

Factors That Increase the Need for Dedicated QA

Complex business logic with many edge cases
Multiple platforms (web, iOS, Android, API)
Regulatory or compliance requirements
High cost of production failures (financial, safety, reputation)
Immature development practices (low test coverage, no code review)

Hiring QA Engineers

What to Look For Beyond Technical Skills

Technical skills are necessary but insufficient. The best QA engineers combine technical ability with a set of qualities that are harder to assess but more important in the long run.

Quality	Why It Matters	How to Assess
Curiosity	QA engineers who ask "what if?" find more bugs	Ask about a time they discovered something unexpected
Communication	Bug reports, test plans, and stakeholder updates are all writing	Review a writing sample or ask them to explain a concept
Empathy for users	Understanding how real people use software reveals realistic test scenarios	Ask them to describe how they would test a familiar product
Systematic thinking	Exploratory testing requires structured approaches, not random clicking	Give a small testing exercise and observe their approach
Comfort with ambiguity	Requirements are often incomplete; QA must fill the gaps	Ask how they handle unclear requirements
Resilience	QA often involves repetitive work, political friction, and pushback	Ask about a difficult situation and how they handled it
Collaboration	QA works with every role; adversarial testers create friction	Ask about their relationship with developers

Interview Questions for QA Candidates

Exploratory thinking:

"Here is our login page. You have 15 minutes. Walk me through how you would test it." (Observe: do they start with a plan or dive in randomly? Do they consider edge cases, security, accessibility, performance?)

Communication and prioritization:

"You found a critical bug 2 hours before a major release. The developer says it is not critical. Walk me through how you handle this."

Technical depth:

"Describe a test automation framework you have built or significantly contributed to. What were the design decisions and trade-offs?"

Process and strategy:

"You join a team with no test automation, no test documentation, and a history of production bugs. What do you do in your first 90 days?"

Self-awareness:

"Tell me about a bug that escaped to production on your watch. What happened and what did you learn?"

Diversity of Skills Within a QA Team

A high-performing QA team is not five people with identical skills. It is a group with complementary expertise.

Role	Focus	When to Hire
Manual / Exploratory Tester	Deep product knowledge, edge case discovery, usability	Always -- this is the foundation
Automation Engineer	Test framework design, CI/CD integration, maintenance	When manual testing cannot keep up with release velocity
Performance Specialist	Load testing, profiling, capacity planning	When performance is a competitive differentiator or SLA requirement
Security Tester	Vulnerability assessment, penetration testing, compliance	When handling sensitive data or facing regulatory requirements
SDET	Testability improvements, developer tooling, test infrastructure	When the team needs someone who bridges QA and development
QA Lead / Coach	Process design, mentoring, stakeholder communication	When the team reaches 3-4 QA engineers

Building from Scratch vs. Inheriting a Team

Building from Scratch

Your first QA hire matters enormously. This person will set the culture, processes, and standards for everyone who follows. Hire someone who is:

Senior enough to work independently and make strategic decisions
Strong in automation (you need to build the foundation early)
An excellent communicator (they will be the voice of quality)
Comfortable with ambiguity (nothing is established yet)

First 90 days for a new QA team:

Days 1-30: Understand the product, map the riskiest areas, document the current state of quality
Days 31-60: Set up basic automation (smoke tests, CI integration), establish a bug reporting process, start writing critical test cases
Days 61-90: Propose a test strategy, identify the next hire's profile, establish metrics to track progress

Inheriting an Existing Team

When you inherit a QA team, resist the urge to change everything immediately.

Listen first (weeks 1-4): Meet every team member individually. Understand their skills, frustrations, and ideas. Observe current processes before judging them.
Assess (weeks 3-6): Map the team's skills, identify gaps, understand the test infrastructure, review metrics and trends.
Quick wins (weeks 4-8): Fix one or two pain points that the team has been complaining about. This builds trust and credibility.
Strategic changes (months 2-6): Introduce larger changes gradually, with the team's input. Explain the "why" for every change.

QA Team Maturity Model

Level	Name	Characteristics
1	Reactive	No formal QA process. Testing happens ad hoc. Bugs are found in production. No automation.
2	Defined	Basic test processes exist. Bug tracking is in place. Some test cases are documented. Manual testing is the primary approach.
3	Managed	Test automation covers critical paths. CI/CD integration exists. Metrics are tracked. QA participates in sprint ceremonies.
4	Proactive	QA influences requirements and design. Shift-left testing is practiced. Test strategy drives automation investment. Quality is measured and reported.
5	Preventive	Quality is built into the development process. Developers write tests. QA focuses on coaching, tooling, and strategic testing. Defect prevention outweighs defect detection.

Moving Up the Maturity Ladder

Each level transition requires different investments:

1 to 2: Establish basic processes, hire a dedicated QA person, start tracking bugs systematically
2 to 3: Invest in automation, integrate testing into CI/CD, start measuring test effectiveness
3 to 4: Move QA upstream (requirements, design), develop test strategy, implement risk-based testing
4 to 5: Build quality culture across the organization, shift QA focus from execution to coaching, measure defect prevention

Hands-On Exercise

Diagram your current QA team structure. Which model (centralized, embedded, hybrid) does it most resemble?
Calculate your current QA-to-developer ratio. Does it align with the guidance for your context?
Write a job description for the next QA hire your team needs, focusing on the skills gap you want to fill
Assess your team against the maturity model. What level are you at, and what specific actions would move you to the next level?
If you were building a QA team from scratch, describe your first three hires and why you would hire them in that order