How manual QA uses PR testing between releases

At Nutrient, quality assurance (QA) plays a critical role in ensuring that new features and fixes don’t just work but work well. As a manual QA tester, one of the most important (and often underappreciated) balancing acts we perform is managing the quality of software between pull request (PR) testing and final release validation.

This blog post walks through how we approach this balance in our workflow, what makes each phase unique, and why this process helps us catch more bugs, reduce risk, and ship with confidence.

What is PR testing?

When developers open a pull request(opens in a new tab), it’s usually tied to a specific feature, enhancement, or bug fix. This is our first chance to interact with the new code in an isolated environment — a sandbox built specifically for the PR.

At this stage, our goals are to:

• Verify core functionality — Does this actually work the way it’s intended?
• Explore edge cases — Try to think of things that would break it and do things out of ordinary to potentially trigger a crash.
• Check for visual/user interface (UI) bugs — Are there layout issues, typos, or broken elements?
• Catch regressions — Did this PR introduce a new issue? Did something change in the behavior?

This approach works well for us because we’re able to take a look at the function early on, test it, and see if there are bugs much earlier. If we find issues, it’s much easier to fix it in a PR rather than fixing it after the code is merged and it’s deployed to the staging environment.

Why PR testing alone isn’t enough

While PR environments are great for catching early bugs, they aren’t a perfect reflection of the real world. Here’s why:

• Mocked or limited data — PRs often use test data or incomplete datasets.
• Incomplete integration — A feature might work alone but fail when combined with others.
• Environment differences — Staging or production may behave differently from PR builds.

This is why we never rely solely on PR testing to approve a feature.

The second line of defense: Release validation

Once a feature makes it through code review and PR testing, it gets bundled into a draft release. This is where our second round of QA comes in, and it’s even more critical.

Here, we test:

• End-to-end workflows — How does this feature behave as part of a bigger user journey?
• Real-world data scenarios — Are there differences when using live or production-like data?
• Compatibility checks — Does it play well with other recent changes?
• Critical paths — Do core business functions still work?

We treat every release as a potential product launch, even if it’s a minor update. Testing at this level helps us simulate the full experience a user would have and validate that nothing got lost in translation between development and deployment.

Balancing the two: A QA mindset

So how do we manage the balance between PR testing and release validation? Here’s what works for us:

• Early testing prevents late surprises — PR testing gives fast feedback and confidence to developers.
• Think modularly, test holistically — In PRs, we focus on the unit. In releases, we test the ecosystem.
• Feedback loops — If a bug is found late, we trace it back and ask, “Could this have been caught earlier?”
• Close collaboration with developers — The QA/developer relationship is essential for clarity, alignment, and speed.

Conclusion

Manual QA isn’t just about clicking around to find bugs; it’s about protecting the user experience, each step of the way. By combining targeted PR testing with comprehensive release validation, we create a layered defense that catches issues early, but also ensures nothing slips through the cracks.

At the end of the day, our job is to make sure that when features hit production, they work not just in theory, but in practice.