Building a QA Process from Scratch: Team Structure, Tools, Strategy, and Maturity Model

Starting From Zero: The First 30 Days

When you take on responsibility for QA at a company that has little or none, the first impulse is to start building: writing test cases, setting up tools, creating templates. Resist this impulse for the first two weeks.

The first 30 days should be about observation and understanding:

Week 1: Understand the product and its users

• Use the product as a user would. Find the onboarding flow, the core value action, the billing flow.
• Read support tickets from the last 90 days. What are users complaining about? Where are they getting stuck?
• Talk to support and sales. Ask: "What's the most common thing users call about?" and "What bugs have cost us deals?"

Week 2: Understand the engineering process

• Shadow a developer for a sprint. Understand how code goes from idea to production.
• Identify: who reviews code, who tests before merge, what happens in staging, how deploys work.
• Find out what automated tests exist today. Run them. See how many pass.

Week 3: Identify the critical paths

• Based on weeks 1–2, identify the 5–10 flows that matter most — the ones where a bug would cause a user to churn or a sale to fail.
• These become your first test coverage targets.

Week 4: Write the first test strategy

• One-pager. Not a comprehensive testing plan — a statement of what the QA function will do and not do for the next quarter.

Writing Your First Test Strategy

A test strategy answers five questions:

1. What is in scope? Which products, platforms, and user personas will QA cover?
2. What types of testing will we do? Functional, regression, exploratory, performance, security?
3. What is our quality bar? What does "ready to ship" mean?
4. What will we not do? Explicit exclusions prevent scope creep and set expectations.
5. How will we measure quality? Defect escape rate, test coverage percentage, time to find critical bugs?

The first test strategy for a new QA function should be short — one to two pages — and focused on the highest-risk areas identified in week 3. It should not try to cover everything. It should try to cover the things that matter most.

Sample First Test Strategy Structure

QA Test Strategy — Q3 2026

In Scope:
- Web application (Chrome, Firefox, Safari desktop)
- Authentication and user management flows
- Core product workflow (feature X)
- Payment and billing

Out of Scope (this quarter):
- Mobile app (separate plan Q4)
- Email deliverability testing
- Performance testing under load
- Accessibility audit

Quality Bar:
- All P1/P2 bugs resolved before release
- Critical path smoke suite passes at 100%
- No open payment-related issues at ship time

Testing Types:
- Manual exploratory (new features)
- Automated regression (critical paths)
- Smoke testing on every deploy

Metrics:
- Defect escape rate (bugs found post-release vs. pre-release)
- Open P1/P2 count at release
- Regression suite pass rate trend

This document is published to the team, reviewed by the engineering lead, and updated quarterly.

Team Structure

QA team structure depends on company size, product complexity, and the relationship between QA and development. There is no single correct structure, but here are the three most common models:

Embedded QA Model

Each QA engineer is embedded in a product team (squad, pod, or tribe). They attend standups, sprint planning, and retrospectives as a full member of the team.

Best for: Companies where different teams own different parts of the product, where close collaboration between QA and development is valued, and where domain knowledge is important.

Trade-off: Embedded QA engineers can become siloed in their team's area, making cross-product regression harder to coordinate.

Centralized QA Model

QA engineers sit in a separate function and are assigned to testing across all teams. There is a QA lead or manager who coordinates allocation.

Best for: Smaller companies where one QA person covers multiple teams, or companies where testing requires product-wide knowledge (e.g., testing integrations between modules).

Trade-off: QA is perceived as a separate gate rather than a collaborative partner. Development teams may not involve QA early enough.

Hybrid Model

Some QA engineers are embedded in teams; others form a central platform function that owns test infrastructure, automation frameworks, and cross-product regression.

Best for: Companies at 50–200 engineers who need both close collaboration and consistent automation practices.

Most companies that are building QA from scratch should start centralized (one QA lead covering everything) and move toward embedded as headcount grows.

Tool Selection

Tool selection is often treated as the first decision when building a QA process. It should be among the last. The tool should serve the process, not define it.

Before Selecting Tools, Answer These Questions

1. What volume of test cases are we managing? (10? 1000? 10,000?)
2. Does QA need to collaborate with developers or non-technical stakeholders in the test management tool?
3. What is the team's technical skill level — can they write and maintain code-based automated tests?
4. What CI/CD platform is already in use?
5. What is the budget?

Tool Categories and Recommendations

Bug tracking:

• Jira (full-featured, integrates with everything, can be complex for small teams)
• Linear (fast, developer-friendly, better for small-to-mid teams)
• GitHub Issues (zero cost, sufficient for small teams, limited for QA-specific workflows)

Test case management:

• TestRail (industry standard, structured, good reporting)
• Zephyr for Jira (integrated into Jira, no context switching)
• Notion or Confluence (lightweight, good for small teams, limited test-specific features)
• Spreadsheets (embarrassingly pragmatic for small teams — don't discount it)

End-to-end test automation:

• Playwright (modern, reliable, excellent for teams with JS/TS skills)
• Cypress (good DX, JS-focused, well-documented)
• Selenium (mature, multi-language, high maintenance overhead)

Always-on monitoring:

• HelpMeTest — define critical flows in plain English, monitor them on a schedule and on every deploy. No code required. Ideal for critical path monitoring when the team lacks automation capacity.

API testing:

• Postman (widely used, good for manual + automated API tests)
• Bruno (open source, git-friendly, gaining popularity)
• Newman (Postman CLI for CI integration)

The Tool Trap

The biggest mistake in tool selection is buying a platform before the process exists. A company that buys a $20,000/year test management platform without a test management process will use it poorly and conclude the tool was the problem.

Tools amplify processes. A good process with a basic tool is better than a broken process with an expensive tool.

Start with the simplest tools that meet your current needs. Upgrade when the tool becomes the constraint, not before.

Onboarding New Testers

Onboarding a new QA engineer into a team with no existing QA process is particularly challenging because there is no existing knowledge to transfer. The onboarding burden falls on the new hire to discover everything.

Reduce this burden by building a QA onboarding kit as part of building the process.

QA Onboarding Kit Contents

Product knowledge:

• A walkthrough video or written guide of the core product workflows (create this during your first-30-day observation period)
• Known edge cases and gotchas for each major feature
• The personas document or user research, if it exists

Technical access:

• Credentials and setup instructions for test environment
• Test account inventory (accounts for each user role, payment test cards, etc.)
• Bug tracker access and labeling conventions

Process documentation:

• The test strategy
• Definition of done (what "ready to ship" means)
• Bug severity definitions (P1 through P4 or equivalent)
• How to file a bug (required fields, reproduction steps format)
• How regression testing works (when it runs, who is responsible)

Week 1 assignment:

• A structured list of flows to explore manually as a new user — designed to build product knowledge
• A set of existing test cases to run — designed to build process familiarity
• Paired work with an existing team member

A QA engineer with a good onboarding kit is productive in 2–3 weeks. Without one, it typically takes 6–8 weeks.

The QA Maturity Model

A maturity model gives you a framework for communicating where your QA practice is today and what the next level looks like. It is particularly useful when presenting to leadership who want to understand QA investment in terms of business impact.

Level 1: Reactive

Characteristics:

• No formal QA process
• Testing is ad-hoc, done by developers or manual spot checks before release
• Bugs are found by users
• No test documentation
• No metrics

Typical output: High defect escape rate, production incidents are common, trust in quality is low

Next step: Define critical paths, write first test strategy, establish a bug tracker

Level 2: Defined

Characteristics:

• QA process documented and consistently followed
• Critical paths identified and manually tested each release
• Bug tracker in use with consistent severity definitions
• Test strategy exists and is updated quarterly
• Defect escape rate tracked

Typical output: Bugs caught before release for most critical paths, production incidents decrease

Next step: Automate the critical path smoke suite, add CI/CD integration

Level 3: Automated

Characteristics:

• Automated smoke suite runs on every deploy
• Regression suite covers major features
• Test results integrated into deployment pipeline (deploy blocked on suite failure)
• Test coverage metrics tracked
• QA involved in sprint planning

Typical output: Regressions caught automatically, QA effort shifts from regression to exploratory

Next step: Add performance testing, shift QA earlier in development (spec review, risk assessment)

Level 4: Shift-Left

Characteristics:

• QA participates in requirements review and architecture discussions
• Test plans written before development begins
• Risk-based testing approach for sprint planning
• Developers write unit and integration tests as standard practice
• QA owns test infrastructure, not just test execution

Typical output: Defects caught in design phase, not testing phase. Cost of quality decreases significantly.

Next step: Predictive quality metrics, automated monitoring in production

Level 5: Continuous Quality

Characteristics:

• Quality monitoring in production (not just pre-release)
• Defect trends and leading indicators tracked and acted on
• Canary deployments with automated quality gates
• QA metrics drive product and engineering decisions
• Quality is a shared responsibility across all engineering

Typical output: Quality is invisible — it is just how the team works. Production incidents are rare.

Most companies building QA from scratch should aim for Level 3 as a 12-month goal and Level 4 as a 24-month goal. Level 5 is typically a multi-year investment.

Making QA a Cultural Practice, Not a Gate

The difference between a QA process that works and one that doesn't is usually not tooling or coverage — it is culture. A QA process that developers see as a gate to get through will be gamed, minimized, and resented. A QA process that developers see as a shared tool for shipping confidently will be embraced.

The transition from gate to tool happens when QA catches problems that would have caused incidents, communicates the value of those catches clearly, and helps development teams ship faster by reducing the uncertainty that accompanies every release.

Build the process with that goal in mind, and use tools that support it. HelpMeTest exists specifically to reduce the uncertainty around each deploy — you define what "working" looks like for your critical paths, and it continuously verifies that they are working. That verification becomes a shared confidence signal for the whole team, not just the QA function.

The best QA process is one where the entire team can look at a dashboard before shipping and know, with evidence, that the things that matter are still working.