Inside Fora Soft's QA Testing Team: Structure, Roles, Ratios & Playbook (2026)

Why Fora Soft wrote this playbook

Fora Soft has been shipping video, AI, and real-time software since 2005 — twenty years and 625+ delivered projects later, QA is the function that keeps that number growing. Our Upwork success score stays at 100% precisely because QA sits next to developers from day one, not stapled to the end of the sprint.

This guide is not a “meet the team” piece. It is the internal playbook we use when a founder asks, “How should my QA team actually be structured?” You’ll see the roles we staff, the ratios we hold, the tools we pay for, the mistakes we watch for, and the cost math we run before every engagement. Wherever a claim is backed by hard data — VALT’s 650+ law-enforcement deployments, BrainCert’s 1M+ learners, Franchise Record Pool’s DJ platform — we ground it in the specific project.

If you’re evaluating whether to build an in-house QA team, extend yours with a partner, or hand the entire function to a vendor, this article is the decision document. Read section 13 (the five-question framework) if you’re short on time.

What a healthy QA org looks like in 2026

Before we talk headcount, here’s the scoreboard we hold ourselves against — and the industry benchmarks that inform each line. If your current QA team is missing three or more of these targets, something is off in either staffing, tooling, or process.

The 1:3 ratio isn’t arbitrary. Rice Consulting’s ratio survey puts the most-common number at 1:3, with the mean drifting to 1:7 in organizations that push QA work back to developers. The 2024 State of Testing report from PractiTest confirms that teams with dedicated test-management tooling outperform by 23.7% on delivery metrics — which is why we standardized on TestRail + Jira + GitHub Actions across every engagement.

The seven QA roles a modern software team actually needs

“We have a QA engineer” is rarely enough. On a product with a real user base — especially one that handles video, payments, PHI, or regulated data — you need these seven capabilities covered. They don’t all need to be separate people, but they all need to be owned.

1. QA Lead / Test Manager

Owns the strategy. Decides what gets tested, with what priority, against what risk. Writes the test plan, negotiates the release criteria with product, and reports quality KPIs to stakeholders. On Fora Soft projects the QA Lead also chairs the sprint’s bug triage and owns the relationship with the client’s product owner.

2. Manual QA Engineer

Owns exploratory, UAT, and regression on new features. This is the person who asks, “What if the user opens 3 chats simultaneously on an iPhone SE while screen-sharing?” Manual QA is where novel bugs are found; automation catches only what you’ve already learned to describe.

3. QA Automation Engineer

Owns the regression automation suite. Writes Playwright/WebDriverIO/Appium tests, keeps them green, and integrates with CI. Distinct from an SDET in that they don’t typically own the framework itself — they live inside it.

4. SDET (Software Development Engineer in Test)

Owns the framework, infrastructure, and tooling. Writes production-quality code: custom runners, shared fixtures, test-data factories, device-farm integrations, flake detection. An SDET who leaves without a handoff is the #1 cause of automation decay — see section 14.

5. Performance / Load Testing Engineer

Owns latency, throughput, and scalability SLAs. Runs k6 / JMeter / Locust scenarios, identifies bottlenecks, signs off on capacity for launches. Mandatory for anything video-centric — we found a 3x latency cliff in one WebRTC product just by running a 400-concurrent-viewer test.

6. Security / Compliance Tester

Owns SAST/DAST, vulnerability scanning, and compliance checks. On HIPAA, GDPR, SOC 2, or law-enforcement evidentiary workflows, this role isn’t optional. For VALT we had a dedicated person running evidence-chain integrity tests every release because a missed bug there is a mistrial.

7. Test Data Management Specialist

Owns realistic, safe test data. Synthetic data generation, PII scrubbing, reproducible fixtures. This role is usually absorbed into the SDET on small teams, but for products that depend heavily on data shape (EdTech, marketplaces, fintech) it deserves its own half-person.

The QA-to-developer ratio and when to break it

There is no universal ratio. There are, however, three ratios we default to based on product profile. The number matters less than whether QA has enough bandwidth to do exploratory testing, not just run the regression suite.

If you go above 1:6, developers end up owning regression and QA becomes a bottleneck at the end. If you go below 1:2, testers start duplicating work and exploratory value drops. We watch both edges.

Shift-left QA: where testing actually starts

Testing at the end of a sprint is 5–15x more expensive than testing during requirements — a cost curve confirmed by both NIST and decades of IBM research. On our projects QA is looped in before a single line of code is written:

1. Requirements review

QA reads every spec before it is signed. One of our testers once saved three weeks of rework on a live-shopping feature by asking, “What happens when the buyer’s cart expires mid-checkout during a sale?” — a scenario that wasn’t in the PRD.

2. Design review

QA reviews Figma and flows alongside the designer. This is where state-explosion questions land best: empty states, error states, 3G load states, long-name truncation, RTL languages.

3. Test case design parallel to development

Tests are written while the feature is being built. By the time the pull request opens, the test plan is ready, which collapses the feedback loop from days to hours.

4. Pairing during implementation

QA pairs with developers for exploratory passes on tricky screens. Atlassian’s agile-testing guidance recommends the same practice — it catches class-of-bug issues that would survive a post-hoc review.

The test pyramid Fora Soft actually uses

Martin Fowler’s pyramid is canonical, but most teams draw it once and never look again. We treat it as a live budget: if unit coverage drops below 60% or E2E grows past 15%, something is off and we fix the source, not the tests.

Two anti-patterns the pyramid is designed to prevent: the ice-cream cone (lots of manual and E2E, few unit) where feedback takes hours and flake kills velocity, and the hourglass (unit + E2E, no integration) where a unit suite passes while an API schema change breaks production. Both are signs that an SDET hasn’t been empowered to own the framework layer.

Manual QA vs Automation vs SDET vs QA Lead, compared

These roles are not a progression — a senior manual tester is not a “failed SDET.” They are different crafts. Confusing them when hiring is the second most common mistake we see in founder-run engineering orgs.

How we build automation that survives teammate turnover

Every agency has war stories about an SDET who built a beautiful framework, then left, and inside 4 months 40% of the suite was flaking and 20% was silently disabled. That is the single worst ROI outcome in QA. Our four guardrails against framework rot:

Standardized framework per stack

Pick one tool per layer across all projects. Playwright for web, WebDriverIO/Appium for mobile, k6 for load. Individual SDETs cannot invent new conventions; if the pattern isn’t documented in our internal QA handbook, we don’t merge it.

Page Object Model + data-testid attributes

Selectors that survive redesigns. Every QA-critical element in the UI gets a stable data-testid. We reject PRs that remove them. Cost to add: 5 minutes per element. Cost to redo selectors after a redesign: the sprint.

Flake budget < 2%

Any test flaking twice in a week is quarantined. Tests get fixed or deleted; they do not rot in the suite. A 10% flake rate trains developers to ignore red CI, which is catastrophic.

Shadow handoffs before any SDET rolls off

Two-week overlap is non-negotiable. The outgoing SDET pairs with the incoming one on live tickets, not a wiki page. If an SDET leaves unexpectedly, another senior SDET from inside Fora Soft backfills within 48 hours — one of the genuine benefits of having a cross-project practice.

Our QA tool stack and why we picked each

This is the stack we install on any new engagement unless the client insists otherwise. Each tool earns its line-item because of a specific failure it prevents.

Where AI speeds up testing, and where it still breaks

AI is reshaping QA — but as the 2024 State of Testing report showed, most teams use it as “extra hands,” not “extra brains.” 69.6% apply AI to execution tasks (mostly test data synthesis and triage), but only 30.9% see measurable reductions in manual testing workload. Here is where we find real leverage, and where we’ve been burned.

What actually works today

Test case generation from requirements. An LLM turns a user story into 40 draft cases in 15 seconds. A human picks the 20 that matter. Net savings: 3–4 hours per medium-sized story.

Bug-report triage. AI classifies incoming tickets into severity, duplicate candidates, and affected modules — with human review on top. We see 40–60% reduction in triage time on high-volume projects.

Flake diagnosis. Pattern-matching flaky failures against historical data surfaces root causes faster than a human grepping CI logs.

Self-healing selectors. Visual-diff-based AI recovery reduces selector maintenance by roughly 30% on projects with frequent UI changes — valuable, but a false positive can hide a real bug, so we keep human review in the loop.

What doesn’t (yet)

Generating exploratory test ideas for novel products. LLMs overfit to patterns they’ve seen; they miss the “what if the user opens this while backgrounded on a VPN” scenarios where real bugs live.

End-to-end autonomous test writing. Demos are impressive; production suites accumulate the same noise-to-signal problem as auto-generated code. A human still owns the test.

If you want the full breakdown, we wrote two companion pieces: AI in quality assurance: practical applications and AI-powered test optimization. Plus the less-cheerful honest take: AI in software testing and QA technical debt.

Mini case: how QA kept VALT stable across 650+ deployments

VALT is an AI video-surveillance and interview recording platform used by 650+ US law-enforcement agencies. When a recorded interview is evidence in a homicide case, “mostly works” is a career-ending phrase.

Situation. The team shipping to VALT had 12 engineers, a Jira install, and no formal regression process. A production incident had corrupted two days of interview recordings. Leadership asked us to rebuild QA from the ground up.

12-week plan. Week 1–2: risk map of the evidence chain — ingestion, encoding, storage, retrieval, export. Week 3–4: TestRail rollout and a frozen regression suite of 400 cases covering every evidence-handling path. Week 5–8: Playwright + k6 automation for the 60% of regression that was deterministic. Week 9–12: dedicated evidence-chain integrity test running on every release, plus a 4-person device lab to reproduce field reports from actual squad-car hardware.

Outcome. Escaped defects per release dropped from 11 to 2 inside six months; evidence-chain incidents went to zero for 14 consecutive months; release cadence went from monthly to bi-weekly without sacrificing stability; and courtroom downtime — the metric the VALT customer actually cares about — stayed at zero across the 14 months we’ve tracked.

Similar pattern on BrainCert, where we’ve been part of the team scaling an LMS past one million learners without a single P1 regression in the last three quarters.

Cost model: in-house vs outsourced QA in 2026

Real numbers for a 12-person engineering team that needs a 4-person QA bench (1 Lead, 1 Manual, 1 Automation/SDET, 1 shared performance/security). Ranges are 2025–2026 market. Your numbers vary; use as a sanity check.

Two non-obvious levers. First, Agent Engineering — our internal practice of pairing humans with AI coding agents — shaves roughly 20–30% off automation framework buildout time, which flows through to a real cost reduction on the first three months of an engagement. Second, a shared QA practice (the Fora Soft model) means you pay for the hours you consume, not the chair, so the effective cost during low-velocity weeks can drop by 30%+.

A decision framework: build, hire, or outsource in five questions

Every founder who asks us “should I hire a QA engineer?” gets walked through these five questions. Answer each honestly; the answer falls out.

Q1. How many developers will ship code in the next 12 months? Under 4: developers can own testing, with a part-time QA consultant for release gates. Between 4 and 10: one full-time QA (or equivalent). Over 10: a team of 3+ with specialized roles.

Q2. What’s your compliance surface? None: you have options. HIPAA / GDPR / PCI / SOC 2 / law-enforcement evidence: you need a dedicated security tester, period, and in-house is easier when auditors want a US or EU citizen.

Q3. How stable is the roadmap? Volatile (pre-PMF): outsource the flexible chunk — you don’t want to hire, fire, re-hire. Stable and growing: build in-house for product knowledge, supplement with an outsourced specialty bench for load, security, device lab.

Q4. How much domain knowledge is required? Generic B2B SaaS: anyone can ramp. Video / WebRTC / telehealth / law-enforcement / live shopping: the ramp-up on an in-house hire is 3–6 months; a vendor with the domain already on the bench (Fora Soft on video/real-time, for example) delivers in weeks.

Q5. What’s the cost of a production bug? A few support tickets: lightweight QA is fine. Customer churn, fines, or liability: invest in the seven-role model and don’t cut corners on automation or security testing.

Five pitfalls that sink in-house QA teams

1. QA stapled to the end of the sprint. When testers only see work in the last two days of a sprint, releases slip, quality compounds, and the QA team becomes the villain in retros. Shift-left or accept the cost.

2. Test cases organized by sprint, not by feature. PractiTest’s survey found 60% of teams have poorly maintained test cases — and in nearly every case the root cause is sprint-scoped organization. Feature-scoped test cases survive re-platforming; sprint-scoped ones rot inside a quarter.

3. Automation built by devs who then leave the framework. Developer-written test automation, without an owner, decays the moment the developer moves on. Either hire an SDET to own it or contract out ownership. There is no third option that works.

4. No device lab and no cloud farm. Trying to cover mobile QA on a personal iPhone and one Android in the drawer. You catch 40% of what’s out there. BrowserStack or a modest in-house lab (5–10 devices, refreshed yearly) costs a fraction of one escaped P1.

5. No performance budget. Performance regressions that creep in 3% per release become a 30% slowdown inside ten releases. A weekly k6 baseline with an alerting threshold catches this inside a day.

KPIs: what we actually measure

Quality KPIs. Escaped defect rate (< 3% on 12-month cohorts), defect removal efficiency (> 95%), regression pass rate on main branch (> 98%), mean time to reproduce (< 1 hour), change failure rate (DORA elite: 0–5%).

Business KPIs. Release cadence (bi-weekly or faster), time-to-market on new features (measured from spec to prod), QA cost per shipped user story, percentage of releases without emergency hotfix (> 90%).

Reliability KPIs. Mean time to detect (< 10 minutes for P1), mean time to restore (< 30 minutes for P1 in production), flake rate in regression suite (< 2%), automated regression coverage (> 70%), uptime on user-critical flows (> 99.9%). We report these monthly to clients and publish them as part of our test summary report template.

Security, compliance, and data testing

Security testing lives inside QA on every regulated project we run. Three practical layers:

Automated scanning in CI. SAST (Semgrep, SonarQube) on every PR. DAST (ZAP baseline) on every staging deploy. Dependency scans (Snyk, Dependabot) daily. Findings triaged weekly. This layer catches 70% of low-severity issues and keeps the backlog honest.

Manual penetration testing quarterly. Internal rotation or external firm depending on compliance. For SOC 2 or HIPAA we always recommend an annual third-party test in addition.

Data-handling test suite. Synthetic-data-only in non-prod, PII scrubbing on DB copies, encryption-at-rest test, key rotation drills. For video products: evidence-chain integrity tests (VALT) and WORM-storage compliance tests.

On payment system reliability we documented the exact reconciliation suite we use — worth a read if you handle money.

The device lab and cross-platform testing

Cross-platform products fail in surprising places. The Franchise Record Pool DJ platform is a good example — a chat feature that looked fine on a flagship iPhone sent duplicate messages every time the recipient was on a Galaxy S7. You only catch that with real devices.

Our default device coverage — ranked by value per dollar:

The culture habits that make our QA team tick

Behind every benchmark number is a habit. When we interviewed our QA team for this article, the same patterns kept showing up:

• Take your time. Rushed testing is shallow testing; shallow testing is the escaped-defect-rate killer.
• Speak up early. Even a small doubt is useful data. Silent testers produce silent bugs.
• Don’t stop at scripted cases. Ask “what if I push this further?” — that’s where the interesting bugs live.
• Learn how the system works under the hood. Easier to investigate, sharper in communication with developers.
• Use AI as a helper, not a replacement. The 2024 State of Testing data backs this up: teams that delegate judgment to AI regress; teams that delegate drudgery to AI improve.
• Challenge requirements early and thoroughly. Cheap now, expensive later.
• Think critically; give constructive feedback. Bugs written without blame get fixed faster.
• Communicate clearly. A bug report with video, network tab, and repro steps saves the developer two hours.
• Keep learning. Meetups, colleagues, different projects — cross-pollination beats tunnel vision.
• Collect full context when reproducing client issues. Screenshots, videos, device specs, network conditions.
• Watch for missing and accidentally added functionality. Both are bugs.
• Automate repetitive steps whenever possible. Your time is worth more than a script.
• Stuck? Ask for help. Guessing never ends well.

We also run a running Slack channel of absurd production bugs — the 100%-discount coupon that discounted only 10%, the 6-digit verification code that showed five, the video timer counting down into negative numbers, the admin-only crash page, the button whose clickable area shrank every click. Every one of those caught in QA before users saw it.

When NOT to hire a dedicated QA team

We’re a QA-positive shop, but there are real cases where you shouldn’t hire a tester on day one:

Pre-PMF, under 4 developers, nothing regulated. Spend the salary on the product. Developers run their own tests, a founder does UAT, and you contract QA for release gates only.

Internal tools with < 50 users. A weekly smoke-test checklist and engaged users are enough. You don’t need the seven-role model to keep a 50-seat internal dashboard healthy.

Throwaway prototypes. The test itself is the market feedback. Resist the urge to gold-plate.

Everywhere else — a real product, real users, real revenue, any compliance — the honest answer is that QA pays for itself inside one quarter by reducing escaped defects and the emergency work they trigger.

FAQ

What to Read Next

Ready to ship stable releases without the drama?

A good QA team is boring from the outside and busy on the inside. You know it’s working when releases ship on schedule, your support inbox is quieter this month than last, and your engineers stop being afraid of deploy day. All of the structure in this playbook — the seven roles, the 1:3 ratio, the pyramid, the tooling stack, the shift-left habit — serves that single outcome.

If you’re not there yet, you don’t need a bigger headcount. You need the right mix and the right habits. Start with the five-question framework in section 13; it will tell you honestly whether you should build in-house, hire, or extend your team with a partner that already has the practice in place.