•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
Your development team doubles, but your QA team stays the same.
You add another developer while there's only one QA. Then you add another 10 developers. Yet another 20 developers are added.
You cannot rely on a fixed ratio when determining staffing needs.
There are many factors influencing mobile QA besides how often you release. Some examples are risk, product maturity, developer testing appetite, automation state, and the number of supported platforms and devices.
One team may ship once a month with a lot of automation. Meanwhile, another team may ship multiple times to iOS and Android devices and each time may have to perform real-device interactions to test payment flows, offline states, and accessibility, among other things.
A healthy ratio of QA to developers gives you a sense of the right number of QA engineers to hire, provided your developers test well and the product carries low risk backed by strong automation.
However, a healthy ratio may leave a fintech mobile team in a vulnerable state when they ship to many devices every week.
Your aim is to strike a balance so that QA releases pose minimal risk to your organization. Define what work needs to be done by QA, what work needs to be done by developers, and what needs to be done by automation.
As a starting point, one strong embedded QA engineer paired with an appropriately scoped automation plan and a small but focused team is advisable. When your team grows, you'll need an automation expert, a focus on exploratory testing, performance, security, release ownership, and shared device infrastructure.
Track release capacity, automated regression coverage, automation reliability, validation time, QA time spent on investigation, and production defects. These metrics will show you when to hire, automate, reorganize, or take all three strategies.
This article outlines the different phases a mobile QA team can go through as an engineering team grows, from early QA hiring to more advanced QA team structures. It covers considerations for staffing, levels of automation, developer-owned testing, embedded vs. centralized QA, the different specialization levels, coverage of devices, and signals for effective scaling.
Although it may seem simple to establish a fixed ratio based on the testing workload added by each developer, mobile teams have a variety of individual developer workloads.
Developing an internal settings menu involves a much lower testing workload than developing a payment, authentication, messaging, or media upload feature.
Release cycles impact how much QA capacity is available. Investigating and fixing a defect for a daily release cycle is a much more time-sensitive task than a monthly release. It also requires consistent automation and stability of development and testing environments, as well as defined ownership of tasks across development.
Device fragmentation also adds to the testing workload. A product that covers a single, recent version of the iPhone has a lower testing workload than a product that supports numerous versions of iOS and Android applications with a range of hardware from upper-level to lower-level.
While the ratio may be a starting point, the existing workload, level of risk, and the required release frequency should guide the final staff hiring decision.
It is crucial to understand what workloads each release will bring in order to find the ideal size of the mobile QA team.
Consider the following:
A team that supports two mobile platforms (iOS and Android) that release weekly has a completely different workload than a team that supports one mobile platform that releases monthly.
A good exercise is to try and time one complete cycle of a release. See how much time the team spends preparing test data, running regression, checking devices, finding the root cause of failing tests, testing the fix in the release, and validating the final release of the product.
This exercise will show the amount of work that goes into the ratio. It will also help to determine whether adding more people to the team, more automation, or clearer ownership will help to ease the difficulties the team is facing.
Many good small teams have one QA engineer for 4 to 8 developers. This is a good range of developers as long as each developer is doing their unit and integration testing, the product has well controlled device coverage, and the release process is straightforward.
A team requires more QA capacity when:
A mature product with reliable automation can support more developers per QA engineer. A regulated mobile product, with high release frequency, may need a smaller ratio.
The ratio depends on how you weigh the risk for the product and how much testing you are willing to do. It should not be a driver to increase the number of people, but rather an increase in the quality of the work done.
QA capacity improves when every testing layer has a dedicated owner.
Developers should take ownership of tests closest to their code. These include unit tests, component tests, API tests, and most integration tests. They run quickly, so developers can get feedback while they are still programming.
While the best practices for mobile app testing act as guidance, a QA should address risks at a product level including:
Automated scripts should be used to handle checks that have stable and predictable outcomes. The automated regression suite usually contains tests for flows including login, account recovery, onboarding, checkout, search, and syncing data.
This division provides developers with rapid feedback while also giving QA the necessary time to perform risk assessments and find new defects.
Automation should reduce rudimentary work and require less time for feedback. Long test runs do not necessarily reduce work or increase feedback speed.
Measure automation maturity in 5 different domains.
Look beyond testing individual user interface (UI) elements. Payment, authentication, and data sync flows should also be tested. Prioritize business-critical product journeys over UI elements with low impact and risk.
Track false fails, flakiness, reruns, and environment-related failures. Automation is trusted the least when you have to go through a lot of manual work to get a passing result.
Increased feedback speed leads to a decrease in the number of defects in the product. Measure the time it takes to produce useful feedback after a code change.
Increased effort for maintenance test suites usually indicates an absence of ownership or unstable test suites. Measure time spent updating test data, selectors, test environments, and devices. This is where modern tooling can reduce overhead; Drizz turns plain-English test steps into AI-powered mobile tests, runs them on real iOS and Android devices, and helps them adapt as the UI changes.
In order to investigate a failure, tests should provide details like time, videos, logs, network interactions, device information, and build information.
Before employing a new QA engineer, check if the existing automation framework consumes or creates capacity. A stable framework reduces the number of repetitive executions, while an unstable framework creates the need for additional manual work.
In an embedded QA model, each product squad houses a tester. The tester plans with the squad, reviews criteria, determines test coverage, and collaborates with developers throughout the delivery process.
This model balances strong product knowledge and swift communication. It is ideal for teams consisting of semi-autonomous squads and frequent releases.
A centralized model consolidates QA into a shared service. Testers provide support to multiple squads within a shared automation, reporting, device coverage, and quality throughout the product release framework.
This model provides better consistency in sharing specialist skills. It also requires collaboration between QA and the product squad.
Large companies usually employ a hybrid approach. Each squad is assigned a QA engineer, while a centralized quality group manages the automation framework and device infrastructure, as well as test standards, accessibility, and special support.
Different product and team sizes dictate the optimal structure. Small teams usually collaborate within a squad, while larger teams thrive under more uniform standards in order to prevent multiple squads from creating disparate tools and standards.
Testing all devices can be costly and unnecessary. Thoughtfully planned device coverage should take into account customer usage, product risk, and known defects.
Build a device matrix based on:
Run smoke tests on a large number of devices. Perform deeper regression tests on a smaller, more focused set of representative devices. Add coverage for high-risk features and defective devices.
Real devices give great insight into on-device performance, permissions, background behavior, network activity, battery consumption, and hardware integrations. Emulators are great for providing fast feedback and coverage across multiple device versions. A good strategy combines both.
Keep an eye on the device matrix on a regular basis. Customer needs change, support of operating systems change, and organizations introduce new features of their products. As a result, coverage is impacted and needs to be addressed.
QA automation engineers generally work to manage scale and regression risks as a product grows. Specialist positions are required when a risk becomes an effort that greatly exceeds the automation team's capacity.
A mobile automation engineer becomes necessary when test automation, test framework maintenance, and test pipeline integrity control the delivery.
An exploratory tester becomes an excellent addition to the team when scripted regression test execution consumes an excessive amount of time and product risks remain unaddressed as a result.
Performance issues, poor memory use, battery drain, and network issues can all affect your customers' experiences, and performance specialists can help.
Accessibility specialists assist with screen reader usability and compliance, as well as issues with dynamic text, contrast, touch targets, and keyboard navigability.
Security testers come into play in the context of authentication, payments, sensitive data, permissions, and regulated workflows.
Hire specialists in response to measurable risk. Don’t add roles to teams based on perceived need.
Don’t make changes to team structure based on anecdotal evidence or hunches. Review quality metrics for multiple release cycles and wait for valid signals.
Some helpful metrics include:
Identify issues for which each metric provides a clue. Defects that occur during manual regression may warrant an automation investment.
Long time to root cause diagnosis may indicate an investment is required for enabling tests that provide better visibility and reporting.
Device-related defects may indicate inadequate real device access. Repeated defects may indicate no developer-owned tests for specific defects.
A hiring decision should follow the identified constraint. An automation engineer won't resolve an unclear ownership problem. A quality lead won’t replace absence of real device access. Another manual tester won’t resolve a weak automation framework.
The best mobile QA team structure is dynamic and dependent on the mobile product and the release process.
Small teams rely on flexibility in QA skills, close developer ownership, and healthy collaboration. Medium sized teams rely on mature automation, clearly defined release ownership, and devices. Bigger teams rely on shared standards, specialization, and quality ownership across the squads.
The QA to developer ratio continues to be a useful reference when thinking about planning. It is more precise when considered with the context of release volume, the complexity of the platform, the maturity of automation, the risk/impact profile, and the production quality of the resulting assets.
Monitor these signals regularly. Hire when the effort to investigate and validate becomes too much. Automate stable checks that are easy to run. Cluster testing as close as possible to development. Keep QA focused on customer risk, customer behavior, and impactful defects.
Unified mobile testing workflows, assisted by Drizz, help teams organize test execution and release feedback in an efficient way as the volume and speed of device delivery increases.
The goal is not to have the most QA resources, but to have enough quality resources to help developers ensure rapid delivery of assets while protecting the customer experience.
©Drizz 2026 • All Rights Reserved
