When I joined a mobile game project for young children, the immediate QA challenge was not a lack of effort. It was that the team did not yet have a shared system for turning testing into reliable release information.
There was no formal test plan or regression plan. Release approval criteria were not written down. Testing environments were not clearly separated, and the process for producing QA builds needed ownership. Dedicated QA documentation was limited, so testers often relied on Miro boards originally prepared to communicate designs to artists and developers.
My first instinct could have been to start writing hundreds of test cases. That would have created more documentation, but it would not have solved the underlying problem.
Before expanding coverage, we needed to know what we were testing, where we were testing it, who owned each area, and how the evidence would support a release decision.
That became the foundation of our QA strategy.
A Project Without a Test Plan
A test plan is useful, but the absence of one was only the most visible gap. The deeper problem was that several connected decisions were still implicit.
Which build should QA validate? Who was responsible for publishing it? Which environment was safe to use? What information made a bug actionable? Who understood each feature well enough to lead its validation? What conditions would make a release ready—or not ready—for production?
If those questions do not have clear answers, adding more test cases can create the appearance of control without creating release confidence.
I began by looking at the flow of information and responsibility around testing. The goal was not to introduce a heavy process. It was to give QA, development, and production a shared operating model.
That distinction mattered. The team was already building and testing the product. My role was not to arrive and declare that everything being done was wrong. It was to make the work more repeatable, visible, and useful for decisions.
Build the Testing Environment Before Expanding Coverage
The first priority was defining the environments and the process for producing builds that QA could trust.
When teams test against an environment that changes unexpectedly, a failed test can mean several different things. The feature may be broken, the data may have changed, another deployment may have replaced the code, or the tester may no longer be validating the intended release candidate.
That uncertainty wastes time and weakens the evidence QA provides.
We defined where different types of validation should happen and established a clearer process for generating QA builds. Specific people became responsible for creating and publishing those builds. QA could then validate a release candidate knowing which version and configuration were under test.
This did not make defects disappear. It made test results easier to interpret.
An environment strategy is sometimes treated as an infrastructure detail, but for a QA Lead it is part of the quality strategy. A stable test target allows the team to distinguish a product problem from noise introduced by unrelated changes.
Make Bugs Actionable
The next improvement was agreeing with development on the minimum information required for a useful bug report.
At a minimum, a defect needed clear reproduction steps, the environment in which it occurred, and visual evidence such as an image or video when that evidence would help explain the behavior. The objective was not to make bug reports longer. It was to include enough diagnostic context for another person to reproduce and investigate the problem.
We also made new defects visible in a shared channel. Developers could see incoming issues, recognize the affected area, and help identify who was best positioned to investigate. As QA Lead, I also learned which developers had the strongest context in different parts of the product, which helped me route issues more effectively.
The result was less time lost between reporting a problem and beginning the fix. Conversations became less focused on reconstructing missing context and more focused on understanding the cause.
This reinforced an important principle for me: the value of a bug report is not that it proves QA found something. Its value is that it helps the team make the product better.
Give Every Feature a QA Owner
We then assigned a QA owner to each feature.
That person was responsible for understanding the feature, documenting how it should behave, leading its validation, and sharing that knowledge with the rest of the QA team. The owner also participated in design meetings, even when the first contribution was simply listening and learning.
For a game intended for young children, this early involvement was especially valuable. A feature could be technically correct and still be confusing to a five-year-old. Waiting until implementation was complete to discover that problem would make the feedback more expensive and the available options more limited.
By listening during design discussions, QA could raise questions earlier: Would a child understand what to do next? Was the feedback clear enough? Did the flow require reading, precision, or patience that the intended user might not have?
Not every question resulted in a design change. That was not the goal. The goal was to make quality considerations visible while the team still had choices.
Feature ownership also reduced knowledge silos. The owner developed depth, but documenting and sharing the testing approach allowed the rest of QA to support later validation and regression.
Test at the Right Depth at the Right Time
Once the operating foundation was clearer, we could organize testing in layers.
The first layer was detailed feature testing. This was where QA validated the complete functionality and relevant edge cases. The purpose was to understand the feature deeply and identify problems before treating it as a stable part of the product.
The release cycle also included a period for validating complete features again. This helped us see how features behaved after integration and after the product had continued to change around them.
The final release regression had a different purpose. It was a focused suite built around the product’s critical user journeys and executed against a stable release candidate. It did not repeat every feature-level edge case because that depth of testing had already happened earlier in the cycle.
For example, a release regression for the account system could include creating an account, signing in, and signing out. We were confirming that a child could still complete the essential flow during normal use of the game.
This was not about declaring edge cases unimportant. It was about applying the right depth at the right moment.
If every regression attempts to repeat every test ever designed, feedback eventually becomes too slow for the decision it is supposed to support. A useful release regression should provide timely evidence about whether the product’s essential experiences remain stable.
Turn Release Decisions Into Risk Decisions
As a release approached, I reviewed the status of each feature with the producer and development lead.
We considered more than the number of open bugs. We discussed how important the feature was to the business, its implementation status, the potential impact on the user, the technical risk, and the amount of time available for meaningful validation.
Sometimes the correct response was to prioritize one feature over another. Sometimes a nonessential feature was removed from the scope. In other situations, I had to communicate that a feature was not ready for production or that the proposed date did not leave enough time to validate the release responsibly.
Those conversations were not always comfortable, but avoiding them would not remove the risk. It would only make the risk less visible.
I do not see QA as the department that unilaterally decides whether the business is allowed to release. QA’s responsibility is to make the condition of the product and the remaining uncertainty clear enough for the team to make a conscious decision.
That means being able to say more than “QA passed” or “QA failed.” A useful release conversation should explain what was tested, what remains unverified, what could happen if the issue reaches users, and which options are still available.
Two Times the Correct Decision Was Not to Ship
Two release decisions illustrate how that worked in practice.
In one case, in-app purchases were not functioning correctly. This was not a minor visual issue or an edge case with limited impact. It affected a core product and business flow. The release was delayed because shipping it would have exposed users to a broken experience in an area where failure carried significant consequences.
In another case, the product was designed to offer both Google Sign-In and Sign in with Apple. The Google option was working, but the Apple implementation was not ready.
We established a deadline for resolving the remaining problem. We also agreed on the fallback before reaching that deadline: because the interface and experience were designed to offer both methods or neither, we would remove both from the update if one could not be completed.
That is what happened. We removed the two sign-in options from that release.
The Google functionality worked in isolation, but readiness is not only about whether one component functions. It is also about whether the experience is complete, consistent, and appropriate for the release being presented to users.
These decisions demonstrate why QA strategy must include scope management. The available options are not limited to “fix everything” or “ship everything.” A team can correct a problem, reduce the scope, remove a feature, change the date, or consciously accept a lower-impact risk.
The strategy gives the team a way to choose among those options with evidence.
What Changed
The most important result was not the existence of more QA documents. It was that the team could move from a problem to an informed action more reliably.
Defects contained better evidence and context, which made them easier to reproduce and route. Developers had visibility into new issues and could help identify the right person to investigate them. QA had stable release candidates and knew which environment, build, and configuration it was expected to validate.
Feature ownership gave individual testers deeper context while still creating documentation that the wider team could use. Participation in design meetings allowed quality questions to surface before implementation. Release discussions became clearer conversations about scope, risk, timing, and readiness.
None of these practices was revolutionary on its own. Their value came from how they worked together.
Stable environments made results trustworthy. Actionable bug reports turned results into development work. Feature ownership created knowledge. Layered testing provided the right evidence at the right time. Risk-based release conversations turned that evidence into decisions.
That combination was the QA strategy.
Five Questions Every QA Strategy Must Answer
A useful QA strategy does not need to begin as a large document. It needs to help the team answer five practical questions:
- What are we testing?
- Where and on which build are we testing it?
- Who owns each area?
- Which risks remain open?
- Do we have enough evidence to release?
The exact processes will change with the product and the organization. A mobile game for young children will not have the same risk profile as a financial platform or an internal business tool.
But the purpose remains the same: create a shared system that turns testing into trustworthy information and trustworthy information into better decisions.
That is the difference between testing features and leading quality.